1

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

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

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

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

4

2 回答 2

4

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

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

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

为了在上面加上一些实际的数字，我们将从这个演示文稿中提取。

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。而且不用担心字数限制

于 2014-10-13T11:11:03.790 回答
2

这并不重要。

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

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

这意味着：

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

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

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

于 2014-10-11T14:15:41.710 回答