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 three 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 three 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)

I had the same question in my head... and think that 3 is 'not enough': 1. mistype with caps lock on, 2. mistype with caps lock off, 3. mistype in panic that the account might be locked out...
– NivasNov 19 '10 at 4:25

3

@Nivas: after you have already failed twice, you should be slowing down and watching what you are doing rather than panic typing. Also, usually a lockout is only for some span of time; you might be locked out for an hour, which would limit brute forcing an account to three attempts per hour, and the real user can get back in after an hour (if they can remember their real password by then).
– Mark RipleySep 17 '16 at 6:29

@MarkRipley Our payroll system requires capitals, regular letters, numbers and special characters and the minimum length 16 characters passwords. And after 3 attampts they permanently lock out you, so you need to contact the payroll company in person to get your account back. Ridiculous.
– CalmariusOct 5 '16 at 9:24

Yes. penny-arcade.com/comic/2006/7/12 A good hint can be useful without giving any real information to hackers. It's of particular use in sites that are used exceedingly infrequently, where the question is less "what's my password" as "which password did I use?"
– TrevelNov 19 '10 at 13:39

44

+1000 "Remind the user of password rules." I hate it when I try a text only passwords on a site for a long time just to find out that passwords must have a number it it. Then I remember which password I used and log in.
– EchoNov 19 '10 at 17:33

Another bump for "remind the user of password rules". However, my situation is actually the reverse of @Echo's. Usually, I am trying to use one of my more secure (longer, more complex) passwords and eventually figure out that the site's authentication system has more limited functionality. It's especially frustrating when I go to reset that password, and the site doesn't say anything about the limitations - leaving me to either set another password that won't be "properly" remembered, or wonder why my passwords just won't take.
– IsziJun 2 '11 at 14:33

Scary and depressing find. They require steel doors and multiple keys for the back door, but the front door is unlocked. To be charitable, is there any chance that there is financial (fraud and theft) data that backs up the 6 attempts limit?
– rox0rNov 19 '10 at 15:08

3

That said, if I fail 6 attempts and have to wait 30 minutes, it isn't too bad. It isn't like a lock-out that requires an explicit admin unlock. I'd love to see their research that lead to the number 6 though...?
– Dan McGrathNov 19 '10 at 22:28

5

PCI as a rule set a minimal baseline, a least-common-denominator, if you will. While I doubt that the number 6 is all that important and backed up by research, for their purposes they HAVE to put in some number, otherwise whats the point of enforcing compliance? 1000 attempts is just as valid, and yet pointless (though probably still have the same mathematical effect). Also see security.stackexchange.com/q/622/33
– AviD♦Nov 22 '10 at 10:48

2

Is there any security advantage to hacking an account lock out for 30 minutes after six attempts, versus allowing one attempt every five minutes after the sixth attempt? Both will require the same amount of time for brute-force attempts, but the latter would make denial-of-service attacks somewhat less effective.
– supercatFeb 2 '14 at 21:21

2

6 is just too low. I have to log into a number of sites some of which require me to change my password on a regular basis, even though I log into them rarely. In essence I must have at least 20 password combinations in my head. I don't write them down, so will happily sit trying a number of combinations. Only certain sites then lock me out (usually without telling me they've done so). I'd much prefer to see at least 10 attempts.
– Chris NevillJul 2 '14 at 21:20

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.

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.

Make sure you account for the attacker changing user names. A brute force attack doesn't have to be a depth first. They could go breadth first, picking a password and changing the user name.
– Dan McGrathNov 19 '10 at 13:21

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.

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.

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.
– DominiqueMay 22 '11 at 22:44

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.

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 key space, any kind of throttling (X number of tries per hour) will ensure that brute forcing 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 trade-off.

I think historically, the trade-off 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, three really doesn't 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.

(As @realworldcoder mentioned, PCI arbitrarily chose six, and if you are subject to PCI you don't have much decision here. Otherwise, choose a number that makes sense for you.)

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

Great points. It doesn't even have to be that sophisticated. They could do the breadth first attack and a spaced out weeks long attack. But the delays do give you a known maximum rate of attack though (if you disregard source IP). If you lock the account after 10000 (any high number) failures in a row, you trade a DoS (if the administrator doesn't pay attention) for getting cracked (assuming 2 factor is out of reach).
– rox0rNov 19 '10 at 13:39

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.

Here's a really nice read that goes over what I believe you're looking for. They took data from undergraduates using a three-strike policy, ten-strike policy, and infinite-strike policy in order to suggest we raise the number from three to ten (since it approximately triples the success of logging in).

Getting back into a subjective view here...

Why do most places use a three-strike policy? It's certainly just a heuristic that developed over time. Three attempts is more or less a middle ground for administrators and users, in that three chances are more than enough.

The idea behind a password is you're supposed to know it. You really shouldn't need more than one try. I understand that mistakes are made, but in a war... you really only get one chance to prove you're an ally, right?.

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.

The problem with lockout according to IP, is that this can also be bypassed or misused. E.g. a distributed attack... And what happens if a single IP is shared by many users, e.g. corporate proxy?
– AviD♦Nov 22 '10 at 11:03

A distributed attack would be more brutal if you didn't have this in place. No matter what you do, it will always heighten the level of the threat. / If users are hiding behind a proxy they would just have to wait. It could be a hacker using a proxy and not a real user. The thing is you never know and that's the consequence for being anonymous. You shouldn't compromise security for convenience.
– Rush FrisbyAug 10 '11 at 22:38

This is not about compromising security, its implementing measures that do not have anything to do with the threat you're trying to prevent. A distributed attack would be brutal, yes, but from a DoS point of view, not a password-bruteforce one. Users are often forced to use a proxy, often without even knowing about it - they are not "hiding" behind it.
– AviD♦Aug 10 '11 at 23:06

That is one of the most destructive mis-conceptions that are so incredibly popular, unfortunately. "Better safe than sorry" might be valid (arguably), IF there were no other associated costs or drawbacks involved. In this case, there definitely are, and you would wind up with a substantially worse solution. "Security at the expense of usability comes at the expense of security".
– AviD♦Sep 21 '16 at 10:12

Brute force attempts quite possibly don't come from a single end point which makes the 'close browser' a moot point.
– Dan McGrathNov 19 '10 at 13:39

2

@Dan, you're right - but they might even come from the SAME endpoint, but without a browser. And, sessionless - each request is a new session. so "session was ended" is also pointless
– AviD♦Nov 22 '10 at 10:53

In this particular case it was impossible to get to this point without having session enabled. But admitedly a better approach would have been to maintain the locking statistics in the database. For us we had a certain set of event ID's being logged, and monitored. If at any point a large number of attempts had come in for the same user... we would have known pretty quickly.
– JoshNov 22 '10 at 14:02

2

I think AviD's point is that the session component could be automated in which case you are only defeating brute-forcing via browsers (ie: a person attempting brute force or ugly browser automation). The other issue is that the response delay is more likely to hit valid users, rather than discourage an automated brute-force attack. If 99% of users get it right in under 10 tries and you can't be brute forced in 10 tries, it's probably a good idea to set the limit to 10 (made up numbers for an example).
– rox0rNov 22 '10 at 15:27