除非您有单独的方法来限制对登录表单本身的访问，否则一个好的基线是没有硬限制。那是因为某人太容易被完全锁定在他们的帐户之外。

这很糟糕，因为拒绝服务，显然，但它本身也是一个安全问题。它将增加要求解锁帐户的人的支持请求，并且进行解锁的人将变得习惯，并且以“嘿，我的帐户已锁定”开头的社会工程攻击变得容易得多。

相反，延长超时时间——但不是无限地；考虑到您的密码复杂性要求，足以将猜测的数量随着时间的推移限制在合理的范围内。

在我看来，这不能笼统地回答。这取决于您对可用性、安全性和其他参数的要求。

主要因素之一是在您的特定场景中可能的密码范围有多大。假设攻击者没有关于密码的更多信息并且必须暴力破解正确的组合，他有 1 到可能的密码组合数量的机会来正确猜出特定的密码。

例如，4 位 PIN 码有 10,000 种可能的组合 (10^4)。一次尝试猜测特定组合的机会是 1 到 10,000 或 0.01%。允许两次尝试使猜对的机会加倍至 0.02%。

您可以根据自己的具体情况找到合适的折衷方案。 但请记住，暴力破解并不是您可能需要考虑的唯一攻击方法。一些攻击者可能有关于目标的额外信息，因此可以通过尝试更有可能的组合来提高猜对的机会（例如，如果目标人在其密码中使用个人信息并且攻击者知道它）。

被认为“安全”的数字是相当随意的，因为风险取决于数据的价值、允许和强制执行的复杂性级别、最小/最大密码长度以及您可能已实施的其他安全措施。

典型的数字在 3 到 10 之间。如果您在不成功的尝试之间实施增加的时间跨度，您可以走向更高端，但前提是您允许/鼓励或强制执行相对较高的密码长度和复杂性。

您需要记住的是，大多数人不会想出随机密码。例如，在英国，最常见的大头针是 1966，另一个常见的大头针是 1066——这两个大头针都是历史上著名的日期。当然，还有更多可供选择的词，但人们仍然经常以常用词结尾。因此，允许对短密码进行 4 次猜测比您想象的更有效，特别是如果您的系统允许在超时后进一步尝试。

当然，在许多站点上，如果风险和数据敏感性较低，这可能并不重要。

除了延长超时，提高安全性的另一个好方法是在几次失败尝试后要求第二个身份验证因素。经常将代码发送到电子邮件或电话。

您还可以阻止来自不同网络的连续登录尝试，尤其是来自不同地区的登录尝试。记录和审核失败的登录尝试也是一个好主意。

这些策略有助于避免高水平的客户支持电话，同时将风险降至最低。

问题

初步说明：我偏向于 Web 服务器，但这里所说的许多内容将适用于其他类型的服务。

问题是拒绝服务。它可以通过两种方式发生：1) 攻击者以蛮力运行，最终导致服务器饱和，现在没有人可以访问该服务。2) 用户（无论是否恶意）可能尝试太多次，导致访问被锁定。

其他注意事项

1. 如果错误在用户名或密码中，则告诉用户将允许攻击者暴力破解/字典用户名。虽然这不利于可用性，但如果帐户默认为私密或匿名，您应该选择安全方面※。

2. 告诉用户该帐户已锁定将使攻击者更容易通过锁定多个帐户来引发问题（这是一种拒绝服务的形式，并且可能会导致许多支持票证）。此外，不存在的帐户无法锁定，允许攻击者通过此方法发现帐户。您可以考虑模拟锁定假帐户。

3. 发现帐户不仅是暴力/字典攻击的一半，而且在未来的社会工程中也很有用。

4. 蛮力/字典攻击的一种变体是针对大量用户名尝试相同的密码（通常是统计上常见的密码）。

※: 搜索引擎能索引用户名吗？如果他们愿意，请选择可用性（无论如何，攻击者在搜索引擎缓存中都有一个有效用户名列表）。避免允许搜索引擎在知道谁拥有帐户可能被视为敏感信息的网站中访问此类信息。

可能的解决方案

有一些常见的事情可以尝试解决这个问题：

• 添加验证码
• 添加重试时间
• 锁定帐户
• 锁定原点
• 两因素身份验证

应该注意的是，只有在防火墙级别或 Web 服务器配置级别锁定 IP 才会对服务器负载产生真正的影响。但是，如果您仅在与给定帐户配对时锁定源，则逻辑将在服务器端代码中。对于其他需要服务器端代码的解决方案也是如此。

这些解决方案依赖于服务器端代码，因此并不能真正保护服务器免受洪水攻击。这意味着这些方法的主要应用是作为威慑。

词汇：

对于这篇文章的上下文，这些词具有此处提到的含义：

• “锁定”：“在提供进一步的身份验证之前阻止访问”，以提供进一步的身份验证方式，以遵循与提供给忘记密码的用户类似的（如果不相同的话）步骤。

• “来源”：服务器可以用来识别连接来源的 IP、用户代理或其他技术。如果使用，应在隐私政策中提及服务器将记录此类信息。

• “第三通道”：电子邮件、SMS、专用应用程序或其他不受服务器控制的私人通信媒介。

还应注意，在此定义下，重试时间不是锁定，因为它不需要用户进行额外的身份验证，而是等待。

而且，因为它不能说足够的次数，散列和加盐你的密码。

验证码

应该注意的是，并非所有 CAPTCHA 解决方案都是可视的。有些是听觉的，甚至有些是文字的（例如：“紫色、企鹅、蓝色、白色和红色列表中有多少种颜色？”）。

优点

使用第三方解决方案很容易实施 CAPTCHA。使用第三方解决方案也会使问题外部化，以使 CAPTCHA 足够强大。

缺点

对于可能在输入密码时遇到问题的合法用户，使用 CAPTCHA 可能会带来不便。当前的 reCAPTCHA 通过使用行为分析来识别人类用户来缓解这个问题。

机器人可以通过聪明的 AI 来解决 CAPTCHA，或者简单地通过要求攻击者来解决它。

重试时间

优点

重试时间的优势在于它可以争取时间。因此，它可以与第三个渠道上的通知相结合，以提醒帐户所有者。

用户可能会采取什么行动？您可以建议使用更强的密码，但这并不能真正解决问题。

作为替代方案，考虑让用户选择拒绝来自攻击者机器的访问（即锁定来源和帐户的组合）※。请参阅“锁定原点”。

※：需要认证，并且只影响当前账户。应注意避免任何可能导致一个帐户锁定另一个帐户的缺陷。

缺点

使用重试时间会降低服务的可用性，因为这会给可能在输入密码时遇到问题的合法用户带来不便。这比 CAPTCHA 更糟糕，因为它是认知停机时间。

如果攻击者大约每小时执行一次尝试，蛮力/字典攻击仍然是可行的。解决此问题的替代方法包括频繁更改密码的安全策略（用户可能会通过选择类似的密码使其失效）和 IDS 或其他分析来检测攻击者（可以通过从多个来源分发攻击来规避 - 希望这是昂贵到足以成为一种威慑本身）。

锁定帐户

优点

它可以抵御随着时间或多个来源传播攻击。

缺点

由于尝试失败的次数，锁定帐户可能会导致合法用户被锁定在帐户之外。

此外，攻击者在第三个位置的失败尝试将锁定合法用户。将原始锁定与帐户锁定相结合将允许更精细的控制。在这种情况下，该帐户将仅针对尝试访问的来源锁定。

攻击仍可能通过导致被锁定的合法用户联系支持或寻找替代服务来影响系统。

锁定原点

优点

独立于帐户锁定来源具有允许阻止攻击者而不是惩罚帐户的优势。

缺点

In 将要求服务器跟踪请求的来源并区分失败与成功尝试。

攻击的来源可能在许多用户之间共享（例如在网吧中），锁定来源可能意味着锁定合法用户。

将原始锁定与帐户锁定相结合将允许更精细的控制。在这种情况下，最初只会为它尝试访问的帐户锁定源，但可以全局锁定为许多帐户锁定的源。

两因素身份验证

双因素身份验证的所有变体都是强大的暴力/字典威慑。有两种主要变体：

• 通过第三个通道发送代码以允许身份验证。它不应该需要额外的措施来防止该代码的暴力破解，因为它是一次性使用且寿命短的。

• 需要来自专用硬件/软件密钥的代码进行身份验证。密钥必须提供授权身份验证的一次性使用代码。

优点

双因素身份验证是唯一可以真正使暴力/字典攻击无效的解决方案。这是通过要求一次性使用代码来实现的，多次尝试不会猜到这是一次性使用代码。

缺点

两因素身份验证的实施通常更昂贵。

用什么？

添加额外的保护来阻止暴力/字典攻击是有意义的。在密码空间太小※或密码的最小强度太低（例如银行中常见的四位密码）的系统中，对这些措施的需求会增加。

※：密码的大小最好设置一个上限。这样，在对密码进行昂贵的哈希时，服务器就不会被阻塞。并且您应该使用昂贵的散列，因为它会阻止针对被盗散列码的强制攻击。

CAPTCHA 应该是第一选择，因为它实施起来非常容易且成本低廉（使用已建立的解决方案，例如 reCAPTCHA）。

在重试时间和锁定之间，考虑最小可行实现是相似的：要锁定一个帐户，您向帐户对象/记录添加一个字段，将其标记为锁定，然后在身份验证时检查...设置重试时间，您做同样的事情，除了您存储的是身份验证再次有效的时间。

一旦几次尝试都失败了，通过添加这些措施来减轻不便是有意义的。如果是这样，请先应用 CAPTCHA，因为它不会为用户造成认知停机时间。

在锁定选项之间，我们已经看到结合源和帐户是比单独使用任何一个更好的选择（但也更复杂）。实施将需要日志和分析。

最后，双因素身份验证具有超越上述解决方案的优势。然而，它的实施成本最高，因为它需要连接到第三方服务（电子邮件服务器、SMS 服务、专用应用程序、专用硬件等）。

我建议实施日志记录和分析，并根据它们决定是要实施锁定还是要实施双因素身份验证。

多少次尝试？

将有：

• n ₁次尝试，直到出现 catpcha。
• n _{2 次}尝试，直到出现重试时间。
• n ₃次尝试，直到应用锁定。

注意：如果您使用双因素身份验证，则从第一次尝试开始使用它。

将来可以根据您的分析调整此变量的值。然而，对于合理的默认值，请考虑：

• n ₁应该是一个人在输入密码有问题时可能尝试的估计次数。2 次尝试将是最小值 n ₁，因为这说明了基本的大写错误。注意：gmail 允许我在使用 CAPTCHA 之前尝试 20 次。

• n ₂应该是一个人在访问恢复机制之前将进行的尝试次数的估计。没有严格的最低要求，事实上，只要您应用 CAPTCHA，它就可以应用，并且等待的时间间隔越来越长。在我看来 n ₂ = 3 * n ₁是一个很好的起点。

• n ₃应该是对更有可能进行攻击的尝试次数的估计。考虑到 CATPCHA 和重试时间应该阻止任何手动攻击，因此 n ₃不需要高得多。在我看来，n ₃ = 2 * n ₂是一个很好的起点。

关于重试时间的注意事项：每次尝试都可以增加用户必须等待的时间间隔。这使您可以使用非常小的初始间隔（例如 1 秒）并从那里建立直到硬上限（例如 1 天）。

关于尝试计数的注意事项：您应该避免尝试计数溢出。如果您将尝试次数存储在帐户对象/记录中，请处理溢出。如果您正在对日志进行查询以获取上次成功尝试的失败尝试次数，请考虑添加时间间隔（这也将限制查询时间）。