理想的密码散列算法是什么样的？答案

【问题标题】：what would ideal password hashing algorithm look like?理想的密码散列算法是什么样的？
【发布时间】：2011-12-17 03:58:36
【问题描述】：

免责声明：关于 SO 有很多类似的问题，但我正在寻找一个实用的建议，而不仅仅是一般原则。此外，请随意指出“理想”算法的实现（PHP 会很好；），但请提供具体细节（它是如何工作的）。

计算存储在数据库中的密码哈希字符串的最佳方法是什么？我知道我应该：

使用盐
多次迭代哈希过程（key stretching 的哈希链）

我正在考虑使用这样的算法：

x = md5( salt + password);
repeat N-times:
    x = md5( salt + password + x );

我确信这是相当安全的，但我想到了几个问题：

在 salt 中包含用户名会有好处吗？
我决定为所有用户使用食盐，这样做有什么缺点吗？
建议的最小盐长度是多少（如果有）？
我应该使用 md5、sha 还是别的什么？
上述算法有什么问题/有什么建议吗？
...（请随时提供更多信息：）

我知道这些决定必然取决于具体情况，但我正在寻找一种解决方案：

提供尽可能多的安全性
足够快（在一台不错的机器上

那么，理想的算法应该是什么样的，最好是伪代码？

【问题讨论】：

对于key stretching - 我已更新问题以反映这一点。

标签： hash passwords md5 sha1

【解决方案1】：

我倾向于使用固定的应用程序盐、用户名和密码

示例...

string prehash = "mysaltvalue" + "myusername" + "mypassword";

这里的好处是使用相同密码的人最终不会得到相同的哈希值，并且它可以防止有权访问数据库的人将他们的密码复制给其他用户 - 当然，如果您可以访问您的数据库真的不需要破解登录来获取数据；）

IMO，盐长度无关紧要，哈希值长度始终为 32（使用 MD5 - 这也是我将使用的）

在安全方面我想说，这个密码加密就足够了，最重要的是确保你的应用程序/数据库没有安全漏洞！

另外，我不会为重复散列而烦恼，在我看来没有意义。有人必须知道你的算法才能尝试以这种方式破解它，然后它是否被哈希一次或多次都没关系，如果他们知道，他们就知道

【讨论】：

多轮散列增加了所需的计算量。一次性身份验证很便宜，但对攻击者来说很快就会变得更加昂贵。
没错。 :) @musefan：我正在寻找“最佳实践”解决方案而不是“足够好”。正确地做事并没有损害——那里有太多糟糕的安全解决方案（不是说你的就是其中之一）。盐键长度很重要，因为它会延长散列字符串 - 需要更大的彩虹表（我认为）。我确实同意其他漏洞，但这是一个全新的主题。 :)
@johndodo：如果他们知道盐键，那么长度并不重要，如果他们使用的是彩虹表，那么他们可能会直接破解哈希，或者您的登录功能（在这种情况下，他们不会不需要关心盐）

【解决方案2】：

“理想的”密码散列函数现在是bcrypt。它包括盐处理和可配置的迭代次数。有一个free opensource PHP implementation。

其次是PBKDF2，它依赖于底层哈希函数，与您的建议有些相似。有technical reasons为什么bcrypt比PBKDF2“更好”。

至于你的具体问题：

1。在 salt 中包含用户名会有好处吗？

不是真的。

2。我决定为所有用户使用普通盐，这有什么缺点吗？

是的：它消除了吃盐的好处。 salt 存在的唯一原因是每个散列密码都是唯一的。这可以防止攻击者以比攻击一个散列密码两倍的努力来攻击两个散列密码。盐必须是唯一的。即使拥有每个用户的盐也是不好的：当用户更改密码时，盐也必须更改。攻击者在重用/共享盐时可能应用的优化类型包括（但不限于）预先计算的哈希表，例如rainbow tables。

3。建议的最小盐长度是多少（如果有）？

盐必须是唯一的。唯一性是一个难以维护的属性。但是通过使用 足够长 随机盐（使用良好的随机数生成器生成，最好是加密强的），您以足够高的概率获得唯一性。 128 位的盐已经足够长了。

4。我应该使用 md5、sha 还是其他的？

MD5 不利于公共关系。它有已知的弱点，可能适用于也可能不适用于给定的用法，并且很难以任何可靠性“证明”这些弱点不适用于特定情况。 SHA-1 更好，但不是“好”，因为它也有弱点，尽管不如 MD5 严重。 SHA-256 是一个合理的选择。正如上面所指出的，对于密码散列，您需要一个在GPU 等并行架构上不可以很好扩展的函数，并且 SHA-256 可以很好地扩展，这就是使用 Blowfish-derivative 的原因最好在 bcrypt 中。

5。上述算法有什么问题/有什么建议吗？

这是自制的。那很糟。问题是没有已知的密码算法安全性测试。我们所能期望的最好的结果是让数百名专业密码学家尝试破解一个算法几年——如果他们不能，那么我们可以说虽然该算法并没有真正“被证明”是安全的，但至少有弱点一定不能很明显。 Bcrypt 已经存在、广泛部署和分析了 12 年。即使有 StackOverflow 的帮助，你也无法靠自己打败它。

作为一名专业的密码学家，我会对在 MD5 甚至 SHA-256 中使用简单的连接表示怀疑：这些是 Merkle–Damgård 哈希函数，可以很好地抵抗碰撞，但不提供 @987654328 @（有所谓的“长度扩展攻击”）。在PBKDF2中，没有直接使用hash函数，而是通过HMAC。

【讨论】：

谢谢，这正是我所希望的——我必须承认我不知道 bcrypt。既然我已经在网上搜索了有关它的信息，我知道为什么...这一定是保存最完好的秘密之一... ;) 我同意您的帖子，您提出的担忧正是让我发帖的那些这个问题。关于如何正确使用 bcrypt 的任何建议？通过phpass 或some other class?
This answer 推荐 phpass 并且似乎提供了有关如何使用它的详细信息。我自己不使用 PHP 开发。