密码哈希：PBKDF2（使用 sha512 x 1000）与 Bcrypt答案

【问题标题】：Password Hashing: PBKDF2 (using sha512 x 1000) vs Bcrypt密码哈希：PBKDF2（使用 sha512 x 1000）与 Bcrypt
【发布时间】：2011-05-24 21:50:09
【问题描述】：

我一直在阅读有关 Gawker 事件的文章，并且出现了几篇关于仅使用 bcrypt 来散列密码的文章，我想确保我的散列机制足够安全以避免切换到另一种方法。在我当前的应用程序中，我选择了使用 sha2-512 和至少 1000 次迭代的 PBKDF2 实现。

我能否就使用 PBKDF2 与 Bcrypt 以及是否应该实施更改征求意见？

【问题讨论】：

标签： passwords hash password-protection bcrypt pbkdf2

【解决方案1】：

从 2022 年开始，最好切换到内存硬函数，例如 scrypt 或 Argon2。 Bcrypt 也可以是一种选择，但它并不难记忆。

对于 PBKDF2，使用 1000 次迭代的建议是在 2000 年提出的，现在您想要更多。

另外，你在使用 bcrypt 时应该更加小心：

另外值得注意的是，虽然 bcrypt 对于大多数类型的密码都比 PBKDF2 更强，但它在长密码短语方面落后；这是由于 bcrypt 无法使用超过密码的前 55 个字符而我们估计的成本和 NIST 的 . 密码短语熵的估计表明 bcrypt 的 55 个字符的限制不是目前可能会导致问题，依赖于系统的实施者建议 bcrypt 解决这个限制（例如，通过“预散列”密码以使其符合 55 个字符的限制）或采取措施防止用户在第 56 位及以后放置过多的密码熵字符（例如，通过要求网站用户在输入中输入他们的密码框只能容纳 55 个字符）。

From scrypt paper [PDF]

也就是说，还有scrypt。

如果没有上述 scrypt 论文中的表格，任何比较都是不完整的：

使用的 PBKDF2-HMAC-SHA256 的迭代次数有 86,000 和 4,300,000。

【讨论】：

“要求网站用户在输入框中输入密码，该输入框只能容纳 55 个字符。”对不起，但这如何适用于现实世界？我几乎想不出 8 个字符的密码。
我认识一个人，他使用一系列伟大的国际象棋游戏作为密码。他用球员的名字，日期，城市等来为序列加盐。我认识另一个使用史诗中的诗句的人，故意引入了错误。有很多方法可以获得长密码。
需要注意的是scrypt论文有错误，bcrypt的实际算法截断是72个字符。所以仍然有一个截止点，但它还有 128 位熵。这非常重要。
@ircmaxell 取决于实现（并且大多数确实接受 72 字节），但 Blowfish 的有效密钥大小为 448 位；虽然它最多可以接受 576 位（如您所说的 72 字节），但“P 数组的最后四个值不会影响密文的每一位”（引用自 Wikipedia en.wikipedia.org/wiki/Blowfish_(cipher)#The_algorithm）。
@m33lky 使用密码短语而不是密码是现实世界中正在做的事情。密码短语的长度很容易超过 55 个字符，并且通常比随机数字+字符+符号 (codinghorror.com/blog/2005/07/passwords-vs-pass-phrases.html) 更容易记住。

【解决方案2】：

评论（回复：标题）：

除非必须，否则不要使用加密（可逆）来存储密码。
由于您提出了一个散列（不可逆）选项作为替代方案，我认为您不需要可逆性。

关于使用 PBKDF2 与 Bcrypt 和我是否应该实施改变？

我的看法：

在 Bcrypt 上使用 PBKDF2。（我只是比 Blofish 更相信 SHA，无缘无故）

至于你是否应该“实施改变”，我不知道你在问什么。

进行了编辑，以更清楚地将加密/散列讨论与陈述我的偏好 w/r/t 算法分开。

【讨论】：

“实施更改”意味着将我的脚本转换为使用 bcrypt 而不是 PBKDF2 算法。
我不相信 bcrypt 是加密。这是一种基于 BLOWFISH 的单向哈希机制
BCrypt是一种散列算法。
-1。 Bcrypt 用于散列，而不是加密。您回答 hints 它用于加密（这不利于存储密码）。如果您以一种读者不会认为 Bcrypt 用于加密的方式澄清您的观点，我将迅速推翻我的投票。