一个典型的web应用程序应该有什么密码策略？

Question

所谓“典型”，我指的是数据的价值，以及攻击者很可能试图破坏数据的可能性，而不是保护数据足够敏感，因此值得为用户方便做出重大牺牲的数据。

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

我目前对此的了解如下。我听说过的密码组合规则是好主意，包括：

• 8个字符的最小长度
• 不允许公共密码
• 不允许数据泄露中发现的密码。

我听说过的密码规则是错误的，包括：

• 最小长度在8个字符以上
• 最大长度低于web服务器规定的长度。
• 可以使用哪些字符的限制
• 使用某些字符组合的要求

我知道的密码规则有时会被使用，但我不确定它们是好的还是坏的想法包括：

• 不允许密码太类似于其他用户属性，如Django的UserAttributeSimilarityValidator
• 基于几种启发式算法的最小熵估计

Answer 1

您的主要三个是好的，实际上前两个是足够的，只要实现技术是坚实的。

不要允许高速蛮力的尝试！三到五次失败的尝试在一分钟或两分钟内应该完全阻止IP地址30-60分钟。这足够短，一个人可以等待合法的错误，但足够长的时间，有效地关闭大多数蛮力的尝试。高动机的低速攻击在数周到几个月内是不太可能的，但即使这样也可以用总错误计数检测来处理，但现实地说，这是过火了。阻止高速。

确保您没有创建SQL注入机制。实际上，不管复杂程度如何，这都适用。

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

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

Answer 2

你问：

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

我要讲的是NIST特别出版物800-63B:数字身份指南、身份验证和生命周期管理，5.1.1节记住的秘密。

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

5.1.1.1如果用户选择记忆秘密鉴定人，记住的秘密应该至少有8个字符。CSP或验证者随机选择的秘密至少要有6个字符的长度，并且可以是完全数字的。如果CSP或验证者根据所选秘密在已泄露值黑名单上的出现而不允许其存储，则应要求订阅者选择另一个已存储的秘密。不应对记忆的秘密施加其他复杂要求。这方面的一个理由载于附录A的背诵秘密的强度。5.1.1.2记忆秘密验证者在处理建立和更改已记忆秘密的请求时，验证者应将潜在秘密与包含已知常用、预期或泄露价值的清单进行比较。例如，清单可能包括但不限于：

• 从先前的入侵身体中获得的密码。
• 字典词。
• 重复或顺序字符(例如‘aaaaaa’，‘1234 e.g.’)。
• 特定于上下文的单词，例如服务的名称、用户名及其派生词。

比如zxcvbn (github.com/dropbox/zxcvbn )。lowe.github.io/tryzxcvbn的演示，谢谢@fread2281)包括基于字典的黑名单和公共序列检查。对于非政府申请，大多数人认为这是足够的。

为了满足第一个问题，您需要一个完整的密码黑名单--最好的黑名单是在haveibeenpwned.com维护的~12 gb数据库。

为了达到第四个要点，您需要维护自己的黑名单，列出在应用程序中具有特殊意义的术语(服务名称、用户名、应用程序中的角色，如"admin“或”辅导员“等)。

正如您所指出的，“复杂性规则”，如一个上、下、下，一个符号正在过时，不应该使用。正如扁桃体指出的那样，“经过20年的努力，我们成功地训练了每个人使用密码，这些密码对人类来说很难记住，但计算机很容易猜出来。”

Answer 3

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

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

说到这一点，可以自由地对“在其他地方使用过/被破坏过的密码块”进行严格处理。我至少看到过一个站点(实际上，其中一个站点的全部目的是验证其他服务！)决定只封锁10万个最常见的密码，其中一吨密码比网站的最低密码要短一吨(比如，他们的“前10,000”列表中包含了一堆像“11111”之类的东西)，否则就已经无效了，所以有效的阻止列表很小，而且显然是“规则律师”使用他们的密码策略(可以说，这不符合NIST的建议)，比如"P@ssw0rd“。

当然，还有很多其他与密码相关的东西超出了“密码政策”的范围(比如MFA或反暴力)，但我确实想提另一个(一对相关的)事情(S)：不要强迫你的用户更换密码(虽然很明显它们是可能的)，但是如果有任何理由期望用户的密码被泄露(无论是通过您的站点还是通过第三方服务)，您应该强制对所有受影响的帐户重新设置密码。