【发布时间】：2025-12-10 09:50:02
【问题描述】：
我已经阅读了大量关于正确密码散列的所有博客文章、教程和 SO 问题。但是我还有一个关于客户端散列的风险的问题。
我想用 JavaScript 在客户端对用户密码进行加盐和散列处理，然后在服务器上进行重新散列和加盐处理，所有数据都通过 HTTPS（非纯文本）发送。客户端的散列不会使用与服务器相同的盐或算法。
从逻辑上讲，对于服务器来说，用户的密码是一个散列，所以如果数据传输是纯文本的，那么密码是否被散列到攻击者都没有关系。如果读取 JavaScript，暴露客户端哈希，理论上是否更容易获得已知长度和字符（0-9 和 af）的哈希，然后是获得可变长度和所有字母数字字符的密码、大小写和特殊字符？
例如，客户端的基本 MD5 散列（我知道 MD5 不好）会产生 128 位（16 字节）散列。因此，如果有 16 个可能的字符，则有 16^16 = 1.84e19 个可能的哈希值。
密码长度为 8-10 个字符，可以从任何字母数字或特殊字符中选择（Wikipedia's count，即 95）。得到 95^8 + 95^9 + 95^10，等于 6.05e19。正如您所看到的，这是密码数量的 3 倍多，是哈希值的 3 倍多（而且这个数字只会在您允许密码的时候变得更高）。
那么不从客户端向服务器发送散列密码不是更好吗？
作为这个问题的第二部分，从阅读资料中，我了解到可以使用字典等工具从逻辑上减少这种可能性。这些工具真的可以将结果缩小到 1.84e19 哈希组合以下吗？
【问题讨论】：
-
有什么意义？如果您不是信息安全专家，请不要试图成为一名信息安全专家。找出当前的最佳做法是什么，然后去做。
-
等等——你是说你想对密码进行哈希处理，但这个问题是关于为什么你想这样做可能是错误的？如果是这样，在我看来，是的。让您的登录页面使用 TLS (https) 并依赖它。
标签： php javascript security web-applications hash