Update 2015-12-03: I just found out from a response tweet from @jacobian that the user flogging is apparently a requirement of the PCI standards, and thus many online services are essentially forced into it. Would love feedback or further information from anyone familiar with how PCI standards get baked.
Calling all designers of online systems that do user authentication… Wait, that could be shorter:
Calling all designers of online systems:
Please stop locking out users after three failed login attempts.
That security measure is left over from the days of Unix consoles that were just dumb terminals connected to a server somewhere else in the building. It makes less and less sense in the modern era. These days, large distributed botnets are engaged in constant automated login attempts against all publicly reachable online services of any size, using guessed username/password combinations, on the principle that only a tiny fraction of the attempts need to succeed for the effort to be worthwhile. The result is that users with strong passwords but human-readable usernames are penalized for being the target of failed hacking attempts.
It happened to me recently:
From: Karl Fogel To: Mailing List Of Various Techie Friends Subject: Speaking of passwords I just found out from a rep that the reason Wells Fargo Bank kept resetting my (incredibly secure) online access password, thus forcing me to do a password reset dance about twice a month, is that online accounts get automatically locked after three failed login attempts. Since my username was "karlfogel" -- it's changed to something less guessable now -- some jerk with a botnet was causing Wells Fargo to lock me out on a regular basis, presumably by trying a username generated from my real name and passwords that were various combinations of my birthday, relative's names, etc. The same is probably happening to thousands of other customers. After all, the hackers only need a tiny number of successes. I wonder if Wells Fargo has really thought carefully about the usefulness of a 3-failures lockout policy in the modern era of distributed attacks against your entire user base. This was not a topic I felt it profitable to take up with the phone rep, though. *cough cough*.
Every time you force your users to do a password reset dance, which usually involves some kind of email confirmation step, you are decreasing their security. First, because if a user is forced to change her password frequently, she is likely to start making passwords that are easier to remember, because why invest in memorizing a hard password if one is just going to have to reset it soon anyway? Second, and more importantly, because you are giving hackers the power to lock someone out of their own online account, which creates two vulnerabilities: one, now the hacker has an additional attack surface (the user’s email account), and two, your user support staff also becomes an attack surface because the hacker can now call up and impersonate the legitimate user, saying “Help, I’m locked out of my account” — a fact that the support rep can easily confirm, and which will lend credibility to the hacker’s attempt at social engineering.
Just as a general principle, it’s usually not good to allow attackers to change the behavior of the system for legitimate users. When you allow that, you give the hackers more material to work with, and they will always be more imaginative than your programmers or your support reps, because once they sense that they have a good target, they can spend all day thinking about how to approach it.
It’s fine to have a delay between login attempts. Maybe it’s even okay to increase the delay somewhat when there are a suspicious number of failed login attempts for a given user (although I’m not sure about that, and it is a minor violation of the general principle above).
If you want to help users who have weak passwords, have your security team run guess-in attempts itself (without the rate-limiting), or even run cracking attempts against the password database itself, and then follow up with the users whose passwords fail the test. You can just let them know the next time they log in, or if you want to provide especially deluxe service, follow up via an automated phone call or something. Don’t let them know by email, though: it’s not a great idea to send cleartext email across the Internet telling someone their password is insecure.
But don’t treat failed login attempts as special events that need some kind of reaction. They are more like spam: inevitable, ubiquitous, and best handled in ways that have no effect on the target. It’s not your users’ fault that people are trying to hack into their accounts, so don’t punish them for it.
Agree? Feel free to retweet #EndLoginFailureLockout, or redent.
Addendum: One of my friends on that mailing list followed up with this story:
Anthem Blue Cross, in order to let you make online payments, redirects you to a random payment processing with a scammy-sounding domain name, which tells you the following: 1. You need to make a new account with us because we're not tied into Anthem's database. Because, you know, I can personally take credit cards - but that's apparently beyond the capability of the largest health insurance provider in the country. 2. By the way, you might already have an account with us from some other place, so you'll have to log in with that account instead. No, we can't tell you whether that's the case or not. 3. You must choose a password between 5 and 8 characters. I'm not kidding. 5-8 characters. I make my payments over the phone.