Password Security Length vs. Complexity [duplicate]XKCD #936: Short complex password, or long dictionary passphrase?Is Diceware more secure than a long passphrase?How is the strength of a key/Password determinedpassword complexity policy for non “English” passwordsPrevent password reusing across different sitesGiven two passwords, what is the fastest way to compare the strength of them with john?

SSD or HDD for server

Doggerel for tonight

Is there a practical way of making democratic-like system skewed towards competence?

Does this shuffle have non-zero probability for all permutations?

How to respond when insulted by a grad student in a different department?

How does paying extra on my mortgage affect my amortization schedule?

String Operation to Split on Punctuation

Delete line if next line is the same

Does Australia produce unique 'specialty steel'?

Can a character dodge an attack that beats their Armor Class?

Fill a bowl with alphabet soup

Why is it so hard to land on the Moon?

What is the ring of invariants under the action of an arbitrary subgroup of the symmetric group?

Sum in bash outside while read line

5v home network

Variable fixing based on a good feasible solution

Is it possible to do a low carb diet for a month in Sicily?

Future of iTunes and audio files in its library

Can you decide not to sneak into a room after seeing your roll?

Short story about aliens who tried using the common cold as a weapon

What is a light-year, really?

Fantasy novel/series with young man who discovers he can use magic that is outlawed

How can demon technology be prevented from surpassing humans?

Smallest number such that the sum of digits and the product of digits is 2000



Password Security Length vs. Complexity [duplicate]


XKCD #936: Short complex password, or long dictionary passphrase?Is Diceware more secure than a long passphrase?How is the strength of a key/Password determinedpassword complexity policy for non “English” passwordsPrevent password reusing across different sitesGiven two passwords, what is the fastest way to compare the strength of them with john?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









0


















This question already has an answer here:



  • XKCD #936: Short complex password, or long dictionary passphrase?

    23 answers



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?










share|improve this question


















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

















0


















This question already has an answer here:



  • XKCD #936: Short complex password, or long dictionary passphrase?

    23 answers



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?










share|improve this question


















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













0












0








0









This question already has an answer here:



  • XKCD #936: Short complex password, or long dictionary passphrase?

    23 answers



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?










share|improve this question

















This question already has an answer here:



  • XKCD #936: Short complex password, or long dictionary passphrase?

    23 answers



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?





This question already has an answer here:



  • XKCD #936: Short complex password, or long dictionary passphrase?

    23 answers







passwords






share|improve this question















share|improve this question













share|improve this question




share|improve this question



share|improve this question








edited Apr 24 at 14:27







JaReg

















asked Apr 24 at 13:45









JaRegJaReg

167 bronze badges




167 bronze badges





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.











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.









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












  • 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







1




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





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





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





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





There, I corrected it (hopefully)

– JaReg
Apr 24 at 14:13




1




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





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










2 Answers
2






active

oldest

votes


















7


















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.






share|improve this answer























  • 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



















5



















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".






share|improve this answer

































    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    7


















    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.






    share|improve this answer























    • 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
















    7


















    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.






    share|improve this answer























    • 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














    7














    7










    7









    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.






    share|improve this answer
















    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.







    share|improve this answer















    share|improve this answer




    share|improve this answer



    share|improve this answer








    edited Apr 24 at 21:20

























    answered Apr 24 at 14:22









    LucLuc

    26.1k6 gold badges51 silver badges110 bronze badges




    26.1k6 gold badges51 silver badges110 bronze badges










    • 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













    • 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








    2




    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





    "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






    @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





    @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






    @MooingDuck Good point! I'll edit the post. (Also, I like your avatar.)

    – Luc
    Apr 24 at 21:14














    5



















    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".






    share|improve this answer






























      5



















      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".






      share|improve this answer




























        5














        5










        5










        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".






        share|improve this answer















        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".







        share|improve this answer













        share|improve this answer




        share|improve this answer



        share|improve this answer










        answered Apr 24 at 14:49









        reedreed

        5,1173 gold badges15 silver badges36 bronze badges




        5,1173 gold badges15 silver badges36 bronze badges
















            Popular posts from this blog

            Distance measures on a map of a game The 2019 Stack Overflow Developer Survey Results Are Inmin distance in a graphShortest distance path on contour plotHow to plot a tilted map?Finding points outside of a diskDelaunay link distanceAnnulus from GeoDisks: drawing a ring on a mapNegative Correlation DistanceFind distance along a path (GPS coordinates)Finding position at given distance in a GeoPathMathematics behind distance estimation using camera

            How to get a smooth, uniform ParametricPlot of a 2D Region?How to plot a complicated Region?How to exclude a region from ParametricPlotHow discretize a region placing vertices on a specific non-uniform gridHow to transform a Plot or a ParametricPlot into a RegionHow can I get a smooth plot of a bounded region?Smooth ParametricPlot3D with RegionFunction?Smooth border of a region ParametricPlotSmooth region boundarySmooth region plot from list of pointsGet minimum y of a certain x in a region

            Genealogie vun de Merowenger Vum Merowech bis zum Chilperich I. | Navigatiounsmenü