我已经阅读了大量的博客文章、教程和 SO 问题，这些问题与正确的密码散列有关。但是我仍然有一个关于客户端散列的风险的问题。
我想用 JavaScript 在客户端对用户的密码进行加盐和散列，然后在服务器上进行重新散列和加盐，所有数据都通过 HTTPS 发送（非纯文本）。客户端的散列不会使用与服务器相同的盐或算法。
从逻辑上讲，对于服务器来说，用户的密码是一个散列，所以如果数据传输是纯文本的，那么密码是否被散列到攻击者都没有关系。如果读取JavaScript，暴露客户端散列，理论上更容易获得已知长度和字符（0-9 & af）的散列，那么它是获得可变长度的密码和所有字母数字字符，大写&小写字母和特殊字符？
例如，客户端的基本 MD5 散列（我知道 MD5 不好）会产生一个 128 位（16 字节）的散列。因此，对于 16 个可能的字符，即 16^16 = 1.84e19 个可能的哈希值。
使用长度为 8-10 个字符的密码，从任何字母数字或特殊字符中选择（根据维基百科的计数，即 95）。得到 95^8 + 95^9 + 95^10，等于 6.05e19。正如您所看到的，这是密码数量的 3 倍多，是哈希值的 3 倍多（并且这个数字只会在您允许密码的时候变得更高）。
那么不将散列密码从客户端发送到服务器不是更好吗？
作为这个问题的第二部分，从阅读资料中，我了解到可以使用字典等工具从逻辑上减少这种可能性。这些工具真的可以将结果缩小到 1.84e19 哈希组合以下吗？