为什么OWASP不建议在客户端和服务器上都加密密码？

Question

自从最近GitHub和Twitter出现问题以来：

• GitHub无意中在其内部日志中记录了一些明文密码
• 推特承认在内部日志中记录明文密码，就像GitHub一样

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

• 如果在引发异常时记录整个请求，如果在登录/注册请求中出现异常，我将永远无法访问用户明文密码。
• 我知道，如果有人能够访问这些只有客户端的散列密码，无论是通过MITM (许多公司在其私有网络中替换SSL证书)，还是通过日志或恶意服务器管理员，他们都可以使用它在我的站点上进行身份验证，但不能访问明文密码，因此它不会损害用户在其他站点和服务中的帐户(即使是那些重用他们的密码的用户)。

Answer 1

我希望解决一个类似的问题，即纯文本密码可以登录到服务器上。结论是，如果可以的话，应该始终附加散列客户端密码。

下面是一些关于client-plus-server散列的文章：

Client-Plus-Server密码散列作为一种可能的方法，可以在不重载服务器的情况下提高对Brute Force攻击的安全性

盐渍密码散列-正确处理

具体见：

在Web应用程序中，总是在服务器上散列 如果您正在编写一个web应用程序，您可能想知道在哪里散列。应该使用JavaScript在用户浏览器中对密码进行散列，还是应该将密码“清空”发送到服务器并在其中进行散列？ 即使您正在JavaScript中哈希用户的密码，您仍然必须在服务器上散列哈希。考虑一个在用户浏览器中对用户密码进行散列而不对服务器上的哈希进行散列的网站。要对用户进行身份验证，此网站将接受浏览器中的哈希，并检查该哈希是否与数据库中的哈希完全匹配。这似乎比仅仅在服务器上散列更安全，因为用户的密码从未发送到服务器，但它不是。 问题是客户端哈希逻辑上成为用户的密码。用户只需告诉服务器密码的散列即可进行身份验证。如果一个坏人得到了一个用户的哈希，他们可以使用它来验证到服务器，而不知道用户的密码！因此，如果坏人以某种方式从这个假想的网站窃取哈希数据库，他们就可以立即访问每个人的帐户，而不必猜测任何密码。 --这并不是说您不应该在浏览器中散列，但是如果您这样做了，您肯定也必须在服务器上散列。在浏览器中进行哈希无疑是个好主意，但请考虑下面几点用于您的实现： 客户端密码散列不能代替HTTPS (SSL/TLS)。如果浏览器和服务器之间的连接不安全，中间人可以在下载JavaScript代码时修改它，以删除散列功能并获取用户密码。 有些浏览器不支持JavaScript，有些用户在浏览器中禁用JavaScript。因此，为了实现最大的兼容性，您的应用程序应该检测浏览器是否支持JavaScript，并在服务器上模拟客户端哈希(如果不支持)。 你也需要对客户端的哈希进行盐化。显而易见的解决方案是让客户端脚本向服务器询问用户的salt。不要这么做，因为它让坏人在不知道密码的情况下检查用户名是否有效。因为您也在服务器上进行散列和盐化(使用良好的盐分)，所以可以使用用户名(或电子邮件)与站点特定的字符串(例如域名)连接作为客户端盐。

经过研究发现，对客户端进行散列也具有明显的安全性。如果HTTPS上的密码被泄露，或者密码登录在服务器上，那么纯文本密码就不能轻易地在用户的其他帐户上重用(许多用户重复使用他们的密码)。

唯一可能的缺点是客户端性能和服务器端密码验证。用户可以操纵您的客户端JS并提交“弱”密码。服务器就不会知道更多了。但我认为这是一个小问题，它依赖于人们故意修改客户端代码，以削弱自己的安全性。

Answer 2

客户端散列是可以完成的，但是我们应该考虑我们真正实现了什么。

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

您可以实现的是，您可以减少服务器负载，因为您让客户端做繁重的计算。如果您能够保证客户端的完整性，那么您就可以在客户机上进行键拉伸，并在服务器上使用快速散列。在安装了应用程序的情况下，这可以是一个选项，但不推荐在网站上使用，因为不能保证客户端的完整性，而且JavaScript通常比较慢，所以可以执行更少的操作。

如果攻击者只能侦听通信量，但不能更改流量，则会得到很小的好处。您愿意花在散列上的时间必须分为客户端部分和服务器部分(不能让用户永远等待)。服务器时间必须足够长，以确保安全，这给客户端留下了很少的时间。如果您在客户端上使用了太快的哈希，那么被截获的密码哈希仍然处于强制强制的范围内(尽管攻击者必须采取这一障碍)。

因此，总之，它通常不值得麻烦，优势太小，时间更好地投资在哈希时间在服务器上。

Answer 3

任何哈希(包括bcrypt)都需要秘密的盐读这里来获取更多细节。如果该salt丢失，客户端将无法创建相同的散列--这与丢失密码相同。因此，您需要创建一种允许所有客户安全获取盐的机制。你需要确保黑客不会得到这种盐。这是相当复杂的实现。

另一件需要考虑的事情是终端用户设备的限制--例如，Android设备的CPU相当弱，而且功能远远不如普通服务器。由于bcrypt的主要优点是计算哈希所需的时间，所以您需要选择参数，以便一个好的服务器(甚至使用GPU)能够在一个缓慢的时间内计算它(假设，对于20个字符的密码，> 1s )。这使得我们很难创造出那些彩虹桌。

因此，除非您能够保证所有用户都运行在足够强大的设备上，否则不建议在客户端执行bcrypt操作。