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

Freiheit
  • 277
  • 1
  • 10
Levite
  • 819
  • 1
  • 6
  • 14
  • 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 May 27 '14 at 22:19
  • How would you define 'too many'? Also, if you enforce such a restriction then you need to make users aware in case they are trying to remember their password and would rather keep trying different passwords than ask for an email reminder (asking for an email reminder is like stopping and asking for directions - some people just won't do it). – Pharap May 28 '14 at 04:41
  • You might want to consider using time between attempts in addition to rate. a legitimate user needs time to enter his username and password and wait for a response. someone using an automated process doesn't really need that. And if they know you're doing this and throttle their requests to look like regular user traffic, it'll be less like a DDOS attack and more like a busy day, something your servers should be able to handle. – Nzall May 28 '14 at 07:56
  • 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 May 28 '14 at 08: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 May 28 '14 at 08:06
  • @Roy If the initial sequence number is predictable, the whole handshake is predictable. But apparently that did get better over the years. But see [here](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3188) for what I meant. – Voo May 28 '14 at 10:25
  • 2
    @voo then don't allow TCP but enforce HTTPS for log-in – ratchet freak May 28 '14 at 11:28
  • Since when can a single IP address cannot represent a whole company/network? I don't think that's how they work. – TylerH May 28 '14 at 13:37
  • 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 May 28 '14 at 14:12
  • @voo yeah I'm aware of TCP sequence predication but that hasn't been a practical threat in ages, that said I hadn't seen that CVE before, but from reading the mailing list posts they're still talking about 24-bits of randomness which would be a hell of a lot of packets to make a single HTTP request even with a vulnerable system. – Rory McCune May 29 '14 at 06:38

4 Answers4

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

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 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 May 27 '14 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 May 27 '14 at 18:32
  • 3
    I'd vote for this answer, but then you'd no longer have +42. – Keavon May 29 '14 at 01:14
  • @Rory, What about IPv6 where each device has its own allocated external IP? – Pacerier Feb 16 '15 at 03: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.

Community
  • 1
thomij
  • 241
  • 1
  • 6
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)

mozzbozz
  • 111
  • 2
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.

Pacerier
  • 3,253
  • 6
  • 34
  • 61