我和我的一个朋友正在讨论是否应该在将 Web 应用程序用户的密码发送到我们的服务器之前对其进行预哈希处理。
我知道有多个问题已经解决了这个主题，但它们都是关于将其安全地传输到服务器。我们的想法不是关于传输安全性（我们使用 SSL），我们希望对客户端进行哈希处理，以防止“真实”密码到达我们的服务器。
这个想法是在 Twitter 宣布他们的错误导致密码以明文形式打印到日志文件时产生的。
我们目前正在讨论这个概念是否有意义，以及如果我们使用 SHA512 对其进行哈希处理，它会如何影响密码的安全性（就暴力破解而言）。
TL;DR:
我们希望在客户端对密码进行哈希处理，以防止我们的服务器以明文形式获取密码（我们使用 SSL 进行传输）。
这有意义吗？
什么算法最适合用于哈希？
然后，服务器端将使用 bCrypt 再次对经过哈希处理的密码进行哈希处理。
它100%有道理：事实上，这个概念已经有很多人提出了，但困难在于正确实施。如果你做错了，就会出现很多陷阱，最直接的一个就是容易受到 @swa66 描述的“传递哈希”的影响。为了防止这种情况，您需要对双方进行哈希处理。客户端哈希应该较慢（bcrypt、scrypt、argon2 或 pbkdf2），而服务器端哈希应该较快（sha256）。
EDIT：许多人在不了解其工作原理的情况下对此投了反对票，因此我现在在此处包含基本细节（之前我仅链接到其工作原理）。这个想法是在客户端应用 bcrypt 等慢速哈希，然后在服务器端应用 SHA256 等快速哈希。需要快速哈希来防止传递哈希攻击。如果发生数据库泄漏，攻击者要么通过散列来反转快速散列（不可能——违反了加密散列函数的单向属性），要么将原像强力强制为快速散列（不可能——大小为慢速散列的输出长度，例如 bcrypt 的 184 位），或暴力破解慢速散列和快速散列的组合 - 这使攻击者回到相同的位置，就好像整个计算已经发生一样服务器端。因此，我们并没有通过将繁重的计算转移到客户端来降低数据库泄漏时密码攻击的安全性。
我调查了许多这样的提案保护Web应用程序数据库密码的方法 https://eprint.iacr.org/2015/387.pdf。此外，我还分析了优点和缺点，并找出了之前未发现的弱点（帐户枚举），并提出了一种安全地执行此操作的独特方法。该研究基于多种来源，包括：
- 安全身份验证：部分客户端密钥拉伸......请审查/批评我的想法 https://security.stackexchange.com/questions/43023/secure-authentication-partial-client-side-key-stretching-please-review-criti
-
如何安全地散列密码？ https://security.stackexchange.com/a/31846-- 请参阅客户端哈希部分
- 客户端密码哈希 https://security.stackexchange.com/questions/23006/client-side-password-hashing/23012
-
Hacker News 上不同作者的讨论 https://news.ycombinator.com/item?id=7626587-- 请参阅 oleganza、mschuster91、crusso 等的评论...
你引用了 Twitter 的例子，GitHub 也做了类似的事情。当我写上面的论文时，防止服务器看到明文密码的最突出的例子是 Heartbleed，我在论文中对此进行了评论（第 1.3 节的底部）。
其他人随后进行了后续研究，发现了类似的想法——示例：客户端加服务器密码散列作为提高安全性以防止暴力攻击而不会使服务器过载的潜在方法 http://ithare.com/client-plus-server-password-hashing-as-a-potential-way-to-improve-security-against-brute-force-attacks-without-overloading-server/。没有人值得所有的功劳，但主要的结论是，如果你安全地做到这一点，这是一个好主意，但你确实需要了解风险（如果你没有阅读研究，很容易不安全地做到这一点）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
