密码散列使用什么？有什么理由不使用 jBCrypt？答案

【问题标题】：What to use for password hashing? Any reason not to use jBCrypt?密码散列使用什么？有什么理由不使用 jBCrypt？
【发布时间】：2010-10-11 23:39:01
【问题描述】：

我计划在一个新的 Web 应用程序中使用 jBCrypt 进行密码散列，因为它应该是我所读过的最好的。因为在我调查是否有任何理由不使用它之前我没有使用它。

我有这个：

我没有在 Maven 存储库中找到它（在 mvnrepository.org 上搜索 jbcrypt 和 bcrypt），这很令人沮丧，因为我希望尽可能使用 Maven 存储库管理我的依赖项。如果 jBCrypt 是密码散列的最佳解决方案，我必须设置自己的本地存储库并以这种方式使用它。还是我只是错过了它？也许它在某个地方？
目前只有 0.2 版，但可能还是很稳定，版本号低的原因还有其他原因？

【问题讨论】：

标签： java hash crypt bcrypt jbcrypt

【解决方案1】：

至于你担心它不成熟，我建议你建立自己的 JUnit 测试，比较 jBcrypt 和更成熟的 Bcrypt 的结果，看看你是否得到相同的结果，然后贡献这些到 jBcrypt 项目。

但这已经完成了：

... 附带一组 JUnit 单元测试以验证正确的操作库和兼容性规范的 C 实现 bcrypt算法。

仔细阅读 JUnit 测试以查看它们是否满足您的满意度是我开始的地方...

【讨论】：

是的，我有。 JUnit 测试仍然非常有限，并且基于测试方法中的硬编码值。因此，如果我不将这些值与 BCrypt 的值进行比较，我仍然无法确定这些值实际上来自 BCrypt（我确定它们是）。

【解决方案2】：

jBcrypt 作为密码的加密算法可能很好；河豚比较强。尽管在 Blowfish 本身中报告了一些实现缺陷，但我没有发现任何关于 jBcrypt 的报道。另一方面，Blowfish 并没有像其他算法那样经过大量测试，crack 风格的 known-plaintxt 攻击通常比预期的效果更好，这让加密极客感到惊讶。

所以这是我的建议：

继续使用 jBcrypt，但在合理范围内保护您的加密密码文件 - 就像在 UNIX 系统上使用 /etc/shadow 一样。
与 Nikhil 的建议相反，我会将源代码拉入您的版本控制，原因有两个：(1) 您将它们保留在哪里，因为您在构建时需要它们，以及 (2 ) 因为做 jBcrypt 的人总是有机会会继续做其他事情，而且你不希望在交付前发现自己悬而未决（这在你发现时是不可避免的。 ) 在这种情况下，我会将源代码放入您的版本控制中，就好像它们是您的代码一样，然后可以插入任何更改，就好像您自己构建了一个新版本一样。无需比平时更复杂。

【讨论】：

是的，它现在在我的版本控制中。我应该用谷歌搜索 Blowfish 的这些已知弱点，因为这对我来说是新闻。关于“破解式已知明文攻击”，您的意思是暴力字典式攻击吗？如果这就是演员阵容，这就是我想使用 Blowfish 的全部原因，因为它的算法很慢。
不，查看 Alec Muffet 的破解：它预先计算了一个包含常用密码的大字典，然后比较密文。并不是说 Blowfish 有已知的缺陷，而是一些实现被报告有缺陷。
嗯，好的。但我正在使用密码加盐，因此不应该以这种方式进行字典攻击。
passwd(1) 也是如此。无论如何，亚历克都击败了它。但是已知明文攻击和字典攻击是不同的东西。 en.wikipedia.org/wiki/Known-plaintext_attack en.wikipedia.org/wiki/Dictionary_attack

【解决方案3】：

我怀疑稳定性是否会成为一个问题，因为 bcrypt 本身已经成熟，而且它的小型标准化包装器并没有做任何特别的事情。我对 Damien Miller 的另一个 bcrypt 包装器 python-bcrypt 很满意，它仅在 0.1 版上。

我不熟悉 Maven，但是（异端警告！）我怀疑您需要对像 bcrypt 这样简单的组件进行版本控制。引用该网站的话，从 v0.1 到 v0.2 的更改是“正确性、错字和 API 调整（完全向后兼容）”，TODO 列表是空的。

【讨论】：

jBcrypt 实际上不是包装器。这是一个本机实现。我现在正在使用它，我将源代码合并到项目中。