51

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

Improve this question
10
  • 7
    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
    Commented May 27, 2014 at 22:19
  • 8
    @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
    Commented May 28, 2014 at 8:04
  • 6
    @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.
    – Rory McCune
    Commented May 28, 2014 at 8:06
  • 2
    @voo then don't allow TCP but enforce HTTPS for log-in
    – ratchet freak
    Commented May 28, 2014 at 11:28
  • 2
    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...)
    – Levite
    Commented May 28, 2014 at 14:12

4 Answers 4

Reset to default
68

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

Improve this answer
4
  • 3
    +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!!
    – Levite
    Commented May 27, 2014 at 14:15
  • 2
    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
    Commented May 27, 2014 at 18:32
  • 3
    I'd vote for this answer, but then you'd no longer have +42.
    – Keavon
    Commented May 29, 2014 at 1:14
  • @Rory, What about IPv6 where each device has its own allocated external IP?
    – Pacerier
    Commented Feb 16, 2015 at 3:27
14

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.

Improve this answer
0
1

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)

Improve this answer
0

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.

Improve this answer
0

You must log in to answer this question.

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