Login Throttling (Brute Force Attack Prevention)
Moderator: General Moderators
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
Login Throttling (Brute Force Attack Prevention)
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?
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?
- BlaineSch
- Forum Commoner
- Posts: 28
- Joined: Sun Jun 07, 2009 4:28 pm
- Location: Trapped in my own little world.
Re: Login Throttling (Brute Force Attack Prevention)
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!
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!
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
Re: Login Throttling (Brute Force Attack Prevention)
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!
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)
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.jayshields wrote:... but there's no point over-complicating things by adding IP address checks because not only can they be spoofed anyway ...
There are 10 types of people in this world, those who understand binary and those who don't
Re: Login Throttling (Brute Force Attack Prevention)
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)
Yes.
It would be something like:
[sql]SELECT count(DISTINCT ip) FROM login_attempt WHERE username='$username' AND timestamp > NOW() - INTERVAL 30 MINUTE[/sql]
It would be something like:
[sql]SELECT count(DISTINCT ip) FROM login_attempt WHERE username='$username' AND timestamp > NOW() - INTERVAL 30 MINUTE[/sql]
There are 10 types of people in this world, those who understand binary and those who don't
Re: Login Throttling (Brute Force Attack Prevention)
Cheers for that!
- jayshields
- DevNet Resident
- Posts: 1912
- Joined: Mon Aug 22, 2005 12:11 pm
- Location: Leeds/Manchester, England
Re: Login Throttling (Brute Force Attack Prevention)
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.
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)
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)
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)
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:I don't see how the number of IP addresses correlates to the seriousness of attack.
Come on - such issues are really easy to solve... or else - there wouldn't be any Apache access log filesjosh 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.
So, the probability to break into an account becomes very, very low, doesn't it?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.
Do you want to buy a bot-net?josh wrote:The justification requirements to obtain IPs has gotten stricter, data centers are getting stricter about hosting open services like proxies & email servers
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"...josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
There are 10 types of people in this world, those who understand binary and those who don't
Re: Login Throttling (Brute Force Attack Prevention)
But I thought we were discussing throttling per user?VladSun wrote:distributed attack will be much more efficient and hard to be "throttled" - so, it's much more "serious".
I don't follow? Isn't that an argument to NOT to re-invent the wheel of log rotation?VladSun wrote:Come on - such issues are really easy to solve... or else - there wouldn't be any Apache access log files
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:So, the probability to break into an account becomes very, very low, doesn't it?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.
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.VladSun wrote: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"...josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
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)
I thought the "per user" attack is just a particular case of the "brute-force" attack ... It's even part of it.josh wrote:But I thought we were discussing throttling per user?VladSun wrote:distributed attack will be much more efficient and hard to be "throttled" - so, it's much more "serious".
I tried to be sarcastic ...josh wrote:I don't follow? Isn't that an argument to NOT to re-invent the wheel of log rotation?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?josh wrote: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:So, the probability to break into an account becomes very, very low, doesn't it?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.
Certainly, that could be a solution - I agree.josh wrote: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.VladSun wrote: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"...josh wrote:I think if the attacks are that sophisticated a captcha is the correct solution (in addition to throttling)
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
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?
There are 10 types of people in this world, those who understand binary and those who don't
Re: Login Throttling (Brute Force Attack Prevention)
Its not that difficultVladSun 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?
- 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)
josh wrote:Its not that difficult
VladSun wrote:we are "clever" enough
Or maybe a round-robin database solutionjosh 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!
There are 10 types of people in this world, those who understand binary and those who don't
Re: Login Throttling (Brute Force Attack Prevention)
What do you mean?