Why do sites implement locking after 3 failed password attempts?

Question

I know the reasoning behind not letting infinite password attempts -- brute force attempts is not a meatspace weakness, but a problem with computer security -- but where did they get the number 3 from?

Isn't denial of service a concern when implementing a lockout policy that is easily activated?

Is there any hard research showing an optimal number or range to choose before locking out an account that balances actual security threat with usability?

Thinking it through, I don't see any measurable security difference between 3 attempts and 20 attempts with the password complexity generally in use today.

(i know this skirts subjectivity, but i'm looking for measurement based opinions)

Answer 1

Recently, at the OWASP AppSec 2010 conference in Orange County, Bill Cheswick from AT&T talked at length about this issue.

In brief, there's insufficient research.

In long, here are some of his ideas for less painful account locking:

• Don't count duplicate password attempts (they probably thought they mistyped it)
• Make the password hint about the primary password, and don't have a (weak) secondary
• Allow a trusted party to vouch for the user, so he can change his password.
• Lock the account in increasing time increments
• Remind the user of password rules.

Answer 2

Any website that complies with PCI Data Security Standards has to adhere to sections

• 8.5.13 (Limit repeated access attempts by locking out the user ID after not more than six attempts)
• 8.5.14 (Set the lockout duration to thirty minutes or until administrator enables the user ID).

This is unfortunately why a lot of sites accepting credit cards have draconian lockout policies, even though their designers may not necessarily agree with what they've implemented.

Answer 3

My experience is lock out mechanisms are diminishing in popularity (at least for web apps). Instead of locking accounts out after a series of failed attempts, you begin to ask for additional information for successful authentication.

Answer 4

Wouldn't be surprised if it came from the baseball "Three strikes" rule rather than anything technical.

One justification (for alphanumerics passwords anyway) is

Typically a failed attempt is either a mis-type or a CAPS on/off issue. So you try to log on and get rejected (1), try again because you think you mis-typed (2) and then realize the CAPS key is on so you get in on the third attempt.

Doesn't really hold for unlocking mobile phones from a network when it is typically a numeric code being entered.

Better suggestions are an ever-increasing delay between successive failed login attempts. First you allow an instant retry, then 1 second, 2, four, eight... You are quickly waiting a minute between attempts which is enough to symie any brute force attack.

Answer 5

I agree with the OP. If you think about what the lockout protects you against, there is no difference between 3 or 20 attempts (or 100, for that matter). All you achieve with these lockouts, apart from punishing forgetful users, is to prevent a brute-force attack. You can also user it to trigger a warning that an attack is on-going, but that isn't the primary purpose (if it were, it means you are deliberately DoSing your users just to make your own monitoring job easier. That's not a very good practice).

If someone has your password database, and can hack away at it off-line, they have unlimited tries. Your 20 guesses limit is no good there.

If someone is attempting an on-line brute-force, all you need is a password that can withstand for "long enough": long enough for your IRT to respond, or long enough for your attacker to give up.

The Conficker password database is slightly below 200 passwords, IIRC, and it is filled with some of the dumbest passwords on the planet. Now let's assume that your password is not on this list. If you allow 20 password tries, say per 15 minutes, without locking, it will take an attacker more than two hours just to get through that list.

In fact, even if you narrow your guessing list down to passwords made from relevant info about that user, like kidsname02, birthday99 etc, you will still end up with at least a few tens of passwords, extending a dictionary attack to maybe an hour or more. That constant, erroneous guessing over time is what should trigger your alarms, not a handful of wrong passwords in a couple of minutes.

So, if you can keep your users away from the most basic password pitfalls, you can happily accept a lot of erroneous password attempts.

Personally, I draw the line at 15. Totally arbitrary, and mostly a practical thing: I find that any real user has given up long before this. Usually if there's that many attempts, it's a process or session that's hanging somewhere with old credentials. And if that's not the case, then we can talk about looking for attacks.

Answer 6

There are two aspects to this.

The first, as you mention, is preventing brute-force attacks.
For this purpose, really any number of tries should do - 3, 5, 20, 2000... with a proper password policy (length+complexity+...) giving a large enough keyspace, any kind of throttling (X number of tries per hour) will ensure that bruteforcing the entire space would take quite a few decades. (Do the math).
Even if - and this should be a requirement - the lockout is only temporary, and after a short period of time it automatically unlocks.
Thus, the number of tries-before-lockout is arbitrary.

However, there is another, more subtle, non-mathematic issue at play here:

It simply does not make sense for a single user to repeatedly put in a wrong password 2000 times in a row.

That is, if you arbitrarily choose 2000, you know long before then that this is NOT a legitimate user. Thus, it really comes down to what makes business sense, and a business-focused risk-analysis tradeoff.
I think historically, the tradeoff was more slanted towards the risk side - since passwords were shorter and less complex, the difference of 3 or 10 was larger. Also, people had fewer passwords, so they were easier to remember... And, users were more technically savvy in general.

Nowadays, 3 really doesnt make sense, considering business impact. It's really a question of what makes sense for your app, what types of users, how often they login, etc. I usually recommend to figure out how many failed, legitimate attempts are likely, then double it.

(Btw, as @realworldcoder mentioned, PCI artbitrarily chose 6, and if you are subject to PCI you dont have much decision here. But otherwise, choose a number that makes sense for you.)

Answer 7

I believe I'm late to this debate, but I hope I have something useful to add here.

The account lockout policy (with the number of consecutive invalid attempts usually in the range of single digits for most organizations) was not devised solely against automated brute force attacks.

It is more of a protection against password guessing by human attackers, especially by individuals who already know of a portion of the password. Attackers could gain password fragments by

• shoulder surfing
• by guessing the patterns employed by an individual for choosing their passwords. After all, how many times has one used passwords with elements in a sequence, like password#01, password#02 etc.

The downside of course, is that with a low threshold value, there is bound to be a denial of service, and an associated cost to business. The Account Lockout Best Practices White Paper issued by Microsoft, provides a recommended value of 10. It also explains how to estimate the probability of a successful attack, using the parameters in the account lockout policy of Windows:

As an example, assume that the administrator resets the password when the account is locked with LockoutDuration registry value of 0. With the LockoutDuration registry value set to 0 and the LockoutThreshold registry value set to 20, the malicious user has 20 guesses to use against that password. If the lockout duration is 30 minutes, the malicious user has 20 guesses every 30 minutes against that password until it is changed. This is a very significant difference in the total number of guesses that are available to the malicious user.

In comparison, if the administrator sets the maximum password age to 42 days, the first malicious user has only 20 guesses against any given password, while the second malicious user has 40,320 guesses (20 tries for ever lockout, multiplied by 48 lockouts every day, multiplied by 42 days before the user changes the password). With the default password settings, there are approximately 10^12 possible passwords. This means that the malicious user has approximately a .000004 percent (%) chance of guessing the password. With an optimized guessing scheme, this percentage would most likely be a larger percentage.

Of course, it is not easy for any layman to choose a suitable number, and such decisions ought to be carefully considered. Therefore, it could be safely assumed that some organizations haven't put in the effort to calculate the monetary effects of their account lockout policy, and the associated benefit of relaxing their policy while retaining the security benefit that it provides.

Answer 8

In regards to the suggestions of time incrementing 'lock-outs' to delay successive failed attempts and hence prevent brute forcing, do please remember this only works on targeted user attacks.

If the attacker only cares about gaining entry to the system, they could perform a breadth first attack (Cycle all known/guessed user names before cycling to the next password). Add that if it was done properly it could come from a distributed network of machines, it is quite easy to see that the delay system doesn't work either.

As mentioned by others, correct monitoring of failed attempts to discover attacks early is critical.

Yes, 3 attempts is quite arbitrary and poses a DoS risk. I really wish people would stop using for public facing systems... Please!

Another solution: 2 factor identification. RSA tokens. If only we had a way to personally own a single RSA token with an 'id number'. We could then register this 'id number' with any system, which would then require the current value from the token along with the password to log in.

But that poses a whole other bunch of issues for implementation and trust...

Answer 9

It's a silly arbitrary rule that comes with a risk of a strange kinda of DDOS attack. Lets say Marv hates website X and web site X has a Y number of attempt lock out policy. Marv could raise some serious hell by having a script automatically try random names Y times with bogus passwords. Even if a password worked Marv would likely not care and ignore it. This would effectively lock out many users for website X and causing lots of user frustration, and god help them if they are bank that you need to call in to reset your password. I'm surprised no one has tried this.

Answer 10

Companies that are public (sell shares in stock exchanges) are regulated under Sarbanes-Oxley Act and are audited several times a year for compliance. Critical software applications must comply with certain security features been one of them to lock accounts after failed password attempts.

Majority of these application what they do is to integrate into the company Active Directory that already have the features enabled.

Answer 11

They must have chosen 3 at random. This is extremely low. Perhaps they have had security problems in the past and have chosen a low lockout number rather than address or fix the problem correctly.

I prefer the method of locking the user out in increasing time increments. I would not key it off of the user name though, instead use the person's IP address, because the person could be trying multiple user names. I set the lockout time to (number of invalid login attempts) ^ 2 seconds, once the user has reached 5 invalid attempts. If the user doesn't know their password in a relatively low number of attempts they will mostly use a password recovery tool if the site provides one. If it is a true hack attempt it will become so frustrating for the hacker that eventually they will give up. Bots will try so many times they will almost never be allowed to login... for example, if they tried 1000 passwords (which would take a long time to actually do anyways) they would have to wait 11 1/2 days before they could try the 1001th password. You could easily increase the deterrent-ability by increasing the multiplier to ^ 3. Anything above that might get a little too high for valid human users.

Answer 12

Not too long ago I implemented a login security scheme that followed these basic rules:

1. First failed attempt gives immediate feedback. They probably fat fingered it.
2. Second through fifth failed attempt caused the response to be delayed by one second per failed attempt. eg. 2 seconds, 3 seconds, 4 seconds...
3. If the fifth attempt failed, then the session was ended and they were presented with a message indicating they would have to close their browser and try again.

To me this was more than adequate to prevent brute force attacks; would be at most an inconvenience to end users, and didn't create any additional work for support.

Answer 13

I think the arbritrary nature of using '3' as the max number of attempts has been answered by most of the previous posters already, but I did want to second AmaDaden's DoS scenario. It is a relatively low-tech attack and could cause a great deal of damage business-wise, especially if a website does not have enough back-up resources to deal with it.