Page 1 of 1
Stop login flood
Posted: Wed Aug 01, 2007 6:35 am
by stakes
Hello developers.
I have a login form that sends the request through ajax to a "process login" script. Now if the user is successfully authenticated he/she
will be redirected to "protected pages". If the user fails to login, for some reason, the server returns different message depending on whatever
failed to authenticate the user. In this case, the page is not reloaded.
Right now someone could hit the submit button X times without being stopped, sending X number of requests to the server. Now i somehow want to stop this, allowing, say max 5 attempts a minute. I initially approached this problem by setting a cookie for the user, but cookies are easily disabled\manipulated. So i used sessions, which in theory stops the user until he\she restarts his browser. I used mySQL to record the user IP and session id but learned quite soon that this could quite easily be spoofed as well and now a malicious user could be flooding my mySQL server with requests\queries.
So what is really the best approach? I'm not running a top secret goverment project here I'm just more looking to stop the average script kiddies from making use\abusing my website, so no superflous suggestions please

Hope this makes sense.
Thanks in advance
/Daniel
Posted: Wed Aug 01, 2007 6:40 am
by feyd
Use Javascript to lock out the controls until a response is heard or some period of time has lapsed.
It doesn't prevent the direct requesting via other means, but it likely rules out a lot of spamming you'll receive due to user ignorance.
Re: Stop login flood
Posted: Wed Aug 01, 2007 6:42 am
by VladSun
stakes wrote:I used mySQL to record the user IP and session id but learned quite soon that this could quite easily be spoofed as well and now a malicious user could be flooding my mySQL server with requests\queries.
What is it so easy to spoof? IP or session ID?
Posted: Wed Aug 01, 2007 8:29 am
by programmingjeff
Session ID is the easiest to spoof.
An IP address is pretty easy because someone can use a proxy. It is a bad idea to limit the number of requests based on an IP address alone because of NATs.
Posted: Wed Aug 01, 2007 8:38 am
by VladSun
programmingjeff wrote:Session ID is the easiest to spoof.
Can't agree - almost every PHP app is based on session-ID security model. You will need an XSS or sniffer to steal a session id.
programmingjeff wrote:An IP address is pretty easy because someone can use a proxy.
It is true but there is no way to prevent it.
programmingjeff wrote:It is a bad idea to limit the number of requests based on an IP address alone because of NATs.
I agree.
Back to the problem - you may use something like "captcha" software.
Posted: Wed Aug 01, 2007 9:45 am
by programmingjeff
VladSun wrote:programmingjeff wrote:Session ID is the easiest to spoof.
Can't agree - almost every PHP app is based on session-ID security model. You will need an XSS or sniffer to steal a session id.
Sorry, I should have been more specific. You cannot rely on trying to only allow 5 logins per session-ID because it is easy for the user to clear cookies and get a new session-ID.
VladSun wrote:
Back to the problem - you may use something like "captcha" software.
Aye. Although I hate them as a user, they may be your best bet.
Posted: Thu Aug 02, 2007 10:49 pm
by shiflett
You might find this helpful:
http://phpsecurity.org/code/ch07-2
This example demonstrates throttling an authentication form, and it's based on data that you control, not the user. Remember to keep your error messages generic, so that an attacker can't reliably determine whether the account exists.
To get around the throttling, an attacker can choose a distinct username for each request, but that dramatically decreases the chance of success. Most enumeration attacks focus on a single account.
An additional safeguard is to use sessions to tally failures for a specific client, and then you just need to make sure requests that don't include a valid session identifier always fail. This lets you throttle a specific client in addition to a specific account, making enumeration attacks require an impractical time investment.
Hope that helps.
Posted: Fri Aug 03, 2007 6:02 am
by Chris Corbyn
shiflett wrote:Remember to keep your error messages generic, so that an attacker can't reliably determine whether the account exists.
I can't agree more. "Invalid username" and a separate "Invalid password" error give away for too much to narrow things down quickly. We always stick to generic "Login failed" messages and we lock accounts out for 1 hour after the 5th succesive failed login, but we don't change the error message to say the account is locked out otherwise you then know the account exists....
Posted: Fri Aug 03, 2007 7:57 am
by Ambush Commander
I hate it when I get locked out of an account because I couldn't remember which password I used for a particular website (or caps-lock was on). I think captchas are a bit better.
Posted: Fri Aug 03, 2007 8:06 am
by superdezign
Ambush Commander wrote:I hate it when I get locked out of an account because I couldn't remember which password I used for a particular website (or caps-lock was on). I think captchas are a bit better.
Captchas on logins? You know, that's a good idea. Do you mean, only after a failed login, or in general?
Posted: Fri Aug 03, 2007 9:31 am
by programmingjeff
superdezign wrote:Ambush Commander wrote:I hate it when I get locked out of an account because I couldn't remember which password I used for a particular website (or caps-lock was on). I think captchas are a bit better.
Captchas on logins? You know, that's a good idea. Do you mean, only after a failed login, or in general?
I've seen both used. As a user, I prefer the former because I have a password manager and therefore my username/password is always right. I feel that having the captcha appear on the first attempted login is a waste of my time.