Các bí mật API có nên bị băm nhỏ không?

Question

Nó có vẻ giống như một câu hỏi ngớ ngẩn, bởi vì mật khẩu của khóa học cần phải được băm và không bao giờ lưu trữ bản gốc.

Tuy nhiên, đối với bí mật API, thường tôi thấy chúng được hiển thị rõ ràng khi đăng ký chúng.

Ví dụ: nếu tôi truy cập bảng điều khiển google api và xem trang thông tin đăng nhập của mình, tôi có thể xem bí mật của khách hàng của mình, tương tự cho twitter.

Khóa api chắc chắn cũng nhạy cảm như mật khẩu?

Có phải chỉ vì bên phía nhà cung cấp, bạn có thể tự tin rằng mật khẩu đủ mạnh đang được tạo? Nếu đó là trường hợp, sau đó không cung cấp bất kỳ bảo vệ là cơ sở dữ liệu của bạn bị xâm nhập. Hoặc có lẽ vì nếu bạn đang sử dụng xác thực dựa trên mã thông báo, bạn đang thực hiện loại cấp mật khẩu, yêu cầu bạn gửi thông tin đăng nhập cùng với id ứng dụng và bí mật hoặc mã thông báo làm mới, để người dùng đã phải bị xâm phạm?

Answer 1

tôi có thể tưởng tượng một vài câu trả lời có thể như thế này:

• Trong một số trường hợp, nó có thể được yêu cầu cho máy chủ phải có bộ nhớ dai dẳng của khóa API rõ để đáp ứng yêu cầu khả năng sử dụng (Google và Twitter là ví dụ).
• Trong một số trường hợp, khóa API không đủ để làm nhiều - bổ sung một cần phải có tài khoản được xác thực - và do đó khóa API của chính nó có giá trị giới hạn (do đó ít giá trị hơn mật khẩu) .
• Trong một số trường hợp, khóa API được mã hóa cứng trong ứng dụng khách (đặc biệt là ứng dụng dành cho thiết bị di động, hầu như luôn làm điều này) và do đó không có ý nghĩa gì khi thêm bảo vệ bổ sung ở phía máy chủ. được lấy ra từ khách hàng.
• Ngành bảo mật chưa trưởng thành. Có thể một khi tin tặc bắt đầu bán các khóa API, các ý tưởng như thế này có thể được coi trọng hơn.

BTW, tôi rất nghiêm túc về điểm cuối cùng. Sự thật là rất nhiều ý tưởng hay không trở thành hiện thực cho đến khi có một khối lượng hỗ trợ quan trọng phía sau chúng. Ví dụ, tôi từng viết blog về một chủ đề liên quan - protecting user confidential information by hashing it in the database nhưng theo cách nó có thể được phục hồi khi người dùng hợp pháp đăng nhập. Tôi đã sử dụng Ashley Madison làm ví dụ - trong trường hợp đó, tin tặc có nhiều địa chỉ email hơn , số điện thoại và địa chỉ thực hơn mật khẩu. Vì vậy, khi tin tặc giật lấy cơ sở dữ liệu, họ ngay lập tức có những gì họ muốn, và họ có thể quan tâm đến mật khẩu mã hóa bcrypt (trên thực tế, một số mật khẩu cũ hơn chỉ được mã hóa với MD5!) Thật không may, các khái niệm như thế này không có đủ thúc đẩy họ trở thành hiện thực. Ngay cả thiết kế web không có kiến ​​thức cũng rất ít trong thế giới thực.