客户端密码哈希与纯文本答案

【问题标题】：Client side password hash versus plain text客户端密码哈希与纯文本
【发布时间】：2015-08-23 17:59:44
【问题描述】：

我正在将一个 android 客户端（可能在未来的 iOS、门户网站等）和 php mysql 服务器放在一起。服务器端我目前正在使用 PHPass 库对传入的密码进行散列和加盐。

我应该让客户端通过 HTTPS/SSL 发送纯文本密码，还是应该让客户端先进行某种形式的散列。例如，每个客户端是否应该简单地对每个传出密码进行 sha1（或其他算法）？

【问题讨论】：

也请考虑在security.stackexchange.com发帖
这里已经介绍了很多。请参阅 Does it make security sense to hash password on client end、stackoverflow.com/questions/3715920 和 stackoverflow.com/questions/6553363。从安全的角度来看，客户端就是客户端，无论是浏览器还是应用程序。应用程序比客户端代码更难破解，但仍然完全不安全。
是的，您应该在客户端和服务器端都进行哈希处理。没有理由不至少在客户端使用恒定盐进行散列，尤其是对于您的情况的移动应用程序。见medium.com/@harwoeck/…

【解决方案1】：

大多数网站将通过加密连接 SSL/HTTPS 发送纯文本密码。可以在客户端对密码进行散列，但优点是很小，而且客户端语言（JavaScrypt）通常很慢，因此您可以同时计算更少的轮次，这会削弱散列。在每种情况下，服务器都必须计算哈希以确保安全。

优势很小，因为如果攻击者可以进行 ManInTheMiddle 攻击，他还可以修改/删除执行散列的脚本 (JS)。只有使用 SSL/HTTPS 的加密连接才能防止 MITM 攻击，因此无论如何您都需要 SSL。

对于您的应用，它看起来略有不同。因为用户首先要安装您的软件，所以无需向客户端发送脚本，因此 MITM 无法修改此脚本。此外，该应用程序可以相对快速地计算哈希（如果它可以运行本机代码），因此可以在客户端执行足够多的轮次。

这就是我会做的：

为方便起见，通过加密的 SSL/HTTPS 连接发送纯文本密码并计算慢速 BCrypt 哈希服务器端，就像您现在所做的那样。
只有当服务器上的负载变得太重时，您才可以将慢速 BCrypt 哈希的计算转移到客户端应用程序中。仍然使用 HTTPS 发送哈希，然后在服务器上计算一个额外的快速哈希（例如 SHA-256）。这更复杂，因为您必须单独更换和储存盐。

【讨论】：

【解决方案2】：

在客户端散列密码的另一个缺点是您无法更改散列算法或迭代计数，而无需更新您的客户端。

对于没有问题的 JavaScript 客户端，但您不能轻易保证您的用户将使用最新版本的本地客户端。

所以我会坚持通过 HTTPS 发送纯密码。

【讨论】：