19

(这主要是一个与语言无关的问题,尽管在我的情况下我使用的是 ASP.NET 3.5)

我正在使用标准的 ASP.NET登录控件,并希望实现以下失败的登录尝试限制逻辑。

  • 处理OnLoginError事件并在Session中维护失败登录尝试的计数
  • 当此计数达到[某个可配置值]时,阻止来自原始 IP 地址或该用户/那些用户的进一步登录尝试 1 小时

这听起来像一个明智的方法吗?我是否错过了可以绕过此类检查的明显方法?

注意:ASP.NET Session 使用 cookie 与用户的浏览器相关联

编辑

这适用于仅在英国和印度使用的管理站点

4

5 回答 5

17

Jeff Atwood提到了另一种方法:与其在多次尝试后锁定帐户,不如增加时间直到允许再次登录尝试:

1st failed login    no delay
2nd failed login    2 sec delay
3rd failed login    4 sec delay
4th failed login    8 sec delay
5th failed login    16 sec delay

这将降低这种保护措施被滥用于拒绝服务攻击的风险。

http://www.codinghorror.com/blog/archives/001206.html

于 2009-02-20T16:21:14.987 回答
15

您要做的最后一件事是将所有不成功的登录尝试存储在数据库中,这将工作得很好,但也使得 DDOS 攻击使您的数据库服务器停机变得极其微不足道。

你可能在你的网络服务器上使用某种类型的服务器端缓存,memcached 或类似的。这些是用于通过 IP 地址和/或用户名跟踪失败尝试的完美系统。如果超过了登录尝试失败的某个阈值,您可以决定停用数据库中的帐户,但是您将为不需要的失败登录计数器保存一堆读取和写入到您的持久存储中坚持。

如果您试图阻止人们强制进行身份验证,那么像 Gumbo 建议的节流系统可能效果最好。它将使攻击者对蛮力攻击不感兴趣,同时在正常情况下甚至在攻击正在进行时最小化对合法用户的影响。我建议只计算 memcached 或类似中 IP 的不成功尝试,如果您成为极端分布式蛮力攻击的目标,您始终可以选择开始跟踪每个用户名的尝试,假设攻击者是实际上经常尝试相同的用户名。只要尝试不是非常分散的,因为仍然来自大量的 IP 地址,初始的 IP 代码应该可以很好地阻止攻击者。

防止来自 IP 地址数量有限的国家/地区的访问者出现问题的关键是不要让您的阈值过于严格;如果您在几秒钟内没有收到多次尝试,那么您可能不必担心重新。脚本暴力破解。如果您更关心人们试图手动解开其他用户的密码,您可以通过用户名为后续失败的登录尝试设置更广泛的界限。

另一个不能回答您的问题但有些相关的建议是对您的最终用户强制执行一定级别的密码安全性。我不会过分要求混合大小写、至少 x 个字符、非字典等密码,因为你不想在他们还没有注册的时候给他们带来太多麻烦,但是简单地阻止人们使用他们的用户名作为他们的密码应该可以在很长一段时间内保护您的服务和用户免受最简单的攻击——猜猜他们为什么称他们为蛮力;)——攻击。

于 2009-02-21T15:02:01.080 回答
11

接受的答案会在连续的登录尝试中插入越来越多的延迟,在 ASP.NET 中可能会执行得很差,具体取决于它的实现方式。ASP.NET 使用线程池来处理请求。一旦这个线程池用完,传入的请求将排队,直到有一个线程可用。

如果您使用 Thread.Sleep(n) 插入延迟,您将在延迟期间占用一个 ASP.NET 线程池线程。该线程将不再可用于执行其他请求。在这种情况下,一个简单的 DOS 样式攻击将是继续提交您的登录表单。最终,每个可用于执行请求的线程都将处于休眠状态(并且时间会越来越长)。

我能想到的正确实现这种延迟机制的唯一方法是使用异步 HTTP 处理程序。请参阅演练:创建异步 HTTP 处理程序。实施可能需要:

  1. 在 BeginProcessRequest 期间尝试身份验证并确定失败时的延迟
  2. 返回一个 IAsyncResult 暴露一个 WaitHandle 将在延迟后触发
  3. 确保在 EndProcessRequest 中已触发 WaitHandle(或阻塞直到触发)
于 2009-10-23T16:43:25.993 回答
7

这也可能会影响您的真正用户。例如。在新加坡等国家/地区,可供家庭用户使用的 ISP 数量有限,IP 数量较少。

或者,您可以在 x 尝试阻止脚本小子失败后插入验证码。

于 2009-02-20T16:18:44.697 回答
4

我认为您需要将计数保留在会话之外 - 否则微不足道的攻击是在每次登录尝试之前清除 cookie。

否则计数和锁定是合理的 - 尽管更简单的解决方案可能是在每次登录失败之间设置双倍超时。即第一次登录尝试后 2 秒,下次登录后 4 秒,8 等。

您可以通过在超时期限内拒绝登录来实现超时 - 即使用户提供了正确的密码 - 只需回复人类可读的文本,说明该帐户已被锁定。

还监视相同的 ip/不同的用户和相同的用户/不同的 ip。

于 2009-02-20T16:19:46.160 回答