在我们的留言板上，我们使用密码匹配来帮助检测具有多个注册的成员，并针对恶意傀儡帐户执行我们的规则。当我们有 SHA256 哈希和每个站点的盐时，它运行良好。但是我们最近遇到了一个令人震惊的安全漏洞，其中一些密码哈希值落入了字典攻击。所以我们强制更改密码，并切换到 bcrypt + per-user salts。
当然，现在密码匹配不再起作用了。我没有接受过密码学或计算机科学方面的正规教育，所以我想问一下是否有一种安全的方法来克服这个问题。与我一起工作的人建议使用松散散列算法的第二个密码字段，该算法故意有很多冲突，但在我看来，这要么会导致大量误报，要么会过多地减少搜索空间以确保安全。我的想法是坚持使用 bcrypt，但存储第二个密码哈希，它使用每个站点的盐和极高的迭代次数（比如在现代硬件上生成 10 多秒）。这样，具有相同密码的用户将具有相同的哈希值，但不能通过字典攻击轻易推断出来。
我只是想知道这是否有明显的问题，或者比我更有知识的人有什么建议可以更好地处理事情？在我看来它会起作用，但我了解到在安全方面可能存在很多隐藏的问题。:P 谢谢！
任何允许您检测 2 个用户是否具有相同密码的算法也将允许攻击者检测 2 个用户是否具有相同的密码。这实际上是一种预计算攻击。因此，您的问题无法安全解决。
如果我可以将您的密码转换算法应用于“密码”并快速判断哪些用户使用“密码”作为他们的密码，那么系统很容易受到某种形式的预计算攻击。
如果我必须进行昂贵的计算来确定每个用户的密码，并且计算用户 A 的密码所花费的工作不会使计算用户 B 的密码变得更容易，那么系统是安全的（针对这些类型的攻击）。
您使用带有 bcrypt 和高迭代次数的 per-site salt 的想法起初可能看起来很有吸引力，但它无法扩展。即使在 10 秒内，也就是每分钟 6 次密码猜测、每小时 360 次、每天 8640 次或每年 3M 次（很多）。这只是一台机器。在那个问题上抛出一个机器僵尸网络，或者一些 GPU，然后这个数字突然变得暴涨。仅 300 台机器/内核/GPU 就可以在一天内淘汰 250 万次猜测。
因为您将为每个人使用相同的盐，所以您允许攻击者一次破解所有用户的密码。通过只使用每个用户的盐，攻击者一次只能有效地尝试破解单个用户的密码。
上面给出的简短答案假设攻击者始终拥有与服务器相同的访问权限，这可能是不合理的。如果服务器以永久性方式（由攻击者拥有）受到破坏，那么任何方案都无法拯救您 - 攻击者可以检索用户设置的所有密码。该模型更常见的是攻击者能够在有限的时间内访问您的服务器，即在服务器上线后的某个时间点。这引入了一个机会，可以在不提供对攻击者有用的信息的情况下执行您所询问的密码匹配。
如果在注册或更改密码时，您的服务器可以访问纯文本密码，那么服务器可以遍历系统上的所有用户帐户，使用每个用户的个人盐对新密码进行哈希处理，并测试它们是否是相同。
这不会引入任何弱点，但只有当您的防止多个虚假帐户的算法可以将其用作一次性输入（“此密码与这些帐户匹配”）时，它才会对您有用。
Storing that information for later analysis would obviously be a weakness (for if an attacker can obtain your database of passwords, they can probably also obtain this list of accounts with the same password). A middle ground might be to store the information for daily review - reducing the total useful information available to an attacker who temporarily compromises your storage.
All of this is moot if the salting and hashing occurs client-side - then the server can't carry out the test.