在数据库中存储有关密码哈希的元数据？答案

【问题标题】：Storing metadata about password hashes in the database?在数据库中存储有关密码哈希的元数据？
【发布时间】：2011-06-10 21:33:35
【问题描述】：

我和我的一个朋友聊天，他说要将用户密码存储在数据库中，他和我引用：

他声称这是可读的，因为他“可以立即知道”使用哪种类型的哈希摘要。

我想我以前从未见过这种情况，但是，我正在寻找为什么它会很糟糕的原因，除了未经授权的用户可以立即知道使用哪种类型的哈希来加密密码和存储字段所需的额外空间。

我的直觉反应是这种处理密码的方法很愚蠢，因为任何帮助攻击者破解密码的迹象都是一个弱点。我应该用什么其他理由来说服他这是个坏主意？

谢谢！

【问题讨论】：

【解决方案1】：

这是个好主意。每个人都这样做，包括在 Unix 系统上的 /etc/password (/etc/shadow...) 文件中。

任何体面的安全模型都会假设攻击者知道使用了哪种散列函数，如果只是因为散列系统是一个软件，存储在硬盘上。相反，相信不宣布使用哪个哈希函数的优点类似于security through obscurity，这很糟糕。

所以不要试图让你的朋友相信他的所作所为是坏事。相反，让他让你相信他的所作所为是好的。

PS：这不是密码加密，这是密码哈希。散列不是一种加密。

【讨论】：

这个答案是正确的。我了解什么是通过默默无闻的安全性，并且，我可以看到我的问题是如何措辞的，这似乎是预期的目标，但是，我主要是在寻找我最初的直觉反应是对还是错的原因。看来我错了。再次感谢！附言是的，加密中的分类哈希，它们实际上是摘要而不是加密。需要记下这一点，我编辑了问题以反映这一点。

【解决方案2】：

存储散列“成本”（散列为stretched 的次数）也是一种很好的做法，即使crypt() 也会这样做。可能，最糟糕的问题是您首先必须查询数据库（了解盐、成本、算法），然后检查您生成的哈希，这需要额外访问数据库。

为什么这是一个好习惯？好吧，如果你有用户特定的盐，它们必须存储在某个地方......另外，你可能（将来）想要将你的哈希成本（哈希“重新哈希”的次数）升级到跟上摩尔定律，如果您不知道原始成本，您将无能为力。

【讨论】：