在 Microsoft，我们正在禁止攻击和附近变体中最常用的密码。我们不是基于我们的用户群体，除非攻击改变，否则他们（因为系统）不会共享这些密码。

攻击列表通常来自对漏洞的研究。攻击者足够聪明，可以查看列表以找出高概率密码，然后围绕这些高频词进行暴力破解等。我们查看相同的列表以及攻击模式来确定我们的禁令列表。

希望这可以帮助。

在决定阻止新用户的密码“太常见”之前检查现有帐户密码的系统实际上会弄巧成拙。您不仅会让用户或攻击者知道密码实际上对某些帐户有效，而且对许多帐户都有效。具体来说，共性阈值 - 其中 1 个。

因此，本文中描述的方法实际上是 Microsoft 用来禁止 Microsoft 帐户和 Azure AD 的常用密码的方法。它是已知的常见和/或弱密码、暴力访问尝试中常用的密码以及被确定为过于相似的那些密码的变体的组合。

是否可以建立一个安全的系统来检查密码更新与其他人的密码并在密码太常见时拒绝它们？

有理由不这样做，但如果我的任务是防止密码被过度使用，我会收到密码，散列它，将散列存储在一个表中，与任何用户没有任何联系，甚至没有用于的文本创建哈希，或者如果它已经存在则更新计数。如果计数超过某个限制，建议用户选择另一个密码。给出可接受的密码后，将其加盐并存储用户的加盐哈希。

因此，您不是直接检查其他用户的密码，而是检查他们未加盐的哈希值。

我认为最好的办法就是检查服务器端的密码弱点，这可能是一项昂贵的操作（例如从字典中查找）。常用或检查攻击的密码也是一个不错的选择。

MS 可能首先尝试对密码进行哈希处理，并将其与不安全密码列表（实际上并未被任何真实用户使用）进行比较。如果散列失败，那么它可以尝试使用另一个 euristic查找密码强度，最后它可以拒绝或接受密码并在其非散列版本中忘记它。如果密码被拒绝，它很可能被添加到不安全的哈希列表中。

密码弱点检查还可以考虑常用的攻击，因此它必须是一种不断发展的算法。

这有两个优点：

1. 您不需要存储所有不安全密码的哈希值。
2. 您可以禁止散列中的 altogheter 冲突（例如，强密码与弱密码的散列相同）。

当然这些只是推测，我们无法知道微软这样的大公司采取的密码安全措施。

作为最终措施，与真实用户密码相比，我只会对弱密码使用不同的哈希值。

编辑：为什么即使是弱密码也应该被散列？对我来说，不需要强散列，但是散列弱密码至少可以“保护”有价值的数据。做一些简单的散列是没有成本的，但是如果有任何数据库数据泄露，你知道至少竞争对手将无法轻易逆转弱密码，这对于不使用禁令列表或在至少可能会带来一点点经济优势。

所以回答 GroundZero 评论：不，对我来说，弱密码都不应该以纯文本形式存储。无论如何，一个简单的哈希都会使公司受益。这是因为存在特定于文化的密码，收集这些信息需要大量投资，那么为什么要以易于检索的方式存储有价值的信息呢？