提议的限制是有害的。 这些限制是多余的。它们不利于可用性。因此，我认为它们对用户安全的伤害大于帮助。

可用性是它的所在。 在我看来，目前影响密码安全性的第一大最重要因素是可用性：用户以安全方式使用该机制的程度。对于一阶近似，您应该做的一切都应该旨在提高可用性并增加用户安全行为的可能性。每次做出设计决定时，都应该问自己：哪个选项更有可能使用户行为安全？

我希望您所阐述的复杂限制总的来说对用户的安全有害。我认为他们会减少安全性而不是增加安全性。以下是我的论点：

• 挫折。一个风险是用户会感到沮丧或烦恼，放弃并转向其他一些管理安全性不如 SO 的 OpenID 提供者——或者只是坚持他们当前的 SO，而不是采用 SO 的 OpenID 提供者。这是用户安全的净损失。

• 让人难以记忆。如果您有特定于 SO 的 OpenID 提供商的独特限制，这意味着用户必须为您的站点选择一个独特的密码。这听起来可能是积极的，但也可能是消极的。如果用户已经拥有高熵秘密，他们可能无法使用该秘密，因为它很可能无法满足 SO 的限制。我怀疑这一事实增加了用户被迫在某处写下他们的 SO 密码而不是记住它的可能性。

• 自动密码生成器。一般来说，人们不擅长选择难以猜到的密码。为了解决这个问题，一些人使用工具为他们生成密码。甚至有人主张这些工具应该更多地集成到每个人的浏览器中并广泛使用。目前，使用自动密码生成的最大障碍在于选择自己的特殊密码限制的网站。因此，您提出的一组限制将使人们难以使用自动密码生成器。那很糟; 您想鼓励人们使用自动密码生成器，因为自动生成的密码会更安全。而且您不想为集成密码生成器设置障碍。

那么你应该怎么做？我有两条高级建议：

• 从威胁模型开始。 不要只是开始编造听起来不错的限制和安全方案。相反，首先要考虑威胁模型。您认为安全最有可能失败的方式是什么？然后，当你提出一个新想法时，不要因为它听起来不错就立即实施，而是分析它将如何影响每一种可能的故障模式。总的来说，它是否显着降低了最有可能出现故障模式的可能性？正如加强链条中最强大的环节没有意义一样，保护实际上不太可能发生的威胁通常也没有什么意义。

  我注意到这个问题描述了一种安全机制，但它没有描述威胁模型，也没有包含分析。它没有确切说明它旨在击败什么攻击。在安全设计领域，这是一种“难闻的气味”，通常表明可能需要更多的思考。

  有关此类分析的示例，您可以阅读此分析。该论文认为，只要密码验证软件的架构合理，大约 20 位的熵就足以用于 web 密码，并认为具有较高熵的密码几乎没有什么好处。详细分析见论文。该论文的结论是“我们得出结论，强迫用户选择强密码似乎是错误的”；请参阅论文以了解原因。

• 成本效益分析。重要的是评估机制的成本和收益，并确保成本与收益相符。在这种情况下，成本是用户的烦恼。与一些不太严格的限制相比，这些限制的安全优势尚不清楚，而且可能很小。

  我鼓励您阅读Cormac Herley 的密码安全经济分析。他指出，安全专家给用户的密码建议是不合理的：用户遵循该建议的成本（例如，他们浪费在选择、记忆、管理和输入复杂密码上的时间）可能超过收益（减少安全漏洞） ) 大幅度增加。他认为，任何每年消耗用户几分钟以上时间的限制几乎肯定是净损失，实际上我怀疑它可能需要至少比这低一个数量级。有人要数据；他有。

  在相关的说明中，Cormac Herley 还对 75 个不同网站的密码策略进行了研究。他发现了广泛的限制。他还发现，限制程度与网站的安全敏感性无关，并建议“具有最严格密码策略的网站没有更大的安全问题，它们只是更好地免受可用性差的后果的影响。 " 这应该使人们对更严格的密码限制更好的建议三思而后行。

如果您正在寻找可以采取的更具体的步骤来保护您的用户并增加他们选择安全密码的可能性，您可以考虑以下一些想法：

• 包括一个密码强度栏。在用户必须选择密码的表单上，包含一些 Javascript 以提供一个动态更新的栏，显示用户密码的强度。你可以用红色、黄色、绿色表示不安全、边缘、好。

• 包括预先生成的密码建议。 在用户必须选择密码的表单上，您可以为他们随机生成一个密码并建议他们使用它。也许有些人会使用它！

• 帮助用户避免使用流行的密码。最近的一篇研究论文提出了一个有趣的想法：他们建议用户应该能够选择他们想要的任何密码，只要之前没有太多其他用户选择过它。然后，他们描述了如何执行此策略，而不会将密码以明文形式存储在服务器上。

• 使用安全、持久的 cookie 进行用户身份验证。如果您降低用户必须输入密码的频率，也许用户会更愿意自行选择复杂的密码，并且用户可能不太可能被网络钓鱼攻击所愚弄。我建议您的网站在用户首次登录时在用户的浏览器上设置一个安全、持久的 cookie。在以后的访问中，如果您检测到该 cookie，请立即将用户视为已通过身份验证并将其重定向到最终目的地，无需用户交互必需，以便用户无需输入密码即可登录。

• 更多地关注密码验证步骤。为什么我们希望用户首先选择高熵密码？我们关心的攻击是什么？一种攻击是有针对性的攻击，攻击者心中有一个特定的用户名并想要侵入该用户的帐户。另一种攻击是广泛攻击，攻击者拥有大量用户名，并希望找到一个，任何一个，他可以猜到其密码的人。SO OpenID 提供商面临的最大威胁是什么？我怀疑你最应该担心的是有针对性的攻击，因为我怀疑攻击者比普通用户更有可能试图闯入版主或高级用户。

  • 阻止有针对性的攻击。有一些有效的方法可以防止针对单个用户的密码进行针对性攻击。一种非常简单的方法是记录在过去一天左右输入了多少错误密码。如果这个计数超过某个阈值，那么你切换到“哦，该死，我可能受到攻击”模式。在该模式下，您可以要求用户输入验证码以及每个密码，或者您可以在每次尝试后添加延迟，或限制登录尝试，或者您可以强制用户解决工作量证明挑战（例如，为用户提供一些 Javascript 代码并强制他们在您接受下一个密码猜测之前进行 20 秒的计算），或者其中的一些子集。有很多可能的方案。

  • 阻止广泛的攻击。如果您想防御大规模攻击，例如，攻击者尝试对数以万计的帐户中的每一个帐户进行一次密码猜测，您将需要不同的防御措施。但也有解决这个问题的方案。一种潜在的对策是跟踪错误密码的总体比率，并在该比率开始变高时进入“我可能受到攻击”模式。

  有大量关于防御此类攻击的文献。总的来说，我认为最好让攻击者更难进行密码猜测攻击（例如，让它们运行得更慢），而不是对用户密码施加额外的限制。我认为那里有更多的物有所值。

该问题特别指出了“与第 3 方站点紧密集成”的要求。因此，所有关于 SE 账户不重要的争论都是无关紧要的。

另请注意，没有人强迫任何人使用这个特定的 OpenID 服务。有很多可供选择。基于良好安全性的差异化对于身份验证服务来说似乎是一个好主意。

密码错误是世界上的一个大问题。用户很可能在其他地方重复使用相同的密码。教育用户如何制作一个好的密码对互联网来说是一项非常有价值的服务。使用良好密码的用户成本很小，特别是考虑到良好且安全的代理（在浏览器或其他地方）方便记住它们。

具有密码等有价值信息的站点应该计划被破坏，并计划如何将损失降到最低。即使使用像 bcrypt 这样的良好散列算法，低熵密码也可以被暴力破解。所以好的密码仍然是一个好主意。

那么什么政策最好呢？我们都有意见，但实际上有数据。一篇有趣的新论文是 Reusable Security: New Paper on Password Security Metrics。（更新：）它指出了根据常见密码黑名单（包括键盘键行等内容）检查建议密码的重要性。它还提出了一个有趣的新密码拒绝功能的想法，该功能还建议使用用户的基本选择模式修改建议的密码，但使密码更不寻常，因此更难破解：

[first] 通过使用在先前公开的密码列表上训练的语法对其进行解析来评估人工生成密码的概率。与简单的黑名单相比，这使我们能够构建更强大的拒绝功能，同时在选择密码时，考虑到系统的安全限制，尝试提供尽可能多的用户自由。

基于上述情况，如果我想降低密码被破解的风险，建议的策略肯定看起来像是一种有利于安全的差异化因素，作为有兴趣采用 Stack Exchange OpenID 提供程序的第 3 方网站，我会寻找它。

（更新：）另一方面，如果您的目标是吸引用户使用您的 OpenID 服务，那么不太可能让他们受挫的方案（如 DW 所述）可能是一个更好的商业决策。最终，您的目标可能是多种多样的，并且权衡是复杂的。

复杂的密码通常由组织的 IT 部门强制执行，以确保员工的用户帐户不会受到外部威胁。在信任用户具有访问权限的情况下，它们也会被强制执行，这可能会在坏人手中造成破坏。

在这种情况下，两种情况都不适用。Stack Exchange 不存储任何私人数据，普通用户帐户也不会造成任何损害。这些密码要求可能有意义的唯一情况是，如果 Stack Exchange 系统遭到破坏，每个人的密码哈希都被暴露，它们很容易被破解，并且用户在其他地方使用了密码。没有其他场景有意义 - Stack Exchange 可以抑制暴力攻击；如果登录系统被破坏，密码强度就没有用了；即使用户的密码被泄露，它对 Stack Exchange 造成的损害也非常有限。因此，在所有情况下，Stack Exchange 都不受用户密码强度的影响。

另一方面，强密码要求可能会导致许多人避免使用该服务，并坚持使用他们的谷歌或 Facebook 帐户，这两者对密码的限制要少得多。

这是一个程度的问题——在人们避免你的服务或破坏你“保护”他们的尝试之前，你能强迫他们变得多安全。例如，某人可能有一个他们想使用的密码，但它可能没有 8 个唯一字符，因此他们使用“Pas$word”。或者他们编了一个密码，但知道他们不会记住它，所以他们把它写在某个地方，让附近的任何人都能看到。

为了提供一些观点，这里是对 Stack Exchange 登录页面上突出显示的其他 OpenID 提供程序的密码限制的检查：

• Google：最少 8 个字符，也不能是“弱”密码，尽管他们用来确定“弱密码”的确切机制是模糊的。（“abcdefgh”和“abcdefg1”很弱，而“Abcdefgh”足够强）。他们确实提供了一个页面，其中包含更强密码的提示。

• 雅虎：最少 6 个字符。有一个类似于谷歌的图形显示你的密码有多强，但没有什么能阻止创建一个密码弱的帐户。

• MyOpenID：最少 1 个字符，没有其他限制。与 Yahoo 类似，有一个图形显示了密码的强度（源代码），但没有什么能阻止使用弱密码（甚至 1 个字符）创建帐户。

• AOL：最少 6 个字符，也不能“太不安全”。有一个密码强度计（源代码），似乎任何得分低于 34 的密码都被认为“太不安全”。

• Facebook：最少 6 个字符。

与这些相比，Stack Exchange OpenID 密码的限制要强得多。在我看来，这是不必要的，因为最大的纯 OpenID 提供商 MyOpenID 完全没有密码限制。

这一切都取决于上下文

我的基本建议是：

像谷歌那样做

如果他们可以破坏 Google 的 OpenId 安全性，他们可能不会打扰您。任何比这更安全的东西都需要一个非常强大的附加价值主张来支持：

• 我们希望比 Google 更安全，因为 ____________________
• 对于我们的用户来说，提供不如 Google 方便的服务更有价值，因为我们提供______________________附加值

其次，我可以提供这条真实数据：

10% 的用户将使用相同的用户名和密码，这在我建立的一些网站上进行了测量，用户数量为 50k-500k。

例如用户名Foobar123和密码Foobar123。

更一般地说，只有在正确实施身份验证机制的情况下，使密码更安全才真正有用：

• 用户名不是秘密但你不会泄露它是否存在于你的系统中
• 密码足够强大
• 这两条信息是完全独立的：
  • 不同的
  • 永远不要一起存储或发送（你会喜欢这个- 包括在其他可能使用它们的站点中）。