我仍然认为客户端的哈希密码更好。我错了吗？

Question

我读过这些：

...而且我仍然认为在客户端哈希您的密码会更好。让我解释。

引用的第一篇文章主张您应该使登录页面独立，因为无法信任客户端使用的整个代码库。我认为这是有道理的。

并且，如果有道理，您如何信任服务器端使用的整个代码库？

上面有很多如此高调的答案声称“由于TLS存在，所以不要在客户端进行哈希处理”。确实可以防止密码被窃听，但是与我们的潜在恶意服务器端代码无关。

另外，如果已经对密码进行了哈希处理，则服务器端也无理由对其进行哈希处理。如果您的服务器被破解，则无论密码如何，您都已经完成了，但是破解者无法在其他任何地方使用获得的密码。

但是，由于我找不到这样的答案，因此我的发言似乎从根本上是错误的。我想念什么？

Answer 1

如果您认为使用工作负载因子/迭代次数较高的现代密码哈希算法（例如PBKDF2，BCrypt，SCrypt或Argon2）对客户端和服务器端进行哈希运算效果更好，那么我同意。

如果您认为仅在客户端进行哈希处理更好，那么我对您的威胁模型持严重保留意见。

服务器端可以防止散列密码的威胁，而客户端可以防止哈希密码的威胁。这是一个简短的清单：

两者：泄露的密码数据库条目使查看者可以查看用户以明文形式输入的内容。
客户：具有数据包/流量拦截访问权限的服务器端内部人员可以查看用户直接输入的内容
- 这是客户端哈希除服务器哈希之外的两个主要威胁之一，非常适合缓解。
服务器：具有数据库访问权限的内部人员可以假冒实际用户
- 如果仅在客户端对密码进行哈希处理，则可以通过客户端请求将服务器数据库中的所有内容提供给系统，以根据服务器以“合法”用户身份登录。这将使所有服务器审核日志记录谁做了什么。
- 如果密码是在服务器端经过哈希处理的，则无论客户端发生了什么，如果通过正常的身份验证通道进行输入，则服务器中的内容都不会对用户进行身份验证。
客户：MitM攻击会看到用户实际输入的内容
- 这是客户端哈希除服务器哈希之外的另一主要威胁，非常适合缓解。
- MitM攻击可能来自客户端的公司IT部门，网络提供商或其他ISP，服务器组织的IT部门（负载平衡器或具有实际证书密钥的高级安全设备等），或许多其他来源。
不需要：MitM攻击者会假冒实际用户
- 无论您是否对客户端进行哈希处理，通过网络发送到服务器应用程序的内容都是服务器用来对您进行身份验证的内容。

我认为这不是信任客户的情况。你是对的，如果有人修改他们的客户端以降低其安全性，那么他们可以在一定程度上（但不是完全）降低自己帐户的安全性。如果他们以明文形式发送服务器密码，我认为服务器不应该竭尽全力（并且服务器上的 PKBDF2 具有任何非平凡的迭代次数都是很大的长度）来阻止它们。我认为你对服务器端哈希加盐的论点是聪明且有用的（我必须考虑将其添加到我的列表中），但在这种情况下为什么使用 HMAC 而不仅仅是 SHA？ (2认同)