BCrypt 与 SHA-256 的未来网络 [关闭]答案

【问题标题】：BCrypt vs. SHA-256 for the Future of the Web [closed]BCrypt 与 SHA-256 的未来网络 [关闭]
【发布时间】：2014-01-16 14:16:56
【问题描述】：

我现在有一个 Grails Web 应用程序，它使用带有唯一盐的 SHA-256 将用户的密码存储在我的数据库中。我最近将 web 应用程序升级到了 Grails(2.3.4) 的最新版本的 Spring Security 插件 (2.0RC2)。新插件默认使用 BCrypt。我的问题是，哪个更好，他们为什么要切换到 BCrypt。我读过关于喜欢 BCrypt 和讨厌 BCrypt 的人的文章。我看到的一个直接专业人士是算法中内置了加盐，所以我不必单独存储盐。我还注意到您可以在 SHA-256 上设置迭代。根据我的阅读，很多人喜欢 BCrypt，因为您也可以为其设置迭代，但这与设置 SHA-256 的迭代有何不同？一个博客说 PBKDF2 是一个更好的选择，因为它已经过测试。但是我也听说过关于 BCrypt 的同样的事情......

【问题讨论】：

标签： grails web-applications encryption passwords cryptography

【解决方案1】：

bcrypt 和 PBKDF2 都是众所周知的算法。只要在范围内使用它们，其中任何一个都可以。

您当然可以使用 SHA-256 来使用迭代计数和盐创建类似的方案。但除非您提出自己的安全证明、测试、社区等，否则您应该使用已知或标准化的算法（如果可用）。

PBKDF2 确实在底层使用了哈希算法，因此它可以配置为 SHA-256 - 如果实现允许的话。

目前唯一的其他选择是 scrypt。 scrypt 可以说更安全，因为它依赖于相对大量的内存。因此，scrypt 更难并行化，例如使用 GPU 等向量机。

现在password hashing competition 已经完成，它提供了一些有趣的替代品，例如获胜者 Argon2。

【讨论】：

【解决方案2】：

没有“他们”，只有我 :)

您可以为 SHA-256 设置迭代计数，但它不会像增加 bcrypt 的 logrounds 值那样减慢速度。您可以使 bcrypt 变得非常慢，这确实会使用户的登录速度变慢，但这通常不是什么大问题。但是，如果您的数据库遭到破坏，那么暴力破解散列密码的成本确实会高得多。

【讨论】：

最后，bcrypt 的成本因素和 PBKDF2 的迭代次数只是定义了一个恒定的时间减速。 bcrypt 使用对数刻度并不重要——只要迭代次数足够高，PBKDF2 就可以匹配减速。 bcrypt 的成本因素可能更容易让用户理解，但它对安全性并不重要（当然，考虑到 c - PBKDF 中的迭代次数 - 对于给定的实现而言，它可能具有足够高的值）。