4

Please consider the following passwords:
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?

mgr326639
  • 183
  • 6
  • Maybe you should have a look at [this](http://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase) – Sebastian Dec 16 '15 at 09: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. – mgr326639 Dec 16 '15 at 09: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. – mgr326639 Dec 16 '15 at 09:35
  • 1
    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 – Sebastian Dec 16 '15 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). – Jonathan Gray Dec 16 '15 at 10:31
  • @Sebastian The keyspace is composed of the pool-size en the length. So I would not agree that _yes: its length_ is an answer to my question _Is there more to consider..._ – mgr326639 Dec 16 '15 at 10:42
  • Ok, sorry then I misunderstood you. Another point from the question I linked is usability (= the human factor). I think common users wouldn't (or at least many would refuse to try to) remember any of the two passwords you provided. – Sebastian Dec 16 '15 at 10:52
  • I think you're right about that. But there are more advantages to avoiding the use of spacial characters. They are cumbersome to type on a mobile device. The symbol depicted on the key is not always the key that you type. Furthermore, many people use special characters for leetspeak only which hardly improves on security. – mgr326639 Dec 16 '15 at 10:59
  • @JonathanGray - make your comment an answer so I can upvote it. – Neil Smithline Dec 16 '15 at 15:10
  • @Neil That is not the answer. That's why I said _Disregarding this slight difference for a moment_. I could have easily chosen an example like this one: Compare a 11 char password from a pool of 90 versus a 12 char password from a pool of 62. The difference is a factor 1.03, but this time in favor of the `[a-zA-Z0-9]` password. I this Johathan understood this because he says _Just for a note of reference_. It is just not possible to find an example where the match is 100%. – mgr326639 Dec 16 '15 at 15:19
  • His comment is based on the fact that only keyspace is relevant. – Neil Smithline Dec 16 '15 at 15:24
  • If I had a password consisting of ones and zeros, say 10100100, and another password, say aHsLiSRs [a-Z], the second password would be 208,827,064,576 times more secure than the first. Yet I don't think it would be that many times more difficult to remember. So if you're asking whether a keyspace with more combinations is ultimately better, I would have to say yes. – Jonathan Gray Dec 16 '15 at 15:36

3 Answers3

1

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.

PwdRsch
  • 8,341
  • 1
  • 28
  • 35
0

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 ;)

Gewure
  • 324
  • 1
  • 11
  • 1
    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. – mgr326639 Dec 16 '15 at 12:36
  • Since special characters are a sublot of all available characters, this is right. – Gewure Dec 16 '15 at 12:49
  • 1
    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. – Neil Smithline Dec 16 '15 at 15:08
0

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.

MrE
  • 101
  • 1