# Is there more to consider than just keyspace when determining a password's strength?

CO/l37)[Ou
It contains characters taken from a pool that contains [a-zA-Z0-9] and 32 'special' characters. That makes 94 characters in total.

And this one:
XFnSzoN3Ype
This one contains characters taken from a pool of [a-zA-Z0-9], so just 62 characters.

Note that the second password is one character longer than the first.

If you look only at the number of possible passwords that you can construct using the given pools and lengths, you will find that both are about equally strong.
1) 94^10 = 5.4 * 10^19
2) 62^11 = 5.2 * 10^19

Disregarding this slight difference for a moment, would there still be a case to make for preferring the first password over the second? Is there more to consider than just keyspace when determining the strength of a password?

• Maybe you should have a look at this Commented Dec 16, 2015 at 9:25
• @Sebastian Yes I'm aware of that article, but it's about using a small number of dictionary words taken from a large pool. My example is about a (sufficiently) large number of characters taken from a small pool. So I don't think that that article really answers my question. Commented Dec 16, 2015 at 9:30
• Besides, if we have an answer to my question it will be useful for all systems, not just the ones that allow spaces and have no max lenght limit. Commented Dec 16, 2015 at 9:35
• But it also points out that a long sequence of a small pool (lower case letters) is probably better than a short sequence of a greater pool (upper-, lower case letters, numbers, symbols). So regarding your second question: "Is there more to consider than just keyspace when determining the strength of a password?" Well, yes: its length Commented Dec 16, 2015 at 10:22
• Just for a note of reference, 62^11 / 94^10 = 0.9661 (you can accurately say the second password is 96.6% as strong as the first). Commented Dec 16, 2015 at 10:31

Determining whether a particular password is "strong" is an imprecise exercise. A slightly better question is whether it's strong against a particular type of attack. This provides a framework from which you can start to evaluate how many guesses or how much time is consumed trying to match guesses to your particular password. But this also forces you to make some assumptions about what attacks and approaches will be tried, and these might not match up with what would happen in the real world.

So, looking at your two presumably randomly generated passwords we can say that the obvious attack is to try all possible random combinations with their respective character pools. We know if we try all combinations we will find a match at some point during that search. We could also evaluate how exactly the guessing software iterates through the random strings and estimate where within the overall brute force process those passwords are likely to be cracked.

Just to make up numbers, let's say your first password would be matched 4% of the way through a brute force of its respective keyspace, and the second password would be matched 39% of the way through its respective keyspace. You could take those results and accurately say that the second password is stronger against this specific type of brute force attack.

But this couldn't tell you that either pool of characters was better or worse at producing secure passwords. It is limited to comparing those two specific passwords. On average both pools would produce random passwords of approximately the same strength since they have a similar keyspace.

We could also look at the computational feasibility of an attacker exhausting all possibilities in a brute force of either keyspace and say that today it isn't likely. At one trillion password guesses per second it would take over 600 days to exhaustively search either keyspace. If neither is likely to be cracked then you could argue they are equally strong, or at least both strong enough, from a practical standpoint.

Another attack might be guessing dictionary words. It's seems safe to say that neither of these passwords should appear in a dictionary. In this case they're also equally strong, since neither have a chance of being guessed.

However, if we step back to evaluate the likelihood of their respective keyspaces matching dictionary words we might see a different result. Your first password's keyspace is made up of around 0.27% strings that are all lowercase, all uppercase, or a mixture of alphabetic cases. In comparison, your second password's keyspace is around 14.45% of those same strings that could be dictionary words.

Now that certainly doesn't mean all these alphabetic strings are words (or combinations of words). A very, very small percent of those strings would match any given word list. But you could make the argument that a higher possibility of a randomly generated password from the second pool containing only letters means that this pool has a higher chance of generating passwords that match words. I'd urge you to actually measure this effect with word lists before proclaiming this to be true, but some people might see this and say that the first pool generates stronger passwords.

So my conclusion would be that there are different ways of measuring the strength of these passwords (and I only discussed a few). Depending on which approach or approaches you took you might get different results.

Yes, there are reasons to use a more randomized password.

Consider that the attacker mostly doesn't bruteforce at random. A password consisting of [a-zA-Z] is much more likely to be on an computer-assembled password list, since most people still don't use special characters in their passwords.

And if they use !"§\$%&/()=?\}][{¬½₹³²¹@ most users will still use much more [a-zA-Z] in their passwords.

a uniformly randomly distributed password would be the most secure one, though humans don't do them usually. There are many passwordlists out there used to create more variations of passwords, i think you should probably add another !"§\$%&/()=?\}][{¬½₹³²¹@ char to your random password ;)

• Unless it's long enough. I would never promote special character-less passwords for short ones. Wouldn't you agree that the "use special characters" requirement is of a lesser importance than say "use long passwords" or "don't use dictionary words"? If your password is short it is BAD, regardless of any other requirement fulfilment. If your password is (too similar to) a dictionary word it is BAD. I don't think you can say the same for special character-less passwords. They can still be good if long and random enough. Commented Dec 16, 2015 at 12:36
• Since special characters are a sublot of all available characters, this is right. Commented Dec 16, 2015 at 12:49
• Without disagreeing with your answer, I don't think it addresses the question Is there more to consider than just keyspace when determining a password's strength? It proposes two password strategies with ~equal key spaces: one shorter with more possible characters, the other longer with fewer possible chars. Commented Dec 16, 2015 at 15:08

Keyspace is especially relevant for brute force attacks.

However password attacks are most often not brute force: this is the last resort. So with that in mind the question is: what is the likelyhood that one password is in a rainbow table vs the other.

The typical 10-12 special characters are potentially in a rainbow table, but 32 is much less likely.

So in my humble opinion, based on this real-life assumption, the shorter but more character is more 'secure' in the sense it will more likely force the cracker to use brute force, which is very time consuming.

Then I would add, it all depends on your encryption: obviously if you store the password in clear, neither password is any good. I'm assuming reliable and equal encryption for both passwords.