Page 1 of 2

Login Throttling (Brute Force Attack Prevention)

Posted: Sun Nov 29, 2009 11:11 am
by jayshields
Hi,

Just about to implement this on my login system, and haven't done it before so wondering what you guys think of my method I've come up with.

Basically, it's just to prevent brute forcing the password for a specific username. I think the easiest solution (and the one I intend to go with if no one can give me reason not to) is to simply add 2 extra fields to my users table. One for a "bad login streak" count and one for the date/time the user is blocked from logging in until (default to 0000-00-00 00:00:00 or something).

I guess the criteria to use for blocking users varies, but 10 unsuccessful attempts in a row (over any amount of time) resulting in a 1 hour block seems sufficient to me.

My method would be to to add 1 to the bad login streak count for every incorrect login attempt made. If the counter gets to 10, reset the counter and store the date/time + 1 hour and don't let the user login until that time has passed.

The main flaw of this method is it is open to a denial of service attack, but there's no point over-complicating things by adding IP address checks because not only can they be spoofed anyway, but if the user can't get onto the website because of a DoS attack then they can simply reset their password using the "Fogot my password" function, and then proceed to login (the bad login attempts counter gets reset upon password resetting). Obviously the user will need to go to their email and click a link to be presented with the option of resetting their password (and resetting the counter).

Does this seem sufficient to you? Is there a better or easier solution?

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Sun Nov 29, 2009 1:36 pm
by BlaineSch
With your method you would have to reset it every time they login. And what about logging? If they get it wrong that many times either they are stupid or are trying to brute force you. If they are trying to brute force you that means they are trying to gain unauthorized access, I would log their attempts. Make another table called "bruteforce" or something "id, ip, user, datetime" add that every time they try for every user then do a query if the IP and/or user has done this 10 times in the past hour or so and then lock them out if they have.

This way you also have records of it. If they were attacking your site and this was not the way they got in they might try other ways, but if they do try it this way you have their IP! :D

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Sun Nov 29, 2009 4:16 pm
by jayshields
Yeah I forgot to mention that upon successful login the counter would be reset.

I don't really care for logging unsuccessful login attempts. What am I going to do with the offenders IP? And if they are making any sort of serious attempt for brute forcing they will probably be spoofing the IP.

Besides, if I ever needed a brute-force attacker's IP address, I'm pretty sure it would stand out in the Apache logs!

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Mon Nov 30, 2009 4:00 am
by VladSun
jayshields wrote:... but there's no point over-complicating things by adding IP address checks because not only can they be spoofed anyway ...
It's not *that* easy to spoof IP addresses and get a *fully* established TCP/IP connection. I'd advice you to "over-complicate" things and to add IP tracking to your system. Then, you can even track whether the IP address changes too fast - in order to protect yourself from a distributed attack.

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Mon Nov 30, 2009 5:33 am
by timWebUK
VladSun, how would you recognise the IP changing too fast? Logging the username the attempt has come from and the IP?

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Mon Nov 30, 2009 5:53 am
by VladSun
Yes.
It would be something like:
[sql]SELECT     count(DISTINCT ip) FROM     login_attempt WHERE     username='$username'     AND     timestamp > NOW() - INTERVAL 30 MINUTE[/sql]

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Mon Nov 30, 2009 5:54 am
by timWebUK
Cheers for that!

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Mon Nov 30, 2009 1:11 pm
by jayshields
Yeah - I suppose I could keep track of IPs and impose some restriction so that someone cannot try to login as any single user from more than say 5 IP addresses over half an hour.

Shame I'm going to need another table in my database to hold the IP of all login attempts now though - something I wanted to avoid if possible for the sake of keeping things simple.

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Thu Dec 03, 2009 4:57 pm
by josh
I don't see how the number of IP addresses correlates to the seriousness of attack. And the *last* thing you want to do is let them use up all your disk space with sophisticated log tables that are going to amount to an up to date proxy list for you.

There is no motive for them to try to waste all the IPs on a single account, they'd spread it out, 1 IP or less on average per account they are trying to log in to, IMO. The justification requirements to obtain IPs has gotten stricter, data centers are getting stricter about hosting open services like proxies & email servers

I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Thu Dec 03, 2009 5:23 pm
by VladSun
josh wrote:I don't see how the number of IP addresses correlates to the seriousness of attack.
Well, a single IP login attemts can be "throttled" even in lower OSI network layers. Mod_evasive is also good enough to stop such attacks. So, a distributed attack will be much more efficient and hard to be "throttled" - so, it's much more "serious".
josh wrote:And the *last* thing you want to do is let them use up all your disk space with sophisticated log tables that are going to amount to an up to date proxy list for you.
Come on - such issues are really easy to solve... or else - there wouldn't be any Apache access log files ;)
josh wrote:There is no motive for them to try to waste all the IPs on a single account, they'd spread it out, 1 IP or less on average per account they are trying to log in to, IMO.
So, the probability to break into an account becomes very, very low, doesn't it?
josh wrote:The justification requirements to obtain IPs has gotten stricter, data centers are getting stricter about hosting open services like proxies & email servers
Do you want to buy a bot-net? ;)
josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
First, it will be very annoying if there is a CAPTCHA in the log in page. Second, brute-force-log-in-attacks are usually "session-less"...

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Fri Dec 04, 2009 7:49 am
by josh
VladSun wrote:distributed attack will be much more efficient and hard to be "throttled" - so, it's much more "serious".
But I thought we were discussing throttling per user?

VladSun wrote:Come on - such issues are really easy to solve... or else - there wouldn't be any Apache access log files ;)
I don't follow? Isn't that an argument to NOT to re-invent the wheel of log rotation?
VladSun wrote:
josh wrote:There is no motive for them to try to waste all the IPs on a single account, they'd spread it out, 1 IP or less on average per account they are trying to log in to, IMO.
So, the probability to break into an account becomes very, very low, doesn't it?
Still not following? If the IP addresses are really as disposable as you imply, then that is just yet another argument not to bother tracking them, is my main argument here.
VladSun wrote:
josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
First, it will be very annoying if there is a CAPTCHA in the log in page. Second, brute-force-log-in-attacks are usually "session-less"...
You could enable the captchas if there have been more then a set threshold of login attempts within a certain amount of time (basically a shield that turns on only as needed). It is up to you whether your captcha requires sessions to be on.

If, lets say, there has been 1,000 login attempts in the last hour, then you could activate the captcha for ~3-4hrs, thus throttling the attack. Hopefully the attackers would then move along to another site, and not very many legit users would even notice. This is likely similar to how Yahoo seems to work

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Fri Dec 04, 2009 8:15 am
by VladSun
josh wrote:
VladSun wrote:distributed attack will be much more efficient and hard to be "throttled" - so, it's much more "serious".
But I thought we were discussing throttling per user?
I thought the "per user" attack is just a particular case of the "brute-force" attack ... It's even part of it.
josh wrote:
VladSun wrote:Come on - such issues are really easy to solve... or else - there wouldn't be any Apache access log files ;)
I don't follow? Isn't that an argument to NOT to re-invent the wheel of log rotation?
I tried to be sarcastic ...
josh wrote:
VladSun wrote:
josh wrote:There is no motive for them to try to waste all the IPs on a single account, they'd spread it out, 1 IP or less on average per account they are trying to log in to, IMO.
So, the probability to break into an account becomes very, very low, doesn't it?
Still not following? If the IP addresses are really as disposable as you imply, then that is just yet another argument not to bother tracking them, is my main argument here.
I don't follow?
josh wrote:
VladSun wrote:
josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
First, it will be very annoying if there is a CAPTCHA in the log in page. Second, brute-force-log-in-attacks are usually "session-less"...
You could enable the captchas if there have been more then a set threshold of login attempts within a certain amount of time (basically a shield that turns on only as needed). It is up to you whether your captcha requires sessions to be on.

If, lets say, there has been 1,000 login attempts in the last hour, then you could activate the captcha for ~3-4hrs, thus throttling the attack. Hopefully the attackers would then move along to another site, and not very many legit users would even notice. This is likely similar to how Yahoo seems to work
Certainly, that could be a solution - I agree.
But ... you have to track somehow the "login attempts within a certain amount of time " - so we are back to some kind of massive logging. And if we are "clever" enough to implement an algorithm that will reduce the log space, then we are able to do the same way for "distributed attack" detection, aren't we?

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Fri Dec 04, 2009 8:23 am
by josh
VladSun wrote:But ... you have to track somehow the "login attempts within a certain amount of time " - so we are back to some kind of massive logging. And if we are "clever" enough to implement an algorithm that will reduce the log space, then we are able to do the same way for "distributed attack" detection, aren't we?
Its not that difficult

- add a column to the users table
- increment it on false logins
- reset it on successful logins
- add a cron script to reset the column hourly
- if the SUM() of this column surpasses a dangerous level, activate the shields site wide!

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Fri Dec 04, 2009 8:56 am
by VladSun
josh wrote:Its not that difficult
VladSun wrote:we are "clever" enough
josh wrote:- add a column to the users table
- increment it on false logins
- reset it on successful logins
- add a cron script to reset the column hourly
- if the SUM() of this column surpasses a dangerous level, activate the shields site wide!
Or maybe a round-robin database solution :)

Re: Login Throttling (Brute Force Attack Prevention)

Posted: Fri Dec 04, 2009 10:02 am
by josh
What do you mean?