我已经阅读了大量关于正确密码哈希的博客文章，教程和SO问题。但我仍然有一个关于客户端哈希风险的问题。
我想加盐和盐在JavaScript中对客户端的用户密码进行哈希处理，然后重新哈希＆amp; salting将在服务器上完成，所有数据都通过HTTPS发送（无纯文本）。客户端的散列不会使用与服务器相同的盐或算法。
逻辑上到服务器的用户密码是一个哈希值，所以如果数据传输是纯文本的，那么密码是否被哈希处理到攻击者并不重要。如果读取JavaScript，暴露客户端散列，理论上更容易获得已知长度和字符（0-9＆amp; 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倍以上（并且只有在您需要密码时，此数字才会更高）。
那么不从客户端向服务器发送散列密码不是更好吗？
作为这个问题的第二部分，从阅读中，我理解词典等工具可以用来逻辑上减少这种可能性。这些工具能否真正缩小低于1.84e19哈希组合的结果？
答案 0 :(得分：1)
客户端没有任何哈希值。然后你所做的就是让你的应用程序依赖javascript。
可以读取传输的攻击者只需将哈希直接提交给服务器，从不需要输入密码。
HTTPS在传输时完全保护用户密码。除非他们在聪明的攻击者范围内使用无线键盘。 HEH。