使用什么来进行密码哈希？ 有什么理由不使用jBCrypt？

Question

我计划在新的 Web 应用程序中使用 jBCrypt 进行密码哈希处理，正如预期的那样成为我读过的最好的。 因为我之前没有使用过它，所以我正在研究是否有任何理由不使用它。

我有这个：

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

Answer 1

jBcrypt 作为密码的加密算法可能很不错； 河豚的实力比较强。 尽管 Blowfish 本身存在一些报告的实现缺陷，但我没有找到任何有关 jBcrypt 的报告。 另一方面，Blowfish 并没有像其他算法那样经过严格的测试，并且

因此，我的建议是：

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

Answer 2

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

但这已经完成了：

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

仔细研究 JUnit 测试，看看它们是否满足您的满意程度，这就是我要开始的地方......

Answer 3

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

我不熟悉 Maven，但是（异端警报！）我怀疑您是否需要像 bcrypt 这样简单的组件的版本控制。 引用该网站的话，从 v0.1 到 v0.2 的变化是“正确性、拼写错误和 API 调整（完全向后兼容）”，并且 TODO 列表为空。