Password strength is now everything, and they force you to come up with passwords with digits, special characters, upper-case letters and whatnot. Apart from being a usability nightmare (even I as a developer hate it when a website requires a complex password), what are the actual benefits of having strong passwords (for website authentication)? Here are the prerequisites of a system that handles authentication properly:

  • store passwords using bcrypt (or at least use salt+hash) - hard-to-impossible to find the original password when an attacker gets the database
  • lock subsequent password attempts with a growing cooldown - no brute-force via the site
  • 1
    @Zavior it's stronger with the spaces
    – Zelda
    Commented Jun 25, 2012 at 12:58
  • 2
    Not directly an answer, so I'll leave it as a comment, but "a system that handles authentication properly" might not store passwords at all. If you don't want to run the risk of revealing passwords (even accidently), don't store them; use trusted or federated authentication, like StackExchange does. Commented Jun 25, 2012 at 14:48
  • 5
    What I hate is that some websites think they're special enough to get my special passwords. Damn you, I'm not making another password to adhere to your stupid requirements which I will forget for some site I'll almost never visit again. Commented Jun 25, 2012 at 22:37
  • 1
    @muntoo if you use the same password for multiple sites, owner of any of them can access other sites that you use using the same password Commented Jun 26, 2012 at 11:18
  • 1
    "Somebody has repeatedly tried to log into your account. Please try again in half an hour, and hope that they're not still brute-forcing, which will lock it for another half an hour. Have a nice day!"
    – lanzz
    Commented Dec 28, 2013 at 9:21

8 Answers 8


Because, as LinkedIn and other recent password leakages reveal, still the most common passwords for websites are "password", "god", "123456", etc. So you can brute-force with really short list of most common passwords. Still, you can just ban those passwords, or require long password - as possible combinations grow exponentially with the length, and requiring long password is better than requiring "strong" password to prevent brute-force. But too many people follow what they believe is a best practice without questioning it, so - great question indeed!

  • 3
    thanks. the main problem for recent password breaches is storing without salt or even in plain text
    – Bozho
    Commented Jun 25, 2012 at 11:21
  • 19
    Bozho: Even with really good crypto in place, salt and all, brute-forcing "password" or "123" is not exactly difficult.
    – user281377
    Commented Jun 25, 2012 at 11:34
  • 1
    "require long password - as possible combinations grow exponentially with the length" you mean that it takes exponentially more time to hack "aaa", "aaaa", "aaaaaaaa", "aaaaaaaaaaa"...?
    – curiousguy
    Commented Jun 26, 2012 at 4:00
  • 3
    @EgonGeerardyn "Indeed it takes (almost exponentially) longer to brute-force those." Except when it doesn't. You can try "a", "b", ... "aa", "bb" ..."aaaaaaa" "bbbbbbb" this takes linear time. "The only case where it doesn't matter is when you know the password only contains a and nothing else" you don't need to know anything, you can guess and quickly verify. You don't know anything about the password, but you still try dictionary words before "cbzpftxuf".
    – curiousguy
    Commented Jun 27, 2012 at 2:37
  • 1
    @EgonGeerardyn So you bet that there are approx. as many people with aaaaaaaa as their password (say password for something not so important, f.ex forum) as there are with tWz2jc7J?
    – curiousguy
    Commented Jun 27, 2012 at 17:26

Because no one ever got fired for creating password strength requirements. For the admin, it's basically the low-risk approach, even though these restrictions are very annoying for the user and offer next to no real security.

  • 3
    @static_rtti - Only allowing password of a certain length and complexity actually does offer some real security. This allows the admin to prevent users from using common passwords.
    – Ramhound
    Commented Jun 25, 2012 at 13:54
  • @Ramhound "Only allowing password of a certain length and complexity" what is "password complexity"?
    – curiousguy
    Commented Jun 26, 2012 at 3:58
  • Password complexity means that the password has high entropy. Basicly, means that your password should be improbable (uncommon or not easy to guess). You can improve the password entropy by two means: either quite short passwords with lots of different characters or really long ones with words.
    – Egon
    Commented Jun 26, 2012 at 5:04

Here are a couple of relevant illustrations from xkcd! On what is considered strong is actually weak because people are human and won't put in the effort, and the other is lazyness even if they use a "strong" password, it gets reused everywhere. You can't win!

Password Strength

Password Strength


Password Reuse

Password Reuse


If you allow short passwords without a strength requirement then you are leaving yourself open to someone doing a rainbow style attack on the usernames. For example:

...keep doing this until the cooldown window expires...
...repeat as needed...

A lot of systems aren't even going to flag this pattern as an issue, and I have never seen one that would really catch it if you did it through a botnet and throttled it appropriately.

  • 1
    "rainbow style attack" what is that?
    – curiousguy
    Commented Jun 26, 2012 at 0:40
  • maybe I am making a bad comparison, but what I meant was if you had a list of common usernames (like a rainbow table's list of common passwords) you would just iterate through them trying random lame passwords letting you try very many combinations of username/password very quickly without triggering the password attempt threshold. Not my idea, and maybe there is a better name for it, but it is effective if done correctly.
    – Bill
    Commented Jun 26, 2012 at 3:21
  • 5
    "like a rainbow table's list of common passwords" a rainbow table isn't (and doesn't contain) a "list of common passwords", it's a cleverly compressed set of password hashes. The term "rainbow" designates a specific hash storage method, and is not a synonym for either "dictionary" or "brute force"
    – curiousguy
    Commented Jun 26, 2012 at 4:01
  • right, so if your org always uses firstnames, or always uses initials followed by sequential zero padded ints the clever part it identifying the pattern to cut down the bad guesses. perhaps calling it a smart dictionary is better, but I had always thought the dictionary attacks were inherently not clever. I have seen this done, but I have never seen it named so I really don't know what to call it.
    – Bill
    Commented Jun 26, 2012 at 11:33

There are several different types of attacks that passwords are subjected to, just as there are a number of defenses that can be implemented.

bcrypt and / or a password lock-out are just two of many possible defenses.
Password Strength is a fairly decent article.

To specifically answer your question as to why the combinations are required - It's the only means available to force the selection of a strong password. A strong password really means high entropy (change) between the characters of the password. The greater the entropy then the greater the range of bits available for the encryption (such as with bcrypt). A low entropy (weak) password doesn't use the full space available for encryption. What you thought was 128-bit or 256-bit encryption ends up being a lot less because the full range for keys wasn't used.

Some numbers might help explain things more clearly. We'll use an 8 character password for the example. All lowercase passwords only have 26 different combinations. So that's 26^8 or 2.1x10^11 different combinations.
Adding in uppercase characters doubles our space (now 52 not 26) but buys us many more combinations. 52^8 or 5.3x10^13, which is a gain of roughly 250x.
Start adding in numbers or special characters and you can easily see the effects of forcing more entropy in the key space.

In reality, we still don't have that full key space since something that is able to be remembered generally doesn't have a lot of entropy to it. But the requirements help push more entropy into the password.

  • "high entropy (change)" hug?
    – curiousguy
    Commented Jun 26, 2012 at 1:14
  • store passwords using bcrypt (or at least use salt+hash) - hard-to-impossible to find the original password when an attacker gets the database

If they have compromised your server, you have far worse things to worry about.

An Analogy:

Thief breaks into your house. But all your keys are securely stored. So what? he is in your house!

  • lock subsequent password attempts with a growing cooldown - no brute-force via the site

This only slows the problem down, if the password is weak eg "password". And that is the first attempt, then your back to square one.

Having a strong password is a good idea (tm)

  • 4
    Except the thief now has all your customers keys instead of just yours.
    – whatsisname
    Commented Jun 25, 2012 at 12:22
  • -1: Wrong on both accounts. Fully compromising the production server is not the only way to get a copy of the database, and "strong" passwords don't do anything more than slowing down a brute force attack either.
    – Michael Borgwardt
    Commented Jun 25, 2012 at 12:47
  • 1
    @MichaelBorgwardt I think you have missed the point entirely --> what on earth is the point worrying about hashed keys, WHEN YOUR server is compromised?
    – Darknight
    Commented Jun 25, 2012 at 13:09
  • 3
    @Darknight: What if the attacker only got a backup copy of the DB from a storage server, or access to it through a readonly account? And even if your server is compromised, your customers will appreciate not having their passwords compromised that they probably used for different accounts as well. Security as an all-or-nothing issue is a simplistic and outdated view. Commented Jun 25, 2012 at 13:33
  • 4
    An analogy: a thief breaks into your house. But the key to your car in the garage, the safe containing priceless jewels and the neighbours' houses are securely stored, and the silent alarm system has already called a security firm who has informed the police after checking back with you; the officers will arrive in 5 minutes. A hell of a lot more effective than relying solely on the lock to the front door, isn't it? Commented Jun 25, 2012 at 13:37

A reason that's not mentioned elsewhere is that it may well be that you have a larger interest in your user account security than the users themselves.

For example, if you're running a completely non-critical system such as some online discussion forum, the users may not really care at all if their accounts are compromised - however, if 5% of your users have passwords '123456' and 'password', then you'll have perpetual problems with spammers using compromised accounts; if you're running a school network then again a significant portion of users may not particularly care if their accounts get abused, but the abusers will cause problems for you if trying top-5 common passwords can reliably get access to a dozen accounts every time.

For this attack scenario (try a trivial password for all account names that you can find) you don't need access to the database, and lockouts won't help as long as sufficient 'fresh' IP addresses are available.


The problem with your solutions are:

  • Using hash + seed doesn't protect against brute-force password guessing.

  • Lockout does protect to a degree, but it has the problem that it can be used as a denial of service attack against genuine users, especially if you use an increasing lockout time. And a smart attacker can switch to targeting multiple accounts, using multiple IP addresses and/or waiting a time between each guess.

By contrast, insisting on strong (harder to guess) passwords means that the attacker has to use more guesses (on average) to crack an account.

  • "Lockout does protect to a degree, but it has the problem that it can be used as a denial of service attack against genuine users" On the Web you can have a combined (moderate) delay + CAPTCHA approach. It isn't perfect either, but it doesn't lock-out users. "By contrast, insisting on strong (harder to guess) passwords" actually they do not insist on strong passwords, they insist on stupid rules like "mixed-case" and "at least of one digit" which make password harder to remember at constant entropy, IOW for a constant memory effort these rules make passwords weaker
    – curiousguy
    Commented Jun 26, 2012 at 1:11

You must log in to answer this question.

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