Why hasn't it become the norm to inhibit repeated password guesses?

Question

Everyone is aware of the convention/need for strong passwords. With the number of different kinds of clues people can use in their passwords, plus the various permutations of caps and digit-letter substitution, a hacker would need to make many attempts on average, in order to get the successful password.

This link: Slowing down repeated password attacks discusses some effort to discourage all that guessing, although it's not the same question I have: Why hasn't it become the norm to interfere with repeated guesses? An increasing backoff time after each wrong guess is one way, and others have been discussed.

I have seen very few attempts to inhibit such guessing on Linux systems, or any web-based authentication. I have been locked out of one system when I got it wrong 3 times.

IT folks impose more and more constraints, like character count, letters, digits, caps, and exclusion of user name from password. But that simply increases the number of needed attempts in a situation where the number is not really restricted.

Answer 1

I'd like to challenge your assumption that this isn't being done.

[warning: wild approximations to follow]

Remember that a successful brute-force attack will require millions or billions of guesses per second to do the crack in a reasonable amount of time (say, a couple hours to a month depending on the strength of your password). Even a rate-limit of 100 password attempts per second would increase the crack time from a month to hundreds of thousands of years. Maybe my standards are low, but that's good enough for me, and no human user legitimately trying to get into their account will ever notice it. Even better if the rate-limit was by IP rather than by username just to prevent some kinds of Denial-Of-Service attacks.

Also, I don't know which Linux distribution you're using, but on my Ubuntu and CentOS systems, when I mistype my password at either the GUI or terminal login screens, it locks for 1 second before re-prompting me.

---

Even if the server isn't actively rate-limiting login attempts (which they really should be), just the ping time by itself is enough to slow you down to millions of years. You'll probably DDOS the server before getting anywhere close to 1 billion guesses / second. The real money is in getting a copy of the hashed passwords database and feeding that into a GPU rig where billions of guesses per second are possible.

TL;DR: if you are going to put effort into hardening your login server, you'll get more bang for your buck by improving your password hashing, and making your database hard to steal than by implementing rate-limiting on your login screen.

---

UPDATE: Since this went viral, I'll pull in something from the comments:

This logic only applies to login servers. For physical devices like phones or laptops, a "3 attempts and it locks" or a "10 attempts and the device wipes" type thing still makes sense because someone could shoulder-surf while you're typing your password, or see the smudge pattern on your screen, or know that a 4-digit PIN only has 10,000 combinations anyway, so the number of guesses they need to do is very very much smaller.

Answer 2

There's one significant problem with locking people out after repeated invalid attempts - it actually becomes an attack vector for a type of Denial of Service attack. Think about what might happen to a support desk or customer service site if a couple hundred thousand accounts all end up locked on a consistent basis by someone trying to disrupt a service.

There's even a web site I use that sends me a physical piece of mail every time I change my password - someone particularly nasty could really create problems by finding a list of accounts and suspending them repeatedly.

There's definitely a judgement call to be made between security and usability, and I personally don't believe there's a fixed or pat answer.

Answer 3

Enough complexity makes it technologically impractical to bruteforce, slowing it down wouldn't do much more.

"But that simply increases the number of needed attempts" is a weird way if saying billions of years longer.

Answer 4

You assume that passwords can only be checked by using the login. But quite often there is a data leak/hack that let's someone get the hashtables of the password. If he has those, he can just bruteforce for the hashes, which is several times faster than using the login. And that's where you really need good passwords.

Answer 5

A very important concept that I don't see mentioned in the other answers so far is the differentiation between offline and online brute force.

In offline bruteforce the attacker has access to the hashed passwords and here the main defence is using an appropriate password hashing algorithm (e.g. bcrypt). points around hashing algorithms, GPU cracking etc, only relate to offline bruteforce

I'm assuming that this question related to online bruteforce where the attacker is trying to log into the system likely remotely.

With remote logins for services like SSH, as has been mentioned, remote password guessing is commonly inhibited through fail2ban or similar.

Where it's not common is in web applications (I know 'cause I give owners of web applications findings for lack of this feature fairly commonly).

A straight lockout is setup in some systems, but this faces the risk of denial of service from attackers password guessing attacks and also some user inconvenience depending on the mechanism for re-activating accounts.

A better solution is forcing an increasing delay in login attempts to make the attack less feasible, however it's important to note that in some cases an attacker may just want to compromise one account (and not really care who's account they get) in which case they can just attempt a small number of common passwords across the userbase, with the expectation that someone will have used them.

Answer 6

The easy way to look at this is with another question. Why is SHA-1/MD5 still in use when there are known flaws/issues with it?

Simply put, the risk assessment of the individual/corporation deems those issues not to be of major concern. Just as in the case with rolling timeouts.

When I did some administration for a local school, it was quite common for teachers to "guess" their own passwords. Forcing teachers to wait was much more of an inconvenience, then just locking an account out after 4 or 5 incorrect passwords and having them phone me to unlock it.

Rolling timeouts are also a major pain to deal with. For a local system, this might not be an issue, but take my school example (just as above), or a large enterprise with over 1,000 employees. Work can no longer be done because someone is sitting at a password prompt, waiting for the chance to enter the correct password. Perhaps someone thought it would be funny to get someone to sit at a prompt for a few hours, or an attacker wanted to slow production down? Factor in that there has to be a way to administrate how long the timeouts are, how much they increase by, and a way to reset them.

I would argue that a lock out system, such as that allowed by Windows, is actually more secure. It requires administrative intervention, and can be much faster to undo (plus the time taken to look at logs). On a web based system, a rolling timeout could be more beneficial, but as we have seen already, password hashes will be leaked and rolling timeouts would be of no help.