API秘密应该被哈希吗？

Question

这可能听起来像一个愚蠢的问题，因为密码当然需要进行哈希处理，而不是存储原件。

但是，对于API机密，通常我会在注册时看到它们以明文形式显示。

例如，如果我访问google api控制台并查看我的凭据页面，我可以查看我的客户端密码，同样适用于Twitter。

当然，api密钥和密码一样敏感吗？

是否只是因为从提供商方面，您可以确信生成了足够强大的密码？ 如果是这种情况，那么这不会提供任何保护，因为您的数据库受到了损害。

或者也许是因为如果你使用基于令牌的身份验证，你要么做密码授权类型，这要求你发送你的凭据以及客户端ID和秘密，或刷新令牌，这样用户就可以已经不得不受到损害了？

Answer 1

我可以想象一些可能的答案：

• 在某些情况下，可能需要服务器具有明文API密钥的持久存储，以满足可用性要求（Google和Twitter就是示例）。
• 在某些情况下，单独的API密钥根本不足以做多少事情 - 另外一个需要有一个经过身份验证的帐户 - 因此API密钥本身的价值有限（因此价值低于密码）
• 在许多情况下，API密钥在客户端应用程序中硬编码（特别是移动应用程序，几乎总是这样做），因此当同一令牌可以在服务器端添加额外保护时没有意义从客户那里琐碎地提取。
• 安全行业尚未成熟。也许一旦黑客开始倾销API密钥，这样的想法可能会更加重视。

顺便说一句，我对最后一点非常认真。事实是，在他们背后有大量的支持之前，很多好的想法都不会成为现实。作为一个例子，我曾经在博客上写过一个相关主题 - protecting user confidential information by hashing it in the database，但是在合法用户登录时可以恢复。我以Ashley Madison为例 - 在这种情况下，黑客是电子邮件地址，电话号码和物理地址之后的密码多于密码。因此，当黑客抢夺数据库时，他们会立即得到他们想要的东西，他们可能不太关心bcrypt编码的密码（事实上，一些旧的密码只用MD5进行编码！）不幸的是，像这样的概念没有足够的努力使它们成为现实。即使零知识网页设计在现实世界中也很少。