40

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
curiousguy
  • 5,038
  • 3
  • 25
  • 27
Bozho
  • 1,173
  • 1
  • 10
  • 12
  • indeed. But it's 20 years - it's hard to change immediately –  Jun 25 '12 at 11:14
  • possible duplicate of [What best practices should be employed in a PHP login script?](http://programmers.stackexchange.com/questions/73024/what-best-practices-should-be-employed-in-a-php-login-script) – Arseni Mourzenko Jun 25 '12 at 11:48
  • 1
    @Zavior it's stronger with the spaces – Ben Brocka Jun 25 '12 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. – Mark Beadles Jun 25 '12 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. – Mateen Ulhaq Jun 25 '12 at 22:37
  • "_growing cooldown_" up to? – curiousguy Jun 26 '12 at 01:20
  • up to half an hour, say – Bozho Jun 26 '12 at 05:48
  • 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 – Andrei Botalov Jun 26 '12 at 11:18
  • Password complexity forces users to use the same password just so they can remember it. – FlavorScape Dec 26 '13 at 00:52
  • 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 Dec 28 '13 at 09:21
  • A related question that doesn't answer yours, but might give you some additional insight: [Are password complexity rules counterproductive?](http://security.stackexchange.com/q/32222/12). – Xander Jul 16 '14 at 16:44

8 Answers8

28

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!

Maxim Krizhanovsky
  • 381
  • 2
  • 5
  • 3
    thanks. the main problem for recent password breaches is storing without salt or even in plain text –  Jun 25 '12 at 11:21
  • 19
    Bozho: Even with really good crypto in place, salt and all, brute-forcing "password" or "123" is not exactly difficult. –  Jun 25 '12 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 Jun 26 '12 at 04:00
  • @curiousguy: Indeed it takes (almost exponentially) longer to brute-force those. Even with something in-between a dictionary and brute force attack when you know there is a minimal length, This is because there are many ways to extend every short password in your dictionary to a longer one. You can repeat characters, add ones at the end/front, etc. The only case where it doesn't matter is when you know the password only contains `a` and nothing else, but that doesn't happen that often. – Egon Jun 26 '12 at 04:56
  • 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 Jun 27 '12 at 02:37
  • @curiousguy: That's exactly the same as saying that `tWz2jc7J4eJxdukeW!c$8&a8GVE7$ex9cUv^yc!n` can be brute-forced in constant/linear time (start with that and then try the rest). Dictionary works well because there is strong evidence that many people use dictionary words. You can reduce the exponential time only by making assumptions, which will work in some cases but as there are many cases, e.g. sequences "aaaaaa", "abcdef", "acegik", "123456", "112358", ... There are too many sequences to try, so your best guess remains brute force. – Egon Jun 27 '12 at 16: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 Jun 27 '12 at 17:26
  • @curiousguy: My initial bet would be indeed that. But as it is in some lists of most frequently used passwords, I'd have to say I'm wrong. So indeed you could argue for adding such string to your dictionary. On the other hand, something like "bb" is not in the [list](http://dazzlepod.com/disclosure/) I consulted, so that already limits usefulness. On the other hand, you could argue that complexity restrictions would limit the number of times `aaaaa` would occur (i.e. a more uniform distribution where `aaa` is really as likely as some random string), so where brute force is the best bet. – Egon Jun 27 '12 at 17:52
16

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.

static_rtti
  • 279
  • 1
  • 5
  • 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 Jun 25 '12 at 13:54
  • @Ramhound "_Only allowing password of a certain length and complexity_" what is "password complexity"? – curiousguy Jun 26 '12 at 03:58
  • Password complexity means that the password has high [entropy](http://en.wikipedia.org/wiki/Entropy_%28information_theory%29). 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 Jun 26 '12 at 05:04
9

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

And

Password Reuse

Password Reuse

Community
  • 1
8

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:

admin,password
fred,password
bob,password
...keep doing this until the cooldown window expires...
admin,god
fred,god
bob,god
...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.

Bill
  • 386
  • 2
  • 7
  • 1
    "_rainbow style attack_" what is that? – curiousguy Jun 26 '12 at 00: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 Jun 26 '12 at 03: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 Jun 26 '12 at 04: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 Jun 26 '12 at 11:33
3

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.

2
  • 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. –  Jun 25 '12 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. –  Jun 25 '12 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? –  Jun 25 '12 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. – Michael Borgwardt Jun 25 '12 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? – Michael Borgwardt Jun 25 '12 at 13:37
  • @MichaelBorgwardt "_What if the attacker only got a backup copy of the DB from a storage server,_" that should never happen. Your backups should be encrypted. "_or access to it through a readonly account?_" what is a readonly account? – curiousguy Jun 26 '12 at 01:16
  • @curiousguy: The real world doesn't much care what should and should not happen. There is no such thing as perfect security, which is what pretty much everyone in the field has come to accept that you need layers of security measures: http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29 . By readonly account I meant an account (DB or OS user) that has limited access privileges. It is quite common for an attacker to first gain access to such an account. – Michael Borgwardt Jun 26 '12 at 07:30
  • @MichaelBorgwardt These thing should never happen, and will never happen in any reasonably secure setup. "_And what do you think strong passwords do?_" They are strong. You cannot guess them. That's what "strong" means. – curiousguy Jun 26 '12 at 20:23
  • Strong passwords take a lot longer to guess. Cooldown periods make guessing weak passwords a lot longer too. – Michael Borgwardt Jun 26 '12 at 20:48
  • @MichaelBorgwardt "_Any password can be guessed,_" "can be" as in "can be with a theoretical computer but cannot be in the real world before the sun takes over the earth"? – curiousguy Jun 27 '12 at 02:40
  • Guys - I have deleted and edited where relevant. If you want to have a conversation, take it to Chat, but keep it polite. – Rory Alsop Jun 27 '12 at 10:38
1

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.

Peteris
  • 8,389
  • 1
  • 27
  • 35
0

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.

Stephen C
  • 117
  • 3
  • "_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 Jun 26 '12 at 01:11