Limiting user login attempts in PHP

Question

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!!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!".

"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.

Answer 5

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:

• The IP address (or the first 24 bits of it)
• The action that was attempted (ie 'log in', 'search', 'comment')
• The time of the attempt
• Number of attempts (attempt counter)

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.