API秘密应该被哈希吗？

发布时间：2020-12-16 04:24:57 所属栏目：asp.Net 来源：网络整理

导读：这可能听起来像一个愚蠢的问题,因为密码当然需要进行哈希处理,而不是存储原始密码. 但是,对于API机密,通常我会在注册时看到它们以明文形式显示. 例如,如果我转到google api控制台并查看我的凭据页面,我可以查看我的客户端密码,同样适用于Twitter. api密钥肯

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

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

例如,如果我转到google api控制台并查看我的凭据页面,我可以查看我的客户端密码,同样适用于Twitter.

api密钥肯定和密码一样敏感吗？

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

或者也许是因为如果你使用基于令牌的身份验证,你要么做密码授权类型,这要求你发送你的凭证以及客户端ID和秘密,或者刷新令牌,这样用户就不得不已被妥协？

解决方法

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

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!