登录请求限制的缺点是什么？

信息安全 Web应用程序 蛮力 拒绝服务 帐户锁定
2021-08-20 21:44:10

在 Web 应用程序中，防止密码猜测攻击的一种方法是在一定次数的登录失败后锁定帐户。这可以在源 IP 地址和用户名上完成。

例如，下表显示了检测到重复尝试时会发生什么。系统设置为在 5 分钟窗口内 3 次登录失败后锁定帐户，持续 5 分钟。

IP             Time       Username           Creds Correct?  Message Given

203.0.113.1    10:00:00   foo@example.com    N               Bad username or password
203.0.113.1    10:00:01   foo@example.com    N               Bad username or password
203.0.113.1    10:00:02   bar@example.com    N               Bad username or password
203.0.113.2    10:00:03   foo@example.com    N               Bad username or password
203.0.113.1    10:00:04   foobar@example.com N               Login locked from your location
203.0.113.2    10:00:05   foobar@example.com Y               Welcome!
203.0.113.2    10:00:06   foo@example.com    N               Account locked
203.0.113.2    10:00:07   bar@example.com    Y               Welcome!
203.0.113.1    10:01:00   foobar@example.com Y               Login locked from your location
203.0.113.1    10:05:03   foobar@example.com Y               Welcome!

登录尝试仅在验证凭据时计入（该过程是在验证凭据之前首先检查锁定 - 如果锁定，则不验证凭据）。

从下面可以看出，恶意用户（在 IP 上203.0.113.3）可以通过故意反复猜错密码来锁定导致拒绝服务的帐户：

IP             Time       Username           Creds Correct?  Message Given

203.0.113.3    10:06:00   foo@example.com    N               Bad username or password
203.0.113.3    10:06:01   foo@example.com    N               Bad username or password
203.0.113.3    10:06:02   foo@example.com    N               Bad username or password
203.0.113.3    10:06:03   foo@example.com    N               Account locked
203.0.113.10   10:07:00   foo@example.com    Y               Account locked
203.0.113.10   10:07:04   foo@example.com    Y               Account locked
203.0.113.10   10:07:08   foo@example.com    Y               Account locked
203.0.113.10   10:07:15   foo@example.com    Y               Account locked
203.0.113.10   10:07:25   foo@example.com    Y               Account locked

...阻止真正的用户203.0.113.10登录。

另一种方法是人为地延迟 HTTP 响应。假设第一次登录失败延迟 1 秒，第二次延迟 2 秒，第三次延迟 4 秒，依此类推，总共 16 秒。如果他们的帐户受到攻击，用户在等待对登录请求的 HTTP 响应时会在浏览器中看到一个旋转的圆圈。

这有什么缺点吗？上面现在看起来如下所示（假设由于 bcrypt 迭代，默认延迟为 1 秒）：

IP             Req Time   Resp Time Username           Creds Correct?  Message Given

203.0.113.3    10:06:00   10:06:01  foo@example.com    N               Bad username or password
203.0.113.3    10:06:01   10:06:03  foo@example.com    N               Bad username or password
203.0.113.3    10:06:03   10:06:08  foo@example.com    N               Bad username or password
203.0.113.3    10:06:08   10:06:17  foo@example.com    N               Bad username or password
203.0.113.10   10:06:18   10:06:35  foo@example.com    Y               Welcome!

请注意，人为延迟（当处于活动状态时）是跨线程的，这意味着攻击者无法以更快的速度从单个 IP 发送请求。来自不同 IP 的登录不会排队，尽管它仍然会经历因错误尝试用户名而造成的任何人为延迟。

正如你所看到的，用户并203.0.113.10没有被拒绝访问——他们只需要等待 17 秒才能完成登录，而攻击者必须延迟他们的攻击。因此，它可以有效地防止密码猜测攻击。

我的问题是这种方法的缺点是什么，为什么您不经常看到这种方法而不是可能导致拒绝用户服务的全面锁定？

4个回答

将您的攻击场景翻转 90 度；考虑攻击者，他不是对单个用户使用密码列表，而是对用户列表使用单个密码。想象一下，我（作为攻击者）不在乎我可以访问哪个帐户，我只想访问任何帐户（例如，银行帐户）。我没有尝试暴力破解单个用户（这可能会失败），而是尝试使用相同的密码（一个常见的密码，例如“CorrectHorseBatteryStaple”）针对我之前掌握的用户列表（大多数网站使用电子邮件用户名的地址，无论如何都不是秘密的）。

在这种情况下，您只能对每个用户名进行一次点击，但您仍然应该限制我的尝试。您提出的防御措施都不能按原样防止这种情况。

您的防御应该集中在其他方面，而不是限制针对用户名的登录尝试，您应该限制针对 IP 地址的尝试。我相信谷歌目前正在这样做。例如，如果我锁定了您的帐户，您应该仍然可以从您的正常 IP 地址登录（IE 与攻击者不同）。

我从这种方法中看到的缺点是：

  • 实现起来更复杂，尤其是在可扩展平台上，跨线程。
  • 跨负载平衡的服务器可能无效。
  • 用户可能需要耐心等待。

由于上述原因，它没有得到广泛实施。

我不确定为什么它比锁定帐户更难实施，或者为什么负载平衡 rs 会产生任何影响。这两种方法都需要集中协调要做什么（锁定与延迟）。

我认为主要原因是它的奇怪行为，让你的网站看起来像是坏了（我不认为这只是耐心）。延迟很常见，人们被训练认为“网站坏了”，因为这通常是这种情况，而不是“哦，这只是延迟我的登录，因为我输入了错误的密码”，这是非常不寻常的。换句话说，每个人都通过网站一般运作方式的规范接受了关于网站行为预期的培训。

另一个原因实际上是人们在简单地重试不同密码方面的潜力有限。如果您尝试登录网站 10 次但均失败，则此时您已经忘记了密码，第 11 次、第 12 次和第 13 次尝试不太可能有任何用处。大多数人可能会在 5-7 岁时放弃。所以此时是重置时间，再等 17 秒除了攻击者之外对任何人都无济于事。

您的解决方案将取决于访问授权系统（AD、ldap、...）的位置的可变性。

您提到的应用程序是唯一使用身份验证服务的应用程序吗？

  • 如果是：限制将正常工作。您可能会让用户对应用程序的缓慢（正如他们所感知的那样）感到惊讶，但这可能并不重要（您的限制应该是指数级的，以便前 3-5 次尝试几乎相同，时间明智，然后放一个陡峭的延迟曲线）

  • 如果不是：您需要对每个关注的系统做出相同的假设。这可能意味着您无法控制的某些应用程序可能没有您提到的延迟机制。这也意味着您必须严格控制哪些应用程序使用您的身份验证机制（例如，如果它作为 DMZ 服务暴露于所有 DMZ 环境中，这可能并不明显）

我非常不喜欢应用程序的节流，因为您必须将其编码到身份验证机制中（应该保持简单）或依赖防火墙节流。这也是因为我通常有很多应用程序从各个地方查询身份验证服务，并且限制既不实用，也不可执行。在这种情况下，您绝对必须拥有良好的密码，因为它们容易受到暴力攻击。

其它你可能感兴趣的问题
上一篇针对 Bitlockered Windows PC 的离线蛮力攻击 下一篇澄清自签名证书与根证书颁发机构