security - 为什么 OWASP 不建议在客户端和服务器上对密码进行加密？

Question

由于 GitHub 和 Twitter 最近出现问题:

• GitHub Accidentally Recorded Some Plaintext Passwords in Its Internal Logs
• Twitter Admits Recording Plaintext Passwords in Internal Logs, Just Like GitHub

我想知道，为什么最好的做法不是在客户端和服务器上都加密密码？由于我不会更改任何已经是服务器端最佳实践的内容(salt、强哈希、HTTPS)，因此它只会更安全。服务器会将已经散列的密码视为密码，并在存储之前再次对其进行散列。

• 如果我在抛出异常时记录整个请求，如果登录/注册请求中发生异常，我将永远无法访问用户明文密码
• 我知道，如果有人能够通过 MITM(许多公司在其专用网络中替换 SSL 证书)或通过日志或恶意服务器管理员访问这些仅客户端哈希的密码，他们就会将能够使用它在我的网站中进行身份验证，但无法访问明文密码，因此它永远不会损害用户在其他网站和服务中的帐户(即使对于那些重复使用其密码的用户)

Answer 1

客户端哈希可以完成，但我们应该考虑我们真正实现的目标。

您可能想要实现的是，当密码通过(希望是加密的 SSL)连接发送时，攻击者无法读取密码。如果攻击者可以拦截流量，那么他(她)很可能也可以更改流量，因此可以删除任何执行客户端哈希的 JavaScript。然后整个保护来自服务器端哈希。

您可以实现的是，您可以减少服务器负载，因为您让客户端执行繁重的计算。如果您可以保证客户端的完整性，则可以在客户端上进行 key 拉伸(stretch)并在服务器上使用快速哈希。对于已安装的应用程序，这可以是一个选项，但不建议用于网站，因为无法保证客户端的完整性，而且 JavaScript 通常较慢，因此您可以执行更少的轮次。

如果攻击者只能监听流量但无法更改它，您将获得一点好处。然后，您愿意花在哈希上的时间必须分为客户端部分和服务器部分(不能让用户永远等待)。服务器时间必须足够长才能保证安全，这样客户端的时间就很少了。如果您在客户端上使用太快的哈希值，则截获的密码哈希值仍处于暴力破解的范围内(尽管这是攻击者必须克服的障碍)。

所以简而言之，通常不值得这么麻烦，优势太小，时间最好投入到服务器上的哈希时间上。