BCrypt vs PBKDF2WithHmacSHA1 [关闭]

Question

为了安全地散列密码，我应该使用哪种算法？ BCrypt 或 PBKDF2WithHmacSHA1?

哪个更安全？ PBKDF2WithHmacSHA1 内置于 Java 中，而 BCrypt 可通过 jBCrypt 库获得（大部分都获得了正面评价）。

另外，如果我使用BCrypt，我是否应该将用户的密码输入限制为 55 个字符（因为这是BCrypt 的限制）？

如果您是 Java 特定的，那将会很有帮助。
请注意，我会选择使密码更安全且暴力破解更困难的选项。

Answer 1

它们不一样，也不是同样安全。

在 CPU 上，它们使用的资源量大致相同，并且在保护密码方面也大致相同。

问题归结为基于 GPU 的攻击。由于 GPU 的架构，bcrypt 实际上比 SHA1（或 SHA256）更难运行。因此，并行化 PBKDF2 + sha1 比并行化 bcrypt 更容易。

要添加一些实际数字，我们将从This presentation 中抽取。

Sha-1 比 md5 贵 3 倍左右。因此，如果我们查看慢速散列函数幻灯片，我们可以得出结论，md5crypt 比 pbkdf2-sha1 快约 3 倍。这是相当多的猜测，但它在我们正在寻找的边缘。

这意味着，对于同等 CPU 运行时，我们可以预期 PBKDF2-sha1 在 GPU 集群上每秒运行大约 2500 万次哈希。将其与每秒运行 75 千哈希的 BCrypt（成本为 5）进行比较。

这意味着 PBKDF2+sha1 在同等成本设置下比 bcrypt 弱约 1000 倍。

请注意，PBDFK2+sha512 几乎与 bcrypt 一样慢。这与使用 64 位操作的 SHA-512 （在当今的 GPU 中不是本机的）有关。

简而言之，bcrypt 比 PBKDF2+SHA1 安全几个数量级。它比 PBKDF2+SHA512 更安全，但差距不大。

这依赖于当今的 GPU 架构。将来，如果缓存大小和指令集发生显着变化，这些差异可能会消失。这就是为什么存在像 scrypt 这样的新算法的原因。

所以只需使用 bcrypt。 And don't worry about the character limit

Answer 2

没关系。

他们两者的安全性差异不足以得出有意义的选择。但是，如果您正在寻找彻底的讨论，请查看 Eugene 的 cmets 中的两个链接

重要的是你正确地对待他们。

这意味着：

• 选择正确的成本因数/迭代次数。如果你是彻底的，你会想要对你的服务器可以容忍的散列函数有多慢进行基准测试。越慢（=更高的成本因素/迭代次数）越好。为了给你一个大概的数字，我的全盘加密软件已经确定带有 HmacSHA1 的 PBKDF2 需要大约 10000 次迭代才能运行 50 毫秒。
• 正确使用 salt：每个密码都需要一个随附的随机值 (salt)，您将其存储在散列旁边并用作每个散列的输入。不要对每个密码都使用相同的盐，that would be pepper，这很好，但不能替代盐。
• 以可升级的方式存储您的密码。稍后，您可能想要更改成本因子或添加胡椒值或将散列方案更改为 scrypt，一旦它被广泛接受。为此，数据库条目需要告知使用哪个参数选择来生成密码。例如，请参阅this commonly used unix passwords storage format。

“另外，如果我使用 BCrypt，我是否应该将用户的密码输入限制为 55 个字符（因为这是 BCrypt 的限制）？”

没有。使用 SHA1 或 SHA256 对密码进行一次哈希处理，然后像之前使用密码一样使用输出。如果你想涂胡椒粉，这里就是最好的选择。最后，如果这听起来很麻烦，这可能是使用 PBKDF2 而不是 bcrypt 的决定因素。