2

I was recently reading this question, where the accepted answer claims that it is easy for attackers to bypass rate limiting that is based on IP, which makes any sort of IP rate limiting to prevent a brute force attack much less useful. But, if it is based on the account that is a victim, then it becomes very easy for an attacker to block access to a victim's account. What is the best way to defend against both account-level DOS attacks and online brute force attacks (and anything else that is in this same category)?

Simply sleeping for, for example, 1 second isn't sufficient because the attacker can simply put in more requests before the first one finishes (1 second latency, but unbounded throughput, and throughput is what matters for brute force). If subsequent requests are blocked until the first one finishes, then they must be blocked per-IP or per-user, which produces the same problem.

2FA isn't always a good solution either, because, for worse, many people fail to use it.

Improve this question
6
  • Online brute force attacks are mitigated by the natural latency between host and attacker. You can't get the same speed off online brute-forcing than you get in an offline attack. In fact, you will get several magnitudes less.
    – user163495
    Commented Apr 1, 2020 at 9:14
  • 2FA is the mitigation for account brute-forcing while not locking out the account. The fact that people fail to use it cannot be a consideration for the service owner.
    – schroeder ♦
    Commented Apr 1, 2020 at 9:15
  • I mean the kind of DOS where a malicious actor locks an account by logging in with an incorrect password too many times. "Account DOS" seems like a reasonable name for this, but I've never heard it and can't find any definition.
    – john01dav
    Commented Apr 1, 2020 at 9:16
  • 1
    @john01dav You prevent the DoS of locking accounts by not locking accounts.
    – user163495
    Commented Apr 1, 2020 at 9:21
  • 2
    Blocking an IP after several failed login attempts for a significant chunk of time, like 30 minutes, is still very effective. True a botnet attack can switch IPs as needed but that really only comes into play for a targeted attack. Most of the time the attacks are opportunistic attacks and the automated systems simply move on when blocked. Even targeted botnet attacks could block around 2000 IPs with a 30 minute jail. Sufficient does not require Perfection.
    – user10216038
    Commented Apr 1, 2020 at 17:28

1 Answer 1

Reset to default
1

You can use IP-based rate-limit, even if the attacker can control multiple IP addresses.

For you, keeping track of tens of thousands of IP addresses is easy: just create a database table with IP address, account accessed, and number of authentication errors. If they are above a threshold, slow down the response.

Simply sleeping for, for example, 1 second isn't sufficient because the attacker can simply put in more requests before the first one finishes.

In this case, you need to look on your table, see if there's more than, say, 5 requests, and add the wait time at the end of the request. So no matter if the attacker sent 10 or 1000 requests, he will have to wait. The wait time should be exponential, not linear, to further increase the attack cost.

For the attacker, controlling more than hundreds of IP addresses is not trivial. They will end up being slowed down by the rate limit, increasing the cost of the attack substantially. But the victim will not be affected.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .