虽非直接相关，但受 Pwned Passwords Validator 的启发，因为我们最近一直在研究更严格的密码验证。
Discourse 似乎并未阻止用户名 myusername 使用如 myusername123 或 4myusername 这类密码。
我未找到关于此类弱密码的过往讨论。此前是否考虑过这一问题？
5 个赞
我同意在用户设置密码时增加一项检查，即“密码不得包含小写用户名”，这在我看来是合理的。
我们已经测试了 password = username 的情况，但我不太喜欢使用子字符串测试，尤其是针对较短的用户名。如果你的用户名是“Ed”，而密码是一个恰好包含“ed”的随机字符串……
3 个赞
使用相似度评分（例如 Levenshtein 距离），如果 levenshtein(username, password) < 6 则判定为失败？或者，甚至加入检测字符排列的逻辑，例如：
levenshtein(sort_by_chars(username), sort_by_chars(password)) < 6
这似乎既能防范最严重的滥用情况，又不会阻止像“Ed”这样的用户设置一个较长的优质密码，而且解释起来也很准确：“您的用户名和密码过于相似”。我尚未查找是否存在不良的边界情况，但目前想不出任何例子。
3 个赞
今日相关推文：
5 个赞
“越来越多”规则的另一方面是，密码更容易被暴力破解。
显然，如果密码长度不超过 15 个字符，就不应包含 10 次重复的字母 z。
显然，如果密码长度短于 12 个字符，就不应包含单词“password”。
连续两个字典单词，显然也是错误的……
依此类推。因此，用于搜索密码的空间被缩小了。
这是一个深奥的话题。经过一番思考后，我改变了昨天的看法。我同意 @codinghorror 的观点：我们在这里无需采取任何行动。
3 个赞
“制定好规则很难，所以我们就不该制定规则”？
这已经是连续第二天看到 Discourse 团队的高级成员传播关于安全性的重大误解了。我认为有些普遍问题需要重新思考，希望你将此视为建设性的反馈。
此外，这个具体建议并非空穴来风：我们最近有一个用户账户遭到入侵，原因是用户名为 myusername，而密码格式为 myusername46。
诚然，这是一个 ClassicPress 站点（登录结构与 WordPress 相同），因此在面对机器人等威胁时，它更容易成为“低垂的果实”。然而，这正是机器人所寻找的目标。
密码规则无法阻止所有类型的弱密码，但它们确实能起到很大的作用。
从技术层面来看，我们遵循的是 NIST 800-63-B 的指南：
在处理建立和更改记忆秘密的请求时，验证方必须将候选秘密与已知常用、预期或已泄露的值列表进行比较。例如，该列表可以包括（但不限于）：
- 从以往泄露数据集中获取的密码。
- 字典单词。
- 重复或连续的字符（例如 ‘aaaaaa’、‘1234abcd’）。
- 特定于上下文的单词，例如服务名称、用户名及其派生词。
其中明确使用的是 MAY（可以）而非 SHALL（必须）。因此，这属于我们的自主决定范围。此处并未对 Levenshtein 距离提出任何建议。或许可以添加一条规则：如果用户名长度超过 6 个字符，则不应包含在密码中；或者在百万级密码列表的基础上增加熵值检查。我不确定。
我想，如果你非常希望在此处实施自己的规则，可以运行 SSO，并在你的端点上设置任意规则。或者编写一个插件。
3 个赞
这可能就是我们打算做的。这里还有很多缺失的内容，但目前的反馈让我觉得，把它提出来并不特别值得。
请在这里的 #plugin 分类中分享您开发的插件。并非所有人都认同我们做出的每一项决定，我完全尊重多样性和不同的选择。也许其他人对更严格的密码规则更感兴趣。
1 个赞