您的主要三个很好，实际上前两个就足够了，只要实现技术扎实。

不允许高速蛮力尝试！在一两分钟内尝试三到五次失败应该会完全阻止 IP 地址30-60 分钟。这对于人类等待合法错误来说足够短，但足够长以有效地关闭大多数蛮力尝试。数周到数月的高动机低速攻击不太可能，但即使这样也可以通过总错误计数检测来处理，但实际上这是矫枉过正。只是挡住高速。

确保您没有创建 SQL 注入机制。实际上，无论复杂性如何，这都适用。

您还可以采取其他更极端的安全措施，但这两个解决了迄今为止最常见的攻击方法。

在我看来，强调极端密码复杂性的“最佳实践”是错误的。银行 ATM 通过阻止蛮力尝试成功地使用微不足道的密码。

你问：

我想知道什么被认为是允许用户设置密码的现代最佳实践。

我的首选是NIST 特别出版物 800-63B：数字身份指南认证和生命周期管理，第 5.1.1 节记忆的秘密。

以下是该文件的一些相关摘录：

5.1.1.1 记忆的秘密认证器

如果订户选择，记忆的秘密长度应至少为 8 个字符。CSP 或验证者随机选择的记忆秘密的长度应至少为 6 个字符，并且可以完全是数字。如果 CSP 或验证者基于其出现在受损值黑名单上而不允许选择的记忆秘密，则应要求订户选择不同的记忆秘密。不应对记忆秘密施加其他复杂性要求。附录 A 记忆秘密的强度给出了这样做的理由。

...

5.1.1.2 记忆的秘密验证者

在处理建立和更改记忆秘密的请求时，验证者应将预期秘密与包含已知常用、预期或泄露的值的列表进行比较。例如，列表可能包括但不限于：

• 从以前的违规语料库中获得的密码。
• 字典单词。
• 重复或连续的字符（例如'aaaaaa'、'1234abcd'）。
• 特定于上下文的词，例如服务名称、用户名及其派生词。

zxcvbn 等工具（github.com/dropbox/zxcvbn. demo at lowe.github.io/tryzxcvbn，感谢@fread2281）包括基于字典的黑名单和常见序列检查。对于非政府申请，大多数人认为这就足够了。

要满足第一个问题，您需要一份全面的已泄露密码黑名单——最好的是在haveibeenpwned.com 上维护的 ~12 GB 数据库。

为了满足第 4 个要点，您需要维护自己的黑名单，列出在您的应用程序中具有特殊含义的术语（服务名称、用户名、应用程序中的角色，如“管理员”或“讲师”等）

正如您所指出的，“一上、一下、一符号”之类的“复杂性规则”已经过时，不应使用。正如mandotory XKCD指出的那样，“通过 20 年的努力，我们已经成功地训练每个人使用人类难以记住但计算机容易猜测的密码。”

您的前三个，加上“禁止类似于其他属性的密码”，是一个很好的策略。在几乎所有情况下，我个人都倾向于使用超过 8 个字符的密码，但那是因为我在不能（方便地）使用 LastPass 的任何地方都使用密码短语，并且看不出有任何理由允许使用 8 个字符这么短的密码；不过，显然世界上很多人都不同意我的观点。不过，我认为我没有看到“您不应该要求密码超过 8 个字符”的论点，只是 8 是您应该要求的最低级别（并且您可能需要更多）。

理想情况下，“禁止类似”规则也应扩展到站点属性（禁止站点名称或 URL，或突出的字符串）；这将破坏使用“通用强密码+站点名称”的“每个站点唯一密码”方案的人，但这是一个糟糕的方案，无论如何都不应该支持。计算熵是一个有趣的概念，但我认为这不是一个好主意，除非站点非常敏感；阻止以前使用过的密码就足以防止您可能在那里看到的问题。

说到这一点，请随意对“已在其他地方使用/被破坏的阻止密码”这件事严格要求。我见过至少一个站点（其全部目的是验证其他服务，事实上！）决定只阻止 10,000 个最常见的密码，其中一吨比该站点的最小值短（例如，他们的“前 10,000" 列表包括一堆像 "11111" 之类的东西）或其他内容已经无效，因此有效的阻止列表是微小且明显的“规则律师”方法来处理他们的密码策略（容我们说，不在符合 NIST 建议），例如“P@ssw0rd”。

当然还有很多其他与身份验证相关的东西超出了“密码策略”的范围（如 MFA 或反暴力破解），但我确实想提一下其他（一对相关的）事物：不要对您的用户强制密码轮换（尽管显然他们必须是可能的），但如果有任何理由期望用户的密码被泄露（通过您的站点或第三方服务），您应该强制输入密码重置所有受影响的帐户。