I've seen the following login rate limiting approach used on a web site I worked on, but I can't figure out if it's a good idea:

After any failed login attempt, the site locks the user account for a fraction of a second. When the account is locked, any login attempts will fail, even attempts with correct credentials. The user is not told that their account is locked, only that their login failed.

The idea is that real users will generally take longer than the lockout time to re-enter their credentials (and will probably re-enter them more slowly the third time if they accidentally trigger the lockout). Meanwhile, hackers brute-forcing passwords would trip the lockout with high-volume login attempts.

What are the problems with this approach?

  • Related: stackoverflow.com/questions/1622952/…
    – atk
    Apr 8, 2015 at 14:49
  • To have less impact on the user, you could add a sleep after they fail logging in - this way, the user will not accidentally trigger the possible lockout false negative. It will still affect the "hackers", because the account will be locked in the meantime - you're trying to protect the legitimate user from that.
    – Luaan
    Apr 9, 2015 at 8:22
  • 4
    The issue with using sleep is that the hacker knows they're locked out. Without sleep, a hacker who sends in login requests as fast as possible will never actually log in (unless they got the credentials right on their first attempt). With sleep, every attempt has the possibility to succeed, so a patient hacker will eventually get the right credentials.
    – James_pic
    Apr 9, 2015 at 9:20
  • "real users will generally take longer than" "a fraction of a second" - Yes, any real user will always take longer than a fraction of a second. Where could the "problem" be?
    – MrWhite
    Apr 13, 2015 at 18:11

7 Answers 7


There's a growing number of what I am calling "slow brute force attacks". Where a bot net with a listing of targets makes a low number of attempts at regular intervals to each target in effort to not get caught by the usual methods of monitoring fast attacks.

I manage a number of websites and I typically see failed login attempts ranging from 3 to 10 attempts on multiple unrelated sites with the exact same user names and password combinations. Typically it is an alphabetical list, but not always. The attempts will usually happen once a day for any number of days.

The sophistication of these hacking attempts is very low, but they would likely be able to bypass a brief lockout as you describe. Any user with a weak password can/will eventually be compromised, and the attack is designed to stay below the radar.

Your method might be very useful for a specific type/speed of fast attack, but it should be just one of many tools if you choose to use it at all.

  • Here's what I read: "I typically see user names and password combinations." Nov 17, 2015 at 16:25
  • 1
    YES. For failed login attempts I log the username and password combinations, as well as IP and time. This allows me to block persistent IPs if I wish. I also get to see any trends in hacking attempts like I mentioned alphabetical lists, username=admin, etc. I can also tell if any attack is coming from a single IP or multiple. One potential flaw is that I can also see when a valid user mis-types their password (or username). Should that data fall into the wrong hands it could be compromising. I must clean the logs with some frequency to mitigate this.
    – KnightHawk
    Feb 3, 2016 at 15:11

A brute-force can implement pauses to match the short lockout gap you are presenting, so this would slow down a brute-force script. However, locking the account permanently (or forcing CAPTCHA & security question in addition to future login attempts) after x-number of consecutive failed attempts is a better way to accomplish that goal. Your approach does have a little merit, but you would certainly want to couple it with the traditional anti-brute methods.

  • 2
    It has one benefit - the brute-force script is not limited in the request rate, so if it tries 1000 passwords per second, it will be rejected 999 times out of 1000 even if it guesses correctly.
    – Luaan
    Apr 9, 2015 at 8:23
  • Right. Small victories like that are why I mention that the technique does have some merit. But it obviously isn't a robust enough defense for known attacks, so if used it should be coupled with other techniques.
    – armani
    Apr 9, 2015 at 15:20
  • Which is of course the tricky part. Most of the additional layers will eliminate all benefit from this technique, I think.
    – Luaan
    Apr 9, 2015 at 15:22
  • Yeah, exactly. Notice that I never said the OP should implement this. =P
    – armani
    Apr 9, 2015 at 15:24

I like the silent approach. As a penetration tester who frequently does testing for PCI compliance, I run into account lockout issues regularly. PCI-DSS requires that accounts be locked out for a minimum of 30 minutes (or until unlocked by an administrator) after six failed login attempts. My problem with a messages stating the account has been locked is it makes it very simple to cause a Denial of Service on a user. This can also be used to enumerate valid user accounts (though if you are brute forcing, one would assume that a valid account is already known).

If you increase the delay until a "max threshold" is reached, then lock the account out for an extended amount of time, the approach seems perfectly valid to me. In addition you should also reset the clock anytime another authentication attempt is made.

  • 6
    Yup, I've seen the locking used as a denial-of-service by a fired employee (remote access.) They didn't have any ability to do harm to the data but everyone was locked out until things were reset from the console itself. Apr 8, 2015 at 2:21

The implementation of this would be tricky to get right. You'd have to consider various ways an attacker might realize that something is up. My first immediate thought is that an attacker might notice that a rate limited failed login returns faster than a normal failed login. Or perhaps the message returned is slightly different, inadvertently.

In any case, this shouldn't be the only line of defense. A total lockout is an inconvenience to a user, but so are hacked accounts. At minimum, the site should continue failing all attempts to login with the same algorithm, but force a total lockout until the user resets their password. They should also be notified by email or SMS, just once, that multiple failed attempts happened; they will know if they did it or not.

Overall, I think the implementation isn't worth the time compared to just locking out the user or requiring a captcha or secondary password, like a security question, after a few attempts.

  • Well, the OP still has to check if the user is locked-out first - presumably by the same query to the database as for the usual case, and only checking the lockout setting after getting the query result back (to make sure query plan optimization doesn't make the response time suspicious). As for security questions, ewww :D
    – Luaan
    Apr 9, 2015 at 8:30

Most delay based lockout mechanisms specify a progressive delay. If the delay does not increase over time, it may not be enough to stop an adaptive brute forcing program - one that slows down to meet the small delays. The downside in the original example is that it may not slow down the brute force enough. The downside in an algorithm that increases the delay is that it might lockout legitimate users.

  • The OP intends for the lockout error to show exactly the same as an incorrect password - the attacker shouldn't realize that failure is due to a lockout.
    – Luaan
    Apr 9, 2015 at 8:36

I don't think you want to lockout a user this way, you want to lockout the endpoint. There are two reasons that you would do this: Firstly if a user is trying to login at the same time his account is hacked he would be unaffected since he is not logging in from the same endpoint, secondly the attacker may not be just targeting one account so this will lock them out when trying multiple accounts as well as single accounts.

As others have pointed out you do not want to alter your timing or neglect other lines of defence.


I think lock IP temporarily is not provide good security. Because attacker will change their IP by proxy and try with different IPs. It can be overcome by two methods.

1. Add captcha verification in login page

2. Add lock IP temporarily.

In WordPress, We can add plugin for it. https://wordpress.org/plugins/wp-limit-login-attempts/ plugin providing these two feachers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .