Silently Limiting Login Attempts

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.