如何安全地检测具有匹配密码的帐户？

Question

在我们的留言板上，我们使用密码匹配来帮助检测具有多个注册的成员，并针对恶意 puppet 帐户执行我们的规则。当我们有 SHA256 哈希和每个站点的盐时，它运行良好。但我们最近遇到了一个令人震惊的安全漏洞，其中一些密码哈希值落入了字典攻击。所以我们强制更改密码，并切换到 bcrypt + per-user salts。

当然，现在密码匹配不再起作用了。我没有接受过密码学或计算机科学方面的正规教育，所以我想问一下是否有一种安全的方法来克服这个问题。与我一起工作的人建议使用松散散列算法的第二个密码字段，该算法故意有很多冲突，但在我看来，这要么会导致大量误报，要么会过多地减少搜索空间以确保安全。我的想法是坚持使用 bcrypt，但存储第二个密码哈希，它使用每个站点的盐和极高的迭代次数（比如在现代硬件上生成 10 多秒）。这样，具有相同密码的用户将具有相同的哈希值，但不能通过字典攻击轻易推断出来。

我只是想知道这是否存在明显的问题，或者是否有比我知识渊博的人对更好的处理方式有任何建议？在我看来它会起作用，但我了解到在安全方面可能存在很多隐藏的问题。 :P 谢谢！

Answer 1

简答

任何允许您检测 2 个用户是否具有相同密码的算法也将允许攻击者检测 2 个用户是否具有相同的密码。这实际上是一种预计算攻击。因此，您的问题无法安全解决。

示例

• 假设我已经破坏了您的密码数据库。
• 假设我已经知道如何计算您的哈希值。

如果我可以将您的密码转换算法应用于“密码”并快速判断哪些用户使用“密码”作为他们的密码，那么系统很容易受到某种形式的预计算攻击。

如果我必须进行昂贵的计算来确定每个用户的密码，并且计算用户 A 的密码所花费的工作不会使计算用户 B 的密码变得更容易，那么系统是安全的（可以抵御此类攻击）。

进一步考虑

您使用带有 bcrypt 和高迭代次数的 per-site salt 的想法起初可能看起来很有吸引力，但它无法扩展。即使在 10 秒内，也就是每分钟 6 次密码猜测、每小时 360 次、每天 8640 次或每年 3M 次（很多）。这只是一台机器。在那个问题上抛出一个机器僵尸网络，或者一些 GPU 的，突然这个数字就飙升了。仅 300 台机器/内核/GPU 一天就可以消除 250 万次猜测。

因为您将为每个人使用相同的盐，所以您允许攻击者一次破解您所有用户的密码。通过只使用每个用户的盐，攻击者一次只能有效地尝试破解单个用户的密码。

Answer 2

上面给出的简短答案假设攻击者始终拥有与服务器相同的访问权限，这可能是不合理的。如果服务器以永久方式（由攻击者拥有）受到破坏，那么没有任何方案可以拯救您 - 攻击者可以检索用户设置的所有密码。该模型更常见的是攻击者能够在有限时间段内访问您的服务器，即在服务器上线后的某个时间点。这带来了一个机会，可以在不提供对攻击者有用的信息的情况下执行您所询问的密码匹配。

如果在注册或更改密码时，您的服务器可以访问纯文本密码，则服务器可以遍历系统上的所有用户帐户，使用每个用户的个人盐对新密码进行哈希处理，并进行测试以查看如果它们是相同的。

这不会引入任何弱点，但只有当您的防止多个虚假帐户的算法可以将其用作一次性输入（“此密码与这些帐户匹配”）时，它才会对您有用。

存储该信息以供以后分析显然是一个弱点（因为如果攻击者可以获得您的密码数据库，他们可能也可以获得具有相同密码的帐户列表）。中间立场可能是存储信息以供日常查看 - 减少临时破坏您的存储的攻击者可用的总有用信息。

如果加盐和散列发生在客户端，那么所有这些都没有实际意义 - 然后服务器无法执行测试。