Hi there, I'm seeing web apps implementing limitations for user login attempts.
Is it a security necessity and, if so, why?
For example: you had three failed login attempts, let's try again in 10 minutes!!
thanks :)
Hi there, I'm seeing web apps implementing limitations for user login attempts.
Is it a security necessity and, if so, why?
For example: you had three failed login attempts, let's try again in 10 minutes!!
thanks :)
The limiting of how many attempts to be made on a website are to prevent brute force (automated) attacks your site. If you don't limit these attempts, a hacker can set up a script to keep guessing passwords until it finds one, and this may impact the availability of your web server.
Typically, you may want to time the user out (10 minutes as you mentioned) after 3 attempts, and lock them out after 6 or 9 consecutive repeated attempts, forcing the user to contact you in order to unlock their account. This is put into place because someone can modify their scripts to adjust your timeout.
Yes, it's necessary to protect accounts from sophisticated brute force attacks - as in, using bots and dictionary files - down to someone just trying to guess the password of the account.
If users can set their own passwords, some bot/kid will try to log in with a list of common passwords, and succeed. And if they don't know any users, they will try common names like admin, simon, rico, etc.
It doesn't help to just flag the user in session, as they can just remove the cookie or query param on their end. You need to have a count of failed login attempts for both IP and login name. Maybe be more forgiving for the IP as it can be shared among many users.
Also using a good implemented CAPTCHA could be an alternative way to enpower your application security against brute-force attacks. there's a wide variety of captcha providers available for free, let's try the easy way if you're in a hurry. Also please consider that there's people outta here saying that "oh, no! this captcha thing is not secure enough!".
"For those of you who don't know, a CAPTCHA is program that can tell whether its user is a human or another computer. They're those little images of distorted text that you translate when you sign up for Gmail or leave a comment on someone's blog. Their purpose is to make sure that someone doesn't use a computer to sign up for millions of online accounts automatically, or.." ref.
Clarification: Actually this is a completion to other's answers. using a good implemented captcha alongside an anti bruteforce mechanism using sessions for example.
The questioner marked it as accepted assuming that captchas are unreadable by machines (she's almost right) and so it's getting negative points, because people think it's not a complete answer & they're right.
For my own projects I wrote a generalized 'floodcontrol' library which handles this sort of thing.
It allows me to specify how many attempts may be made in X amount of time. It allows for a certain number of 'grace' attempts in a short time, so that only really unusual behaviour will be caught.
I record in the database a few things:
For each attempt made I query against the partial IP address and the action, and if a previous attempt was made within a certain window of time then I increment the attempt counter for that attempt. If the attempt counter exceeds the number of grace attempts allowed then I check whether the last attempt was within X seconds of now and if so, return false - therefore the action will be blocked (and the user will be told to wait X seconds before trying again). If the attempt counter is below the number of grace attempts then I return true and let it slide.
If a person with the same IP comes by later, then the previous attempt count won't be fetched, because it will be too long ago.
I saw a creative approach to this once...
For each login attempt, that fails, the lockout time increases... exponentially.
attempt | lockout time
======================
1 | 2s
2 | 4s
3 | 8s
4 | 16s
5 | 32s
6 | 64s
7 | 128s
8 | 256s
9 | 512s
10 | 1024s
In theory, it lets user make a mistake or two, but as soon as it appears to become a "hacking" attempt, the hacker gets locked out for longer and longer time periods.
I haven't used this myself (yet), but conceptually I quite like the idea. Of course on successful login, the counter is reset.
I reckon putting a 'failed attempts' counter in the DB would be the safest and easiest way to go. That way the user can't bypass it (by disabling cookies). Reset on successful login of course.