111

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)

kalina
  • 3,374
  • 5
  • 21
  • 36
Bradley Kreider
  • 6,182
  • 2
  • 24
  • 36
  • 23
    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... – Nivas Nov 19 '10 at 04: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 Ripley Sep 17 '16 at 06:29
  • @MarkRipley time bound lockout makes sense. – Nivas Sep 19 '16 at 13:27
  • @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. – Calmarius Oct 05 '16 at 09:24

13 Answers13

77

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.
Zian Choy
  • 1,131
  • 8
  • 8
  • 46
    I absolutely hate "password hints". Is that mechanism actually useful? – Andrew J. Brehm Nov 19 '10 at 09:47
  • 11
    Yes. http://www.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?" – Trevel Nov 19 '10 at 13:39
  • 45
    +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. – Echo says Reinstate Monica Nov 19 '10 at 17:33
  • 4
    @Echo: Perhaps you should look into [LastPass](http://lastpass.com/) – BlueRaja - Danny Pflughoeft Feb 23 '11 at 17:46
  • 4
    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. – Iszi Jun 02 '11 at 14:33
  • 2
    @Trevel Sometimes the hints can be used in [unintended](https://xkcd.com/1286/) ways. – kasperd Aug 15 '15 at 23:44
38

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.

Edit: Note that these requirements only apply to systems for "non-consumer users" so they shouldn't affect customer sites accepting cards.

SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
realworldcoder
  • 1,123
  • 11
  • 10
  • 1
    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? – Bradley Kreider Nov 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 McGrath Nov 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 http://security.stackexchange.com/q/622/33 – AviD Nov 22 '10 at 10:48
  • 3
    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. – supercat Feb 02 '14 at 21:21
  • 3
    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 Nevill Jul 02 '14 at 21:20
  • so now I know who came up with retardation like that – Enerccio Jun 03 '19 at 08:02
22

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.

Tate Hansen
  • 13,794
  • 3
  • 41
  • 84
18

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.

Gary
  • 904
  • 7
  • 12
  • 15
    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 McGrath Nov 19 '10 at 13:21
  • @DanMcGrath Some relevant note on this: [Do Strong Web Passwords Accomplish Anything?](http://research.microsoft.com/pubs/70445/tr-2007-64.pdf) – Gumbo Nov 30 '11 at 08:55
16

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.

itinsecurity
  • 161
  • 2
12

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.

AmaDaden
  • 221
  • 1
  • 2
  • 2
    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. – Dominique May 22 '11 at 22:44
10

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.

Vineet Reynolds
  • 1,246
  • 11
  • 13
8

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

Community
  • 1
AviD
  • 72,708
  • 22
  • 137
  • 218
7

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

Dan McGrath
  • 219
  • 1
  • 3
  • 1
    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). – Bradley Kreider Nov 19 '10 at 13:39
3

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

3

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.

Jose
  • 31
  • 2
2

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.

Rush Frisby
  • 360
  • 1
  • 2
  • 11
  • 3
    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 Frisby Aug 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
  • Better safe than sorry. – Rush Frisby Sep 20 '16 at 13:56
  • 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
  • Damn y u so mad bro? No one sits there and tries to reset their password thousands of times. Only bots. F those bots. That's bad security if you let them back in when you know what it is. – Rush Frisby Sep 21 '16 at 13:42
  • Heh sorry if I came off sounding mad, not at all. And you're right, if a single user is trying the wrong password a thousand times, you can be darn sure it is some form of attack. But the point is, you lose that when swapping to IP address. Sure, track it, compare to other attempts, maybe even stick them in a graylist - but don't ignore the wider context, and typical valid usage scenarios (not to mention, how little IP address really constrains an attacker). – AviD Sep 21 '16 at 15:29
2

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.

Josh
  • 121
  • 2
  • 2
    Brute force attempts quite possibly don't come from a single end point which makes the 'close browser' a moot point. – Dan McGrath Nov 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. – Josh Nov 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). – Bradley Kreider Nov 22 '10 at 15:27