1

I have a somewhat basic understanding of how entropy relates to password strength - generating a password with a truly random selection from some set (whether that's characters, or a set of dictionary words, or whatever else) gives increasing entropy as either the size of the set and/or the number of selections increases.

But in some cases, simply generating a password with a certain entropy doesn't result in a password that's strong 'in the real world'. For example, let's say I want to randomly generate a password that's 8 characters long. I take a truly random selection from the set of all uppercase and lowercase letters, numbers, and special characters, and the result I get is:

password

That's just as likely as any other output from a random selection, and assuming a valid generation it has the same entropy as something like '@gm%Kj$9'. Despite that, it's clearly not suitable for use as a password, as any even remotely competent malicious actor would be into the system almost immediately. Chances are a random person would pass that check on literally their first try.

It's clear that entropy alone can't necessarily be relied on for a strong password. My question, then, is how the random chance of generating common password strings within a longer password impacts the strength of that password against real-world attacks, using whatever techniques password crackers might commonly employ - or if it has any impact at all.

Let's say I realise that an 8 character password isn't that strong, and decide instead to generate a 16 character password using the same truly random generator with the same set. I have four systems I need to protect, so I generate four passwords (that will all be used, I'm not going to select from them again afterwards manually as that would influence the entropy). The four passwords I get are:

al#k2j$9gjKDm5%l
*g3RpasswordnG&4
password%G@fDnBv
Nf!hFm$xpassword

All four of these have the same entropy and are just as likely as the others to be returned from a truly random generator - however, three of them include the sequence 'password', which on it's own would be incredibly vulnerable. One has that sequence in the middle, one has it at the start, and one has it at the end.

Are any of these passwords more vulnerable to real-world attacks than the others, despite having the same entropy?

Note: I've looked at this similar question, however I think this is a slightly different case as we're not 'adding' a common password to the end of our randomly generated one.

1

If you're picking uppercase and lowercase letters uniformly at random, that's log2(52) = 5.7 bits per character, so 5.7 × 8 = 45.6 bits for an 8-character password. And the answer to the worry that you have a 2-45.6 chance of randomly choosing password (one in thirty-something trillion) is that you probably shouldn't worry too much that you have about a one in thirty-something trillion chance of picking password.

More generally, yes, there is a probability that random selection will, by chance, pick the very first password an attacker is likely to try, or the second, or the third, and so on. As long as we make that probability acceptably low this isn't something to worry about.

There's seven billion people in this planet, which is about 233. If each of them has a thousand passwords each—about 210—that's 233 × 210 = 243 passwords, and if they all do 8-char passwords from a 52 letter alphabet (45.6 bits) that'd mean there's something between a 1/4 and 1/8 chance that somebody will pick password at least once. That might be a reasonable argument against recommending 8 upper/lower letter passwords to humanity at large, but only because it's modestly likely one lone person in the whole wide world might be bit by one of a thousand random passwords they choose. (Well, actually it gets a bit worse once you consider longer password cracking dictionaries.)

8 upper/lower letters is cutting it much too close, though, because of computing power.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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