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.

  • 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. Jan 31, 2017 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 1, 2017 at 1:28
  • 4
    Adding on previous comments, such throttles will be silent to avoid helping attackers know exactly which protections are employed.
    – user121968
    Feb 1, 2017 at 3:45
  • 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). Feb 1, 2017 at 8:55
  • 4
    @MartinBonner CIA: en.wikipedia.org/wiki/Information_security#Availability
    – schroeder
    Feb 1, 2017 at 17:58

6 Answers 6


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.

  • 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. Jan 31, 2017 at 22:54
  • 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 1, 2017 at 9:05
  • 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 1, 2017 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. Feb 2, 2017 at 13:38
  • 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 2, 2017 at 15:25

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.

  • 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 2, 2017 at 8: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 2, 2017 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 2, 2017 at 15:28
  • 1
  • 1
    @Luaan "It is always something" (RFC 1925)
    – Thomas
    Feb 3, 2017 at 6:56

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.

  • 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, 2017 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. Jan 31, 2017 at 22:34
  • 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, 2017 at 22:54
  • 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. Jan 31, 2017 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 1, 2017 at 1:57

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.


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.

  • 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 2, 2017 at 14:02

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.

  • 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.) Feb 1, 2017 at 8: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. Feb 1, 2017 at 9: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. Feb 2, 2017 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 2, 2017 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .