理论上，您希望运行与攻击者相同的工具。攻击者将根据他所知道的或对用户心理的猜测来运行“可能的密码”列表。John the Ripper是一款著名的密码破解软件，其中包含大量“常用密码”和用户常用的用于导出机智密码的规则。

您的优势是服务器代码在用户注册时可以访问密码本身。与攻击者必须通过潜在的昂贵散列过程运行每个猜测相反（如果您将bcrypt迭代计数调到最大功率可能会很重），您的代码可以处理实际的东西并进行一些优化，例如，你建议，规范化为小写。

但是，我认为这在一般情况下不是一个好主意。攻击者不仅限于公开可用的软件；他可以将他的潜在密码列表调整为实际目标（例如，围绕密码受到攻击者攻击的特定用户的孩子的名字使用更多的推导）。即使跟上“常见的弱密码”列表也可能是一个令人厌烦的过程。此外，用户自己也将进入游戏：由于用户认为密码限制是一个令人讨厌的障碍，他们将使用他们所有的创造力来寻找更聪明的密码生成规则来逃避你的测试。

在服务器上执行复杂的密码排除规则以某种方式在攻击者的战场上与攻击者作战，并将用户带入盛宴；用户可能不幸（并且无意地）帮助了攻击者。

因此，我建议不要使用此类规则。您需要的是用户的协作，并且您将通过对您使用的规则保持透明来获得它；用户必须能够在不进入试错过程的情况下找到“通过测试”的密码。没有什么比连续选择十个密码直到最终被严格的服务器接受更烦人的了。您不想惹恼用户，因为被惹恼的用户会帮助攻击者（他不会这样想，但这就是最终效果）。明确的规则（“至少 8 个字符，至少 1 个数字”）对于教学法来说要好得多。

而且，当然，没有什么比对用户进行有关非随机密码危险的适当教育和培训更好的了。

除了其他理智的做法（例如，bcrypt）之外，听起来不错。

我会使用尽可能多的密码黑名单。如果您的密码在公开的 100000 个密码列表中（或仅与该列表中的密码相差一两个字符），则它是一个错误密码，GPU 可能会击败它。也有可能有人在重复使用该密码。放宽此标准的唯一充分理由是，如果您不想让可能求助于允许使用弱密码的竞争对手的用户感到沮丧。（同样要说明的是，不要使用您自己系统中的密码来建立这个列入黑名单的密码列表——这是以明文形式存储密码，这是一个很大的不。）

此外，您可能希望创建一个密码建议功能，该功能始终生成符合您标准的密码，并在密码失败时弹出此密码。（尽管仍然需要用户输入两次。）

我还要确保您的方案不会无意中阻止强密码。例如，这是一个很棒的随机创建的 diceware 密码短语，如果一个常见的黑名单密码减少到（并且 fork 包含在您的密码短语中）fork scorn loss cope endow yin，则不应被禁止。fork

事实上，Jeff Atwood 在他的博文中提倡这种做法：https : //blog.codinghorror.com/password-rules-are-bullshit/

在他的 Discourse 角色中，他建议强制执行至少 10 个字符的长度，然后检查与长度超过 10 个字符的前 10,000 个最受欢迎的密码的匹配项。

有关其他一些好的建议，请参阅博客文章。