I've seen web apps with 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!!
I've seen web apps with 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!!
Clarification This is a completion to the other answers. Using a good implemented captcha alongside an anti-bruteforce mechanism using sessions for example.
The questioner marked this 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.
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 and they're right sometimes!".
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.
Resetting the failed attempts after a correct login almost makes the whole system worthless.
Any registered user could then do three guesses on someone else's account and password, then log in with their own to reset the counter, and repeat — that can be automated, too. So a normal registered user can brute force admin passwords, for example.
The reset needs to be done by the admin, not by simply logging in successfully.
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.
You can count by IP and/or by username. Advantage of IP is that you can block one person trying to hack multiple accounts. If you count by username you can block people using a server farm and won't accidentally throttle people on the same network.
I saw a creative approach to this once...
For each login attempt, that fails, the lockout time increases... exponentially.
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.
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.