蛮力攻击有两个方面的影响。一种是通过一系列密码猜测来恢复凭据，另一种是通过发起大量尝试来创建拒绝服务 (DDoS)。

行业使用多种机制来组合来减轻攻击，因为仅实施一种控制可能不够。

可能的缓解控制措施可能是：

• 根据连续登录失败锁定帐户
• 在多次登录失败后在身份验证过程中创建暂停
• 阻止 IP – 为多个帐户发起多次登录尝试
• 允许高权限用户从特定 IP/IP 登录
• 从一个 IP 地址尝试使用多个用户名登录
• 一次尝试登录多个 IP 的帐户时限制/阻止流量
• 使用设备 cookie 减慢猜测速度（参考：https : //www.owasp.org/index.php/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies）
• 使用 CAPTCHA 防止自动攻击
• 使用 2 因素身份验证来防止攻击

现在，为什么使用控制组合很重要是为了确保合法用户不会受到影响或被阻止访问资源。

例如，如果我们仅实施“多次失败尝试后的帐户锁定”，攻击者可以简单地滥用此控制并通过发送一系列暴力尝试简单地锁定数千个用户帐户。结果，这变成了 DDoS，合法用户将因访问他们的资源而受到影响。

因此，始终建议根据要求的上下文使用上述控件的组合，以防止暴力攻击的影响。

为了防止暴力攻击，您可以使用以下方法：

通过睡眠人为地减慢登录尝试。

这对于 PHP 网站来说有些常见。当然，问题在于它占用了您的网络服务器上的一些资源。

使用验证码

要求登录必须解决验证码。

限速

您可以对每个 IP 进行速率限制，但是……还有 NAT，这对某些最终用户来说有些麻烦。此外，您可以使用其他类型的设备指纹识别，这样您就不会阻止太多用户。

两因素身份验证

你甚至可以通过电子邮件做到这一点。一些最终用户讨厌这一点，因为要登录，您现在还需要检查您的邮件。

尝试 10 次后锁定帐户，然后要求用户通过电子邮件解锁帐户

有点可行，但这意味着攻击者可以不断锁定帐户。

编辑：那里也有一些网络钓鱼的可能性（感谢您的评论）

哈希现金

从未真正被广泛采用。基本上，您要求客户端为您部分“破解”哈希（您指定前 n 位并要求客户端找到其哈希以这些 n 位开头的输入）。您可以使这变得任意困难（例如现代计算机上的 1s）。

缺点：需要来自客户端的更多 CPU 资源，您还需要验证哈希值，这也需要从服务器获取一些 CPU 资源（尽管比客户端少得多）。

外包问题

使用通过 facebook、google 或其他方式登录。始终是一个选择……可能并不总是您的最佳选择。

不是每个人都喜欢这样，因为您最终可能会泄露有关您的用户访问了哪些网站的信息。（如果您在欧盟，可能也不符合 GDPR？）

“人”检测

除了验证码之外，还有其他方法可以将机器人与人类区分开来，例如检查他们的用户代理、检查引用、检查他们的浏览器支持的功能等。但使用现有的验证码提供商可能更容易，反正已经这样做了。

您可以对此非常有创意，例如将 div 堆叠在一起并使用 CSS 设置样式并使用 JS 修改它们，以便正确的“登录”是唯一可见的，而其他的则不是，这意味着机器人很难分辨哪个“登录”是正确的。想出将机器人与人类区分开来的方法很有趣……但同样……使用现有的 CAPTCHA 服务通常更容易。

另外...考虑到可访问性...仅图像验证码将使某些人无法使用。好的验证码提供商至少也提供音频验证码。所以...不要创建自己的验证码。然后是屏幕阅读器......你的“检测人类”可能会干扰。（嗯，不确定使用这样的外部 CAPTCHA 提供程序是否符合 GPDR？）

网络级别的节流

如果你有正确的基础设施，你可以做到这一点。如果您有托管服务提供商，他们可能已经在请求过多之后已经这样做了（作为一般的 DoS 保护）。

蜜罐

不确定是否有人在实践中这样做，但基本上一旦你确定一个帐户被暴力破解，让他们的一次登录尝试成功，并给他们一个模拟网站，让机器人相信登录成功但实际上并不成功。

您可以通过多种方法尝试阻止暴力破解：双因素身份验证、验证码、速率限制，当然还有一些 pw 复杂性要求。

“我应该使用什么”的答案将取决于您的风险模型；如果您是一个不值得花费时间和精力来破解的小型网站，那么限速和/或复杂性规则可能就绰绰有余了。如果您正在运行像亚马逊这样的电子商务网站，其中包含大量机密数据，那么 2FA 可能更相关。

你应该首先考虑什么是可行的，然后在考虑到你的资源和风险水平的情况下，什么是合理的。