Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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)?

share|improve this question
Don't forget the simple fact that I can easily (sadly really) spoof my IP address and get you to block IPs despite not having any access to it. Depending on your use case such a DDOS attack may be problematic or not. – Voo May 27 '14 at 22:19
@Voo how would you spoof an IP using TCP. This is not possible as there is no way to complete your three-way handshake succesfully. The only way you'd be even reomtely able to do this is by abusing a botnet. But even then the amount of IPs will be relatively limited. – Lucas Kauffman May 28 '14 at 8:04
@voo I'd agree with Lucas, you'll need to provide more details to substantiate that claim. Spoofing IP addresses for TCP based protocols (e.g. HTTP) is quite difficult in most cases. – Rоry McCune May 28 '14 at 8:06
@voo then don't allow TCP but enforce HTTPS for log-in – ratchet freak May 28 '14 at 11:28
The EXTERNAL IP might be the same for a whole university for example, while the computers in the network have their own individual internal IP addresses. But that's not the point here, also this login requires SSL, so IP spoofing should also be pretty much off the table (albeit distributed attacks might bring up similar problems...) – Levit May 28 '14 at 14:12

4 Answers 4

up vote 61 down vote accepted

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]).

share|improve this answer
+1 that is a really good answer! The implementation should really also depend on the specific case/site! Putting captchas for a specific IP with too many tries (as well as too many tries for a specific user) at first, also seems to be the user friendliest way to start security meassures. Good thoughts!! – Levit May 27 '14 at 14:15
It's also very important for a site with a hardened security posture that implements IP bans for administrative accounts to have precautions in place to make sure that all legitimate access is never cut off, such as standing exceptions for trusted networks. – Stephanie May 27 '14 at 18:32
I'd vote for this answer, but then you'd no longer have +42. – Keavon May 29 '14 at 1:14
@Rory, What about IPv6 where each device has its own allocated external IP? – Pacerier Feb 16 at 3:27

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.

share|improve this answer
403 means Forbidden, as in the user isn't allowed to access the resource, regardless of circumstances. 429 Too Many Requests is more appropriate for rate limiting, which is essentially what this solution is. (You could also use 420 Enhance Your Calm if you have a sense of humor.) – Justin Lardinois Feb 19 at 8:37
@JustinLardinois - you are right, 429 is a better choice. Since 429 is an "optional" code I went with 403, but 429 is safe to use and is more descriptive. – thomij Feb 19 at 17:09

Adding on to the other answers, another solution is to allow your user to login using an alternative mechanism when the "usual login page" has been disabled. For example, in addition to the password he needs to supply one or more of these:

  • an SMS code

  • a hardware dongle

  • a code sent to secured email

To guard against DoS, this alternative mechanism should always be accessible (no rate limit). Since there are no limits, you need to make the secrets long enough such that attackers wouldn't be able to successfully bruteforce this alternative login.

share|improve this answer

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)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.