客户端密码散列

Question

我和我的一个朋友正在讨论是否应该在将 Web 应用程序用户的密码发送到我们的服务器之前对其进行预哈希处理。

我知道有多个问题已经处理了这个主题，但它们都是关于将它安全地传输到服务器。我们的想法不是关于传输安全性（我们使用 SSL）我们想要散列客户端以防止“真实”密码到达我们的服务器。

这个想法是在 Twitter 宣布他们的错误时出现的，该错误导致密码以明文形式打印到日志文件中。

我们目前正在讨论这个概念是否有意义，以及如果我们使用 SHA512 对其进行散列，它会如何影响密码的安全性（就蛮力而言）。

特尔；博士：

我们希望在客户端散列密码，以防止我们的服务器以明文形式获取它们（我们使用 SSL 进行传输）。

这有道理吗？
哪种算法最适合用于散列？

散列后的密码将在服务器端再次使用 bCrypt 进行散列。

Answer 1

100%是有道理的：其实这个概念已经被很多人提出了，但难点在于正确实施。如果你做错了，会有很多陷阱，最直接的一个是容易受到@swa66 描述的“传递哈希”的影响。为了防止这种情况，你需要在两边散列。客户端哈希应该很慢（bcrypt、scrypt、argon2 或 pbkdf2），而服务器端哈希应该很快（sha256）。

编辑：许多人在不了解其工作原理的情况下否决了这一点，所以我现在在这里包含基本细节（以前我只链接到它是如何工作的）。这个想法是在客户端应用一个慢散列，例如 bcrypt，然后在服务器端应用一个快速散列，例如 SHA256。需要快速散列以防止传递散列攻击。在数据库泄漏的情况下，攻击者要么通过散列来反转快速散列（不可能——违反加密散列函数的单向属性），要么将原像强行转换为快速散列（不可能——大小为慢散列输出的长度，例如 bcrypt 的 184 位），或者强力组合慢散列和快速散列——这让攻击者回到相同的位置，就好像整个计算已经发生一样服务器端。

我在保护 Web 应用程序数据库中的密码的方法中调查了许多类似的建议。此外，我分析了利弊并确定了之前未发现的弱点（帐户枚举），并提出了一种安全地执行此操作的独特方法。该研究建立在许多来源的基础上，包括：

• 安全认证：部分客户端密钥拉伸……请审查/批评我的想法
• 如何安全地散列密码？-- 请参阅客户端散列部分
• 客户端密码散列
• 来自 Hacker News 的不同作者的讨论——参见来自 oleganza、mschuster91、crusso 等的评论......

你引用了 Twitter 的例子，GitHub 也做了类似的事情。当我写上面的论文时，防止服务器看到明文密码的最突出的例子是 Heartbleed，我在论文中评论了它（第 1.3 节的底部）。

其他人随后进行了后续研究，确定了类似的想法——例如：Client-Plus-Server Password Hashing 作为一种在不使服务器过载的情况下提高针对暴力攻击的安全性的潜在方法。没有人值得所有的赞誉，但主要的结论是，如果您安全地进行操作是个好主意，但您确实需要了解风险（如果您没有阅读研究，很容易不安全地进行操作）。