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

Question

我打算在新的Web应用程序中使用jBCrypt进行密码哈希，因为它应该是我读过的最好的。因为我在调查之前是否有任何理由不使用它。

我有这个：

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

Answer 1

jBcrypt作为密码的加密算法可能不错;河豚比较强壮。虽然Blowfish本身有一些报道的实施缺陷，但我没有发现任何关于jBcrypt的报道。另一方面，Blowfish的测试几乎没有其他算法那么严重，并且crack式的已知plaintxt攻击通常比预期更好，令人惊讶的加密极客。

所以这就是我的建议：

• 继续使用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列表为空。