客户端密码散列的安全风险

Security Risks of Cient-Side Password Hashing

本文关键字：安全密码客户端更新时间：2023-09-26

我已经阅读了大量关于正确使用密码散列的博客文章、教程和SO问题。但是我仍然有一个关于客户端哈希的风险的问题。

I want to salt &在客户端用JavaScript散列用户的密码，然后重新散列&盐渍将在服务器上完成，所有数据都通过HTTPS发送(不是纯文本)。客户端的哈希不会使用与服务器相同的盐或算法。

对服务器来说，用户的密码在逻辑上是一个散列，所以如果数据传输是明文的，那么密码是否被散列对攻击者来说并不重要。如果读取JavaScript，暴露客户端哈希，理论上更容易获得已知长度和字符的哈希(0-9 &a-f)，然后是获得可变长度和所有字母数字字符的密码，上&小写字母和特殊字符?

例如，客户端上的基本MD5哈希(我知道MD5是坏的)产生128位(16字节)哈希。所以，有16个可能的字符，那就是16^16 = 1.84e19个可能的哈希值。

密码长度为8-10个字符，可从任何字母数字或特殊字符中选择(根据维基百科的统计，这是95个字符)。得到95^8 + 95^9 + 95^10，等于6.05e19。正如您所看到的，这是密码数量的3倍多，而不是哈希(这个数字只会更高，因为您允许密码尽可能长)。

那么，不从客户端向服务器发送散列密码不是更好吗?

作为这个问题的第二部分，从阅读中，我理解像字典这样的工具可以用来在逻辑上减少这种可能性的数量。这些工具真的可以将结果缩小到低于1.84e19的哈希组合吗?

在客户端没有必要进行散列。那么你所做的就是使你的应用程序依赖于javascript。

可以读取传输的攻击者可以直接将哈希值提交给服务器，而不需要输入密码。

HTTPS在传输时完全保护用户密码。除非他们使用的无线键盘在聪明的攻击者的攻击范围内。嘿。