Is it good practice to ban an IP address if too many login attempts are made from it?

Question

Since an IP address does not necessarily represent a specific device, but probably a whole network/company/etc. does it at all make sense to block an IP address if there is a significant amount of false login tries from it?

I was planning to implement IP checking as well as tries for a specific user/account/email, but I am not sure if it is better to leave the IP check out completely therefore.

On the other hand this allows an attacker to pretty much try a specific amount of passwords for every user without ever getting banned (at the same time blocking those users from being able to log in since their accounts will be locked for a while).

What is the correct approach to prevent something like that (possibly without using dedicated hardware)?

Answer 1

The answer to this question very much depends on the security posture of your site, which decides whether the risk of unauthorised access is greater or lower than the risk of Denial of Service for some users.

For high risk sites, I might go with the blocking option, especially where most of the user base is likely to be home users and therefore is likely to have distinct IP addresses.

One compromise might be where you detect password guessing attacks, add some anti-automation (e.g. CAPTCHA) to logins from that IP address for a while. That has the effect of making the attack harder to pull off while not completely blocking legitimate users from the site.

If you still get lots of invalid logins with the CAPTCHA completed then it would sound like you're seeing a more targeted attack (as they'd likely need to pay for a CAPTCHA solving service if your CAPTCHA is any good), and at that point I'd be more inclined to block the IP address for a while and redirect users to a message explaining the block (something like "malicious activity has been detected from your IP address, please contact support on [your_support_email_here]).

Answer 2

As @Rory said, it depends on your security posture, but if it's not a very high risk site and you are worried about blocking multiple users who happen to be sharing the same IP, one approach you could use would be to track the number of login attempts per IP and apply some very moderate (for a human) throttling that would make a brute-force attack prohibitively expensive.

For example, if more than X tries from a given IP address have been attempted in the last second (where X is your estimated number of concurrent login attempts per second from a single IP address) send a 403 (or better, a 429) with a message that says something like "Too many attempts have been made recently, please wait a few moments and try again."

This way, it is very unlikely that a human will ever have a problem even if they have a shared IP, while any brute force attack will be limited to X per second, which is hundreds to thousands of times slower than a non-throttled attack.

If you wanted to make it a little more secure without resorting to auto-banning, you could also send an automated email to support whenever the maximum login threshold has been reached an excessive number of times (maybe 100) from a single IP. That way you could inspect the logs and decide for yourself if that particular IP address is worth perma-banning or not.

This approach trades a little security for usability, since we are avoiding captchas or anything else that would slow a human down.

Answer 3

I'd like to mention another problem: This can be a usability catastrophe...

This block can be very annoying (happened to me more than once). Consider the case of an internet provider with native IPv6 adresses where IPv4 is only available through NAT. Let's say there are 1000 people behind this NAT, i.e. 1000 people with the same IP address. If you ban only one of them by their (most likely IPv4?) address, you would also ban the other 999 people. Does this sound like a good idea? I don't think so. I'm not sure about the side-effects if you check for the IPv6 address.

(the above scenario with IPv4-only-over-NAT applies at least for some major internet providers in Germany)

Answer 4

Another workable solution is to create an alternative mechanism for the user to login. The user would be able to use this alternative mechanism when the usual login mechanism has been disabled (due to too many failed login attempts by Mallory)

This alternative mechanism typically would request for much more information to ensure that only the actual user is able to login successfully. For example, in addition to the password we may require the user to supply one or more of these:

• an SMS code

• a hardware dongle

• a code sent to an (secured) email

This alternative mechanism must not be rate limited (otherwise Mallory would simply spam it with garbage to achieve denial of service).

Since it is not rate limited, the inputs need to be long enough to resist "infinite" bruteforce attacks.