2

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 lock an IP address if there is a significant amout 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.

Which would allow an attacker to pretty much try a specific amout of passwords for every user without ever getting banned (at the same time blocking those users from being able to lock in since their accounts will be locked for a while).

What is the correct aproach to prevent something like that?

(Btw: I am using PHP/MySQL, but this does not really matter, since just the right way to do it is needed)

Levite
  • 17,263
  • 8
  • 50
  • 50

1 Answers1

4

Banning an IP is, at least in my opinion, the exact opposite of 'good practice'. In some countries it's a given that your IP changes every 24 hours, so if you ban an IP today, an entire different person will get that banned IP tomorrow.

What you could (and should) do is to enforce a wait time after a false password was provided. As an example you could take a look at the webinterface of a AVM Fritz!Box. 

You provide a wrong password -> 2 seconds wait
You provide another wrong password -> 4(?) seconds wait
You provide another wrong password -> 6(?) seconds wait
...

(please note that usually a Fritz!Box only has a password field, no username/UID. That is configurable in newer versions. For full user/password authentication the 'wait time' needs to be applied as soon as a wrong log-in was submitted. Regardless if the username or the password or both were wrong)

That way someone trying to bruteforce his/her way into your webservice has a long way to go while regular users are not bothered.

Steffen Winkler
  • 2,805
  • 2
  • 35
  • 58
  • Well I was actually looking to ban it for about 10 minutes after maybe 10 wrong tries, but this might be the better solution slowing down the attack significantly. But still other users with the same IP might suffer from it, but there seems to be no good way around this, the same way you really can't circumvent an USER ACCOUNT being locked because of brute force attacks, and therefore the real user not being able to log in / work because of that. – Levite May 27 '14 at 13:52
  • 1
    @Levit well, applying some logic here: Let's say you got a malicious user inside a company's network...this way, people will be on someone's door asking what's up with the timeout. You (or your boss) can say 'well, someone is using wrong passwords here' and that should lead to some IT guy sniffing his network. To aid in such a case, you could log wrong log-in attempts using a timestamp, the IP, the username and a flag indicating if a different password was used. – Steffen Winkler May 27 '14 at 13:59
  • Good point! The main point should probably be to have more dynamic locking times (increasing/decreasing "fast"), by that also not "punishing" IPs, that might already belong to someone else. Simply slowing down an attack, seems to be the best possible way to implement this. (Thx!) – Levite May 27 '14 at 14:04
  • oh about the decreasing: on a Fritz!Box the timer is reset when you log-in successfully. That'd probably not work for your case (NAT) so, yeah you've to decrease based upon successful log-ins and time passed since the last failed log-in. – Steffen Winkler May 27 '14 at 14:06
  • But this way you're leaking user IDs, right? OWASP's Authentication Cheat Sheet states: "The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID." This way you infer a valid user ID, because the wait time only applies to valid user IDs. – Stan May 28 '14 at 05:55
  • @Stan I'm not sure what you are saying. The logfile is only on the server and should, of course, only be readable by system administrators. It doesn't matter if the UID is valid or not. A wrong log-in is a wrong log-in. I just don't want to have a bunch of passwords, of which some might be valid, inside a logfile. If you are referring to my original answer: On a AVM Fritz!Box there is, usually, only a password field. (in newer versions you can also create user accounts), which was why I'm only writing about wrong passwords. I'll edit my answer accordingly. – Steffen Winkler May 28 '14 at 07:42
  • @SteffenWinkler I missed some context, thanks. You're right that if there's only a password field then there's no information leakage. But what about if the application requires a username as mentioned in OP's question? Do you implement wait time per user account (which will lead to leaking usernames) or per IP address (which is insufficient when attacking from different IPs)? – Stan May 28 '14 at 07:55
  • Per IP-Address. I'm no expert when it comes to security measures but if you are attacked from multiple IP-addresses you are most probably being attacked by a botnet. The only way to counter that would be to 'sound an alarm' if a certain number of wrong log-in attempts/minute is reached (threshold). After that you'd have to decide if the attack is so bad that you need to switch off your systems to protect them or if a temporary IP-ban would be sufficient (only few IP-addresses, a certain subnet...something like that). – Steffen Winkler May 28 '14 at 08:06
  • I am - as of now - doing both: IP and Username checks! But since I really log the userNAME (not just id) I am also able to block a user that has too many tries but does in fact not even exist! It might be quite some storage overhead (with time), just for the reason NOT to leak usernames, but there is also the possibility to reset those (only entered usernames) after the time they became "irrelevant". – Levite May 30 '14 at 09:04