41

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.

Community
  • 1
donjuedo
  • 659
  • 1
  • 5
  • 8
  • 87
    Citation needed! Many systems implement throttles, although they may be silent rather than with an explicit lockout; they may also be general site request throttles rather than being login-specific. For ssh (which already has built-in delays), see also the popularity of fail2ban. I suspect the reason you don't actually encounter lockouts often is because they're *well-tuned* to not trigger for normal user behavior, and you aren't actively and persistently trying to crack user accounts. – Xiong Chiamiov Jan 31 '17 at 22:41
  • 59
    The measure of good security is how well it **distinguish** between legitimate user and malicious user. A security system that locks a legitimate user out of their account fails the Availability criteria of the CIA triad (Confidentiality, Integrity, and Availability). Good account lockout policy should be designed so they would never be encountered by legitimate users. If all that matters is keeping the bad guys out no matter the cost to legitimate users, I have the best security system in the world: `function login(un, pw) { return "Sorry wrong password"; }`. – Lie Ryan Feb 01 '17 at 01:28
  • 4
    Adding on previous comments, such throttles will be silent to avoid helping attackers know exactly which protections are employed. –  Feb 01 '17 at 03:45
  • It's fairly common for systems to return their normal "incorrect username or password" message once an account is locked - otherwise you reveal whether an account exists, unless you track every entered username and respond identically. – Matthew Feb 01 '17 at 07:29
  • @LieRyan for example, the new captcha system means a genuine human should not often have to select from the photos – Tim Feb 01 '17 at 08:22
  • 3
    @LieRyan: I learnt CIA as "confidentiality" (nobody else can read it), "integrity" (I am reading what was sent), and "Authenticity" (it's really come from who I think). – Martin Bonner supports Monica Feb 01 '17 at 08:55
  • 4
    @MartinBonner CIA: https://en.wikipedia.org/wiki/Information_security#Availability – schroeder Feb 01 '17 at 17:58
  • 1
    "IT folks impose more and more constraints, like character count, letters, digits, caps, and exclusion of user name from password. " Citation needed. Normally it is pointy haired bosses that add stupid password "strength requirements". https://xkcd.com/936/ – Aron Feb 02 '17 at 05:52
  • Password strength is also important for hacks in which the hacker obtained a hashed list of passwords. If everyones password would be bad, the strength of the hashfunction would be less important. – HopefullyHelpful Feb 02 '17 at 10:51
  • I'm not sure I'd agree with the sentiment that "everyone is aware of the need for strong passwords". Look at any password dump from recent breaches and I guarantee you'll find a high proportion of trivial passwords in there... – Rory McCune Feb 02 '17 at 13:45
  • Why are people still using MD5 for password hashing? Because they don't know better or don't care. @MartinBonner "Authenticity" would be part of, integrity" by your own definition. – jpmc26 Feb 04 '17 at 06:00

6 Answers6

113

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.

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • Its interesting to think that maybe some systems give the *appearance* that it is not being done to mitigate the risk of DOS and identify the baddies (maybe that's what you meant, Mike?) as opposed to systems commonly implementing lockouts. – symcbean Jan 31 '17 at 22:36
  • 4
    @symcbean I wasn't actually thinking of honeypotting. My point was more that a "lockout" of 10 milliseconds is enough to stop a drive-by brute-force attack, so why inconvenience your users for no reason? Now, for phones and PCs with smudges on the screen or people looking over your shoulder, maybe there's an argument for a lockout after 3, but the OP was specifically asking about web servers. – Mike Ounsworth Jan 31 '17 at 22:54
  • On Linux, particularly server setups, there is a service called the Login Failure Daemon (LFD). Instead of disabling a login LFD temporarily bans the ip address attempting the login. – slebetman Feb 01 '17 at 07:47
  • 8
    @MikeOunsworth A lockout after 3 is utterly infeasible unless the device is centrally managed and allows for an unlock via some company IT or such, and even then it's complicated in practice. People mistype passwords 3+ times way too often especially in cases where password change is enforced. – DRF Feb 01 '17 at 09:05
  • DDOS = distributed denial of service attack. You can't do that alone. – John Dvorak Feb 01 '17 at 15:31
  • @JanDvorak That's exactly my point: there's no way a single computer can generate anywhere close to 1 billion login requests per second. – Mike Ounsworth Feb 01 '17 at 16:28
  • 1
    @DRF In my experience, 3-5 attempts for a lockout is actually pretty common practice. My current company's AD is set to 3. I think I've needed the net admin to unlock my account maybe once or twice in over 8 years. I've also had to get the net admin to unlock other users' accounts who were trying to log into a web service I wrote a handful of times over that period. By default, my Samsung phone actually wipes the phone's memory if the passcode is typed wrong 10 times. Judging from the situation with the FBI in the San Bernardino shooter case, iOS apparently uses the same default. – reirab Feb 01 '17 at 21:28
  • 1
    This very much assumes that the goal is to compromise one specific password, and not just "anyone's password" . In that case the attacker (after enumerating user accounts), just tried all the accounts with "Password1" or equivalent and goes from there, probably getting access with a relatively small number of guesses (compared to the numbers needed for a brute-force of one account) this is more relevant in web apps than Linux boxes though, where there's likely to be a large user population. – Rory McCune Feb 02 '17 at 13:38
  • RoryMcCune If you use fail2ban, or some other thing to rate-limit based on IP rather than rate-limit based on requested user name then doesn't it amount to the same thing? – Mike Ounsworth Feb 02 '17 at 13:50
  • 4
    Not to mention that a lockout like this can easily became a DOS attack itself - all you need to do is find the usernames of the users of the service, and "guess" three wrong passwords and voila - the service isn't useable anymore. Especially effective if the admins have no special access, so they can't reverse the lockouts :P – Luaan Feb 02 '17 at 15:25
60

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.

Ken Whitesell
  • 561
  • 3
  • 3
  • Wouldn't you try to lock out the machine (source IP) instead of the user that is being used? That way an attacker would have to be able to (pretend to) originate from the same IP as the legitimate user. Now, while that might be possible, I think it should be much harder... – Thomas Feb 02 '17 at 08:27
  • 1
    @Thomas Bot nets mean that you get to use thousands or millions of IP addresses to try to log into an account. – Yakk Feb 02 '17 at 15:27
  • 1
    @Thomas And how do you store that information? If I have a botnet with ten thousand computers and do the lockout on all users on the system from ten thousand different machines, is your system going to survive? What's the chance I managed to block some legitimate users as well (NAT and such)? How can the user possibly tell why he can't access his account anymore, especially when a good security practice is to avoid telling the user his account has been locked? Can your service handle that? – Luaan Feb 02 '17 at 15:28
  • 1
    Funnily enough, [Stack Exchange itself was used for a password-reset-email flood attack](http://meta.stackexchange.com/questions/270051/please-rate-limit-the-password-reset-functionality) – Bob Feb 02 '17 at 23:59
  • 1
    @Luaan "It is always something" (RFC 1925) – Thomas Feb 03 '17 at 06:56
5

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.

Slava Knyazev
  • 716
  • 5
  • 12
  • The slowing down I imagined might be 1 extra second after the first failure, then 2 seconds, then 4, then 8 and so on. Of course, that has to reset after some criterion is met. With such of a level of delay, even a modest password would seem sufficient (to me, a novice). – donjuedo Jan 31 '17 at 22:16
  • 1
    @donjuedo But for what purpose? With enough complexity, it simply doesn't matter. The server will be a fossil by the time he gets it. – Slava Knyazev Jan 31 '17 at 22:34
  • It's for the purpose of remembering easier passwords, while still maintaining security. – donjuedo Jan 31 '17 at 22:44
  • So to use less complex passwords? That's simply a bad idea no matter how you look at it. – Slava Knyazev Jan 31 '17 at 22:47
  • 1
    We're comparing (complex passwords guessed at high speed) to (less complex passwords guessed at low speed). Neither is inherently better than the other. What's important is what you said, "impractical to bruteforce", or expected time to crack is too long. – donjuedo Jan 31 '17 at 22:54
  • complex passwords guessed at high speed ARE inherently better though. Speed is linear, complexity is exponential. – Slava Knyazev Jan 31 '17 at 22:58
  • 1
    This is a "blame the victim" sort of answer. Choosing an entropic password is a good measure, but one that *users* adopt to protect themselves from attackers. Throttling login attempts in contrast is a measure that *developers* and *administrators* take to protect users from attackers *and themselves*. Developers and administrators can't save *all* users from their own poor choices, but we do have a responsibility to provide reasonable safeguards. – Luis Casillas Jan 31 '17 at 23:42
  • 4
    @donjuedo that will only protect the weak password from bruteforcing *through that single channel*. If e.g. salted hashes get leaked from a database, then the weak passwords would be vulnerable to bruteforcing "around" the server and the throttle, while strong passwords would still be protected. – Peteris Feb 01 '17 at 01:57
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.

Kami Kaze
  • 139
  • 5
2

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.

Rory McCune
  • 61,541
  • 14
  • 140
  • 221
  • Your assumption about the question being related to online brute force is correct. When I posted, I had not even considered an offline attack, and only noticed after it was mentioned here and there. – donjuedo Feb 02 '17 at 14:02
1

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.

dark_st3alth
  • 3,062
  • 9
  • 23
  • 1
    Actually the Windows login screen *does* have a delay. You get a couple of attempts for free, and then it starts to add additional delays. (I ran into this, when I was trying to login with a different keyboard.) – Martin Bonner supports Monica Feb 01 '17 at 08:59
  • @MartinBonner This will occur after the 3rd (or 5th?) wrong entry, where there is a significant delay. If I recall, there is no "rolling" feature, the delay does not become longer and longer. Then again, at this point an account lock out should be triggered. – dark_st3alth Feb 01 '17 at 09:02
  • Lockouts do have their risks though, especially where an attacker is remote, which is that it's fairly easy for them do DoS the service especially if the username format is known. – Rory McCune Feb 02 '17 at 13:42
  • @dark_st3alth Account lockout only makes sense in a domain. While a good portion of Windows machines run in a domain, you can't really ignore all those computers that don't. How would a non-domain user recover from the lockout? – Luaan Feb 02 '17 at 15:30