纵然这份数据泄漏了一些ASCII中心主义。我想，数字在任何文化里都是相同的，但我难以相信普通的中国人会选择“password”、“qwertyuiop”或“mynoob”作为密码。因此，上面这份清单必然还会因地区而异。

　　（一个有趣的想法是，在长密码里去检索匹配常用的较短密码，不过，我觉得这会产生太多的误报。）

　　如果你再次检视这份数据，不难得出一个支持密码长度的结论。请注意，在最常用的25个密码中，只有5个超过10字符。因此，如果我们要求密码长度至少是10，就已经把上黑榜的几率降低了80%。我最早是在为Discourse.org做调研时意识到这一点的，那时我收集了数百万个泄漏出来的密码，然后把这份清单过滤到只剩下满足我们新的最低要求（10个字符或更长）的那些密码，真的是寥寥无几了！

　　在此，我想对我们的程序员小伙伴们提几点常识建议：

　　1. 密码规则就是扯蛋

它们没卵用！

它们严厉惩罚了你的理想用户——使用真正的随机密码生成器的那些人。你猜啥，那些随机密码可能不包含数字或符号。我刚刚翻了一下数学教科书，确认了，这是有可能的。我很肯定！

它们给普通用户带来挫败感。然后，他们就暗生排斥心理，耍起了小聪明，结果使得他们的密码安全性变差。

它们还常常错误百出，所选的规则非常不完整，甚至很愚蠢。

不开玩笑，看在上帝的份上，趁早抛弃这种没心没肺、毫无道理的密码规则吧。如果你不信我的话，看看人家的这份建议。人家也说了，“别用组合规则”。不过，我确实发现一个问题——应该说是，“别用扯蛋的组合规则”。

　　2. 密码要支持Unicode，并强制要求最小长度

　　这条规则，最起码很容易记，也容易理解和实施。至尊规则唤众戒，众戒归一黑暗中。

它很简单。用户可以数。好吧，大部分人都能数。

它行之有效。已经有数据证明了这一点。你随便去下载一份常用密码清单，然后按密码长度分组，一目了然。

需要明白一点，即使这条规则也不是无懈可击的。在一个中文网站上要求最小密码长度为6可能已经够好了。而一个20字符长度的密码可能极不安全。

如果你不允许在密码框里输入任何Unicode字符，你可能就在犯错。

还有一个实现方面的细节，就是要确保密码的最大长度也要合理。

　　3. 与常用密码进行校对

　　前面我已经提到过，所谓“常用”，跟你的用户和语言有关。但是，如果你让他们从最常用的1万、10万甚至100万个密码中挑选自己的密码，那就等于在坑他们。毋庸置疑，黑客在攻击行动中会利用这些常用密码。纵然你对密码的重试频次有积极的限制措施，只需用1000个最常用的密码来碰撞，你又能扛得了多久呢——结果非常令人震惊！

1.4%的人使用了最常用的10个密码

4.4%的人使用了最常用的100个密码

9.7%的人使用了最常用的500个密码

13.2%的人使用了最常用的1000个密码

30%的人使用了最常用的10000个密码

　　你很幸运！成百万个遭曝光的真实密码在那里等着你去筛选。做这种数据分析还是有点意思的，因为这些不是某些无聊的程序员凭空捏造出来的密码规则，而是被用户真正使用过的真实密码。

　　研究一下吧。收集一下数据。别让你的用户把自己坑了。

　　4. 检查基本的熵

　　别异想天开！关于熵的衡量，你内心深处觉得对就行。但是请记住，当用户无法通过规则检查时，你必须能向他们解释清楚。

　　我有点难过，因为我们曾经毫不介意用户选择像“aaaaaaaaaa”这样的10字符长度的密码。在我看来，最简单的解决方法是设定一个像“总共y个字符中至少需要x个唯一字符”的规则。在Discourse.org的beta版里，我们就是这么干的。如果你有更好的主意，欢迎留言给我。越简单清晰，越好！

　　5. 拒绝特殊密码

　　我感到羞愧难当，但我还是得承认：我们在早期开发Discourse.org登录模块的时候，忽视了必须要阻止的两种常见情况：

密码与用户名相同

密码与email地址相同

　　与此类似，你可能也应该阻止其他的特殊情况，比如：

密码等同于URL或网站域名

密码等同于App名字

　　简而言之，试着跳出密码输入框去思考，就像用户那样。

　　原文：https://blog.codinghorror.com/password-rules-are-bullshit/

　　作者：Jeff Atwood