This question already has an answer here:

I am working on a password policy and had some questions about password/passphrase strength:

For password strength, is a shorter more complex password stronger or weaker than a much longer, less complex password.

For instance:

Password 1 - :*{5fCC" - 8 characters, upper, lower, special, numbers (95 total). - 6.6 * 1015 permutations

Password 2 - OneDayIWentToWalkOutsideRaining - 31 characters, upper, lower (52 total) - 1.5 * 1053 permutations

From the above, password 2 has more possible permutations but contains dictionary words. Obviously more permutations makes raw brute forceing more difficult, but does a longer password protect a hashed password better than a shorter password, or is there other considerations that I need to understand?

marked as duplicate by PwdRsch, Community Apr 24 at 20:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Your math is massively off (69 orders of magnitude) in the first example password - assuming an allowed special character set of 18 characters (80 total allowed characters), you'll have 1.68*10^15 permutations. – Larkeith Apr 24 at 13:56
  • For the first password I assumed 8 characters. 26 upper, 26 lower, 10 numbers, 32 special characters. so 8 characters with 94 options. – JaReg Apr 24 at 14:00
  • Oh - it looks like you got the numbers reversed then (8^94 rather than 94^8) - I just did the same when typing it in on my end. In that case it should be 6.10*10^15 permutations for the 8-character password. – Larkeith Apr 24 at 14:02
  • There, I corrected it (hopefully) – JaReg Apr 24 at 14:13
  • 1
    I think you missed the exponent field on Password 1 (should be 6.6e+15 for 95^8) but everything else looks correct. – Larkeith Apr 24 at 14:18

There are indeed two properties to a password:

  • Complexity (number of possible characters in each position)
  • Length (number of positions)

The 'randomness' of a password is simple to calculate: complexity ^ length, where ^ is exponentiation. As you might know, changing the exponent (the length) makes the number much larger than changing the base (complexity).

For example, a random password using 6 characters, consisting of a-z, A-Z, and 0-9, has a complexity of 62 (26 + 26 + 10) and a length of 6, making 62^6= ~56 billion possible passwords. It is well-known that 6 characters is very insecure for most purposes, even when randomly generated.

For randomness, more is better, up until about 128 bits of entropy. A little more than that helps buffer against cryptographic weakenings of algorithms, but really, you don't want to memorize 128 bits of entropy anyway. Let's say we want to go for 80 bits of entropy, which is a good compromise for almost anything. (Unless you use a password manager, which you should. In that case, just generate 128-bits random passwords and you're good.)

To convert "number of possible values" to "bits of entropy", we need to use this formula: log(n)/log(2), where n is the number of possible values. So if you have 26 possible values (1 letter), that would be log(26)/log(2)= ~4.7 bits of entropy. That makes sense because you need 5 bits to store a letter: the number 26 is 11010 in binary.

A password with a complexity of 62 needs 14 characters to reach our target of 80 bits:
log(62^14)/log(2)= ~83.4 bits of entropy.
Example: c21FApmUsptwfd

If you add all possible ASCII symbols, you get a complexity of about 95. These passwords are annoying to type, even harder to remember than without symbols, and you still need 13 characters:
log(95^13)/log(2)= ~85.4 bits.
Example: ~2YPCi.%$6u,.

If you add words, your password becomes much longer, but is slightly easier to remember. The calculation is similar: number of possible elements to the power of the number of elements. If you have a dictionary of 7000 words and pick 6 random words, you have 7000^6 possible combinations. That is:
log(7000^6)/log(2)= ~76.6 bits of entropy.
Example: cardigans Malthusian's acorns glows unconfirmed uncluttered

You can combine them: if you have four random words and three random digits in between, you have 10^3 * 7000^4 possible values. Again, the entropy calculation:
log(10^3 * 7000^4)/log(2)= 61.0 bits of entropy.
Example: foreshadow3sectionals2palm6deliberating

It is simple to use the math and make a table of possible combinations/lengths/complexities and compare their strengths. You can mix properties until you find a combination that you like, and check that it gives you enough strength. But to answer your question generally: length beats complexity.

Finally, it should be noted that the example you used is not as strong as N random words: the 6-word sentence "OneDayIWentToWalk" makes sense. The 6-word sentence "OneIDayWentToWalk" does not make sense. Someone guessing which passphrase you used can eliminate all the possible nonsensical sentences and try only the grammatical ones. That reduces the number of guesses required by a lot. This question at the Linguistics StackExchange explores the randomness of grammatical phrases. (Credits to Tezra for sharing that link.)

Note: this answer uses parts from another answer I posted in a different question earlier today.

  • 2
    "two properties to a password" You're missing at least 1 more: likelihood of being remembered without being written down and stored on a post-it taped to the monitor. – Mast Apr 24 at 18:53
  • @Mast First off, that's a property of the human, not of the password. But more importantly, you can pick how secure you want to be and choose your password's properties accordingly. I'm not telling you to use 80 bits, I'm saying that's enough for pretty much everything. For less important stuff, use less. It's as the post says: "You can mix properties until you find a combination that you like, and check that it gives you enough strength." It's you who gets to define what is "enough" :) – Luc Apr 24 at 20:04
  • @Luc: The only thing missing from this answer is a mention that the calculation for words is only correct if the words are randomly selected, but "OneDayIWentToWalkOutsideRaining" appears to not be. – Mooing Duck Apr 24 at 20:21
  • @MooingDuck Good point! I'll edit the post. (Also, I like your avatar.) – Luc Apr 24 at 21:14

Password 1 - :*{5fCC" - 8 characters, upper, lower, special, numbers. - 7.77e+84 permutations

The rule to generate password #1 can generate 94^8 = 6.10 x 10^15 permutations, so it has about 52 bits of entropy.

Password 2 - One8Day7I6Went5To4Walk3Outside2Raining1 - 39 characters, upper, lower, numbers - 4.42e+98 permutations

It's more difficult to estimate the entropy of password #2 because it's not random. The numbers and the uppercase characters appear to be totally predictable, so they do not add anything.The words look like very basic words that could be chosen among the most common 3000 words in the English language, but the choice doesn't look random, because it almost looks like a valid English sentence. According to some studies (look up "entropy of English") the English language should have about 1 bit of entropy per character. Your password #2 probably has about 40 bits of entropy then, although it's difficult to give a precise answer. In general, we could suppose that the rule that you use to generate password #2 will generate less than 50 bits of entropy, making password #2 actually weaker than password #1.

A strong password should:

  • Be generated using enough entropy.
  • Not contain patterns. If you roll 6 dice to generate the numerical password 123456, then you need to discard it and repeat the process, because that password would be an obvious pattern definitely included in the attacker's dictionary.
  • Be different from any other passwords you have already used.

Those are the things that really matter. You should not care about "length" or "perceived complexity".

Not the answer you're looking for? Browse other questions tagged or ask your own question.