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

Question

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

1. 取用户密码
2. 用随机盐哈希
3. 然后，他使用散列类型和salt为＃2的结果添加前缀，并使用竖线分隔的字符串将它们连接起来。 （例如SHA1 | RANDOMSALT | afde4343 ....）
4. 在db
中存储＃3的结果

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

我认为我之前从未见过这个，但是，我正在寻找原因，除了未经授权的用户可以立即知道使用何种类型的哈希来加密密码和存储字段所需的额外空间。

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

谢谢！

Answer 1

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

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

所以不要试图说服你的朋友他所做的事情很糟糕。相反，让他说服你他正在做的事情是好的。

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

Answer 2

将散列“成本”（散列的次数stretched）存储起来也是一种好习惯，甚至crypt()也可以。可能，最糟糕的问题是您首先必须查询数据库（了解盐，成本，算法），然后检查生成的哈希，这需要额外的数据库之旅。

为什么这是一个好习惯？好吧，如果你有特定于用户的盐，它们必须存储在某个地方...此外，你可能（将来）想要将你的哈希的成本（散列的次数“重新散列”）升级到如果你不知道你不能做任何事情的原始费用，请遵守摩尔定律。

我强烈建议您read this blog post about (secure) password hashing。