Is the NHS wrong about passwords?

Question

An NHS doctor I know recently had to do their online mandatory training questionnaire, which asks a bunch of questions about clinical practice, safety and security. This same questionnaire will have been sent to all the doctors in this NHS trust.

The questionnaire included the following question:

Which of the following would make the most secure password? Select one:

a. 6 letters including lower and upper case.
b. 10 letters a mixture of upper and lower case.
c. 7 characters that include a mixture of numbers, letters and special characters.
d. 10 letters all upper case.
e. 5 letters all in lower case.

They answered "b", and they lost a mark, as the "correct answer" was apparently "c".

It is my understanding that as a rule, extending password length adds more entropy than expanding the alphabet. I suppose the NHS might argue that people normally form long passwords out of very predictable words, making them easy to guess. But if you force people to introduce "special characters" they also tend to use them in very predictable ways that password guessing algorithms have no trouble with.

Although full disclosure, I'm not a password expert - I mostly got this impression from Randall Munroe (click for discussion):

Am I wrong?

Answer 1

By any measure, they're wrong:

Seven random printable ASCII: 95⁷ = 69 833 729 609 375 possible passwords.

Ten random alphabetics: 52¹⁰ = 144 555 105 949 057 024 possible passwords, or over 2000 times as many.

Length counts. If you're generating your passwords randomly, it counts for far more than any other method of making them hard to guess.

Answer 2

The theoretical perspective

Let's do the math here. There are 26 letters, 10 digits and let's say about 10 special characters. To begin with, we assume that the password is completely random (and that a character in one group is not more likely to be used than a character in another group).

The number of possible passwords can then be written as C = s^n where s is the size of the alphabet, and n the number of characters. The entropy of the password is defined as:

log2(C) = log2(s^n) = log2(s)*n

Lets plug the numbers from the question into this:

     s    n   Entropy (bits)
A   52    6   34.2
B   52   10   57.0
C   72    7   43.2
D   26   10   47.0
E   26    5   23.5

So in this scenario, C is only the third-best option, after B and D.

The practical perspective

But this is all under the assumption of randomness. That is not a reasonable assumption for how people generate passwords. Humans just don't do it that way. So we would have to pick some other assumptions for how the passwords are generated, and what order the attacker tries them in her dictionary.

A not unreasonable guess would be that many dictionaries begin with words, and only later move on to making substitutions and adding special characters. In that case, a single special character in a short password would be better than a really long and common word. But on the other hand if the attacker knows that a special character is always used, she will try those passwords first. And on the third hand maybe the dictionary is centered around completely different principles (like occurrences in leaked databases).

I could go on speculating about this forever.

Why it is the question, not the answers, that is wrong

The problem is that there are many principles for how the password is generated to choose from, and I could arbitrarily pick one to make almost any answer the correct one. So the whole question is pointless, and only serves to obscure an important point that no password policy in the world can enforce: It is not what characters a password contains that makes it strong - it is how it is generated.

For instance, Password1! contains upper case, lower case, a number, and a special character. But it is not very random. ewdvjjbok on the other hand only contain lower case but is much better since it is randomly generated.

What they should have done

If you just stop relying on the very fallible and limited human memory the character set and the length stops being limiting factors that you have to weight against each other. You can have both in abundance.

One way to do this is to use a password manager. As Dan Lowe pointed out in comments, that might not be a workable option on a hospital. A second alternative is to use some kind of two-factor authentication (e.g. a hardware token or keycard) that makes the security of the first factor (the password) less important.

This is the responsibility of the system managers, and not the end users, to implement. They must provide the tools that allow the end users to perform their work in a practical and safe way. No amount of user education can change that.

Answer 3

I realize there are already a number of good answers, but I want to clarify one point.

The question is unanswerable as it does not specify a character set, nor the password selection method.

First of to address the second point, we shall pretend the passwords are generated truly randomly within the permitted domain, otherwise we cannot even start reasoning on the matter.

For our other point, to give extreme examples, let us say b implies letters only in the English alphabet, so lets say 52 possible symbols. This gives about 5.7 bits of entropy per character and thus about 57 bits of entropy overall.

On the other hand let us say (perhaps somewhat unreasonably) that answer c implies any completely random Unicode code point which is considered to be a character (as opposed to a BOM etc). There are currently roughly 109,000 of these as of Unicode 6. This means about 16.7 bits of entropy per character and a total of 117 bits of entropy.

On the other hand if the answer c was limited to only ASCII or perhaps ISO 8859-15 or some subset of these, the opposite conclusion could easily be drawn.

This is of course completely unreasonable but highlights the brokenness of the question and how one can reasonably justify either answer. To be a sensible test question it would have to be worded much more rigorously which would make it much harder for users with limited technical or mathematical knowledge to work out.

In the end I would suggest that this test is probably fairly pointless as an organisation would ideally not require users to memorize password requirements but would instead enforce them technologically (the only requirement I can think that learning by heart is useful is not reusing the same password in multiple places).

Answer 4

Is the NHS wrong about which passwords are most secure in the ideal case? Yes, absolutely -- and the other answers have covered that ground pretty thoroughly.

Is the NHS wrong about which passwords are most secure in an NHS environment? Maybe not.

How could a long password be worse tha--?

There are legacy systems that artificially limit the length of a password -- for instance, the old Windows LANMAN/NTLMv1 password hash limits the length to 14 symbols, and the old DES-based UNIX password hash limits it to 8. Worse, the password entry on such a system will often let you enter a password as long as you like, and ignore everything after the first n symbols.

In fact, it seems likely that NTLMv1 is the particular legacy scheme they're running. As @MarchHo points out, NTLMv1 splits your password into two halves of up to 7 characters each, and each half can be cracked separately. So if you're using NTLM with a 10-character alphanumeric password, what you really have is a 7-character alphanumeric password and a 3-character alphanumeric password. The former is clearly worse than 7 characters from the full symbol set, and the latter can be broken in milliseconds on a 10-year-old PC.

Why would something so old still be in common use?

Basically, because it works and it would be expensive to upgrade.

Now, this is me speculating, but: I propose that healthcare environments in particular are likely to be running legacy systems, because of the sensitive nature of healthcare. New systems are likely to need very thorough scrutiny before being accepted as a solution, which means healthcare systems upgrades tend to happen slowly and at great expense.

So if you know there are systems in common use that behave this way, and you can't fix them, then the best you can do is to tell your users to choose a length-n password using the largest possible symbol pool.

In general: are you sure your passwords aren't truncated?

Unfortunately, this has implications for the general case too, especially for us who like our passwords long. How sure are we we can't log into our account on https://example.com with just the first word or two of our passphrase? As bad as using the well-known "correcthorsebatterystaple" is, accidentally using "correct" would be even worse. To be secure in your passwords it's not enough to make sure you generate enough entropy. You also have to be sure that the system on the other end isn't throwing most of it away.

Answer 5

There are some problems with that question. One of them is that it doesn't state how the passwords are chosen but I think the most logical approach is to assume the passwords are chosen randomly but satisfying the respective conditions so I'll use that convention for my answer. Note that Randall's comic clearly doesn't share this assumption but the question didn't specify which way a password is chosen so I reckon we can go for the best which is possible and that's choosing a password randomly. Furthermore, the test probably isn't based on Randall's comic.

The key pace of option b is quite easy to calculate if we assume the English alphabet is used. Yeah, more assumptions, I know. But since the test appears to be in English and not very tricky, I think we can make that assumption.

There are 26 lower-case letters in the English alphabet and just as much upper-case letters, making 52 in total. So there are 52^10 ≈ 1.45*10^17 elements in the key space of option b.

Option c is way less specific than option b. However, since we assumed that the English alphabet is used – which is in favor of option c – we may also assume that only ascii is used for the special characters – which is in favor of option b. Really, if we assumed more special characters than ascii has, we got to assume more letters than are in ascii since ä arguably is a letter in German. That makes the key space of option b even bigger compared to the one of option c.*

The best we can do for option c if we restrict ourselves to the ascii alphabet is to use every printable character (excluding the blank) in our alphabet (note: different, more general use of the word "alphabet"). That's 94 characters, giving option c a key space of 94^7 ≈ 6.48*10^13 elements.

Since one of our assumptions to tackle the question is that the password is chosen randomly witch the respective restrictions and that rule is equal to choosing a password randomly from the respective key space, a password chosen using option b is arguably harder to guess since there are several orders of magnitude more options to try when cracking the password.

In fact, if we assume the costs of cracking a password via brute force to be approximately linear to the size of the key space, cracking a password chosen via option b is 52^10/(94^7) ≈ 2'229 times as hard as cracking one chosen via option c, clearly showing that the allegedly correct answer to this question is wrong.

---

 * This is quite easy to prove mathematically but this StackExchange lacks LaTeX support and you probably will understand it better through a textual description anyways.

The only advantage option c as over option b is its bigger alphabet (again, more general use of the word "alphabet"). Option b, however, makes more than up for this by having choosing a longer password. If we add more and more characters (like ü, à, Ø, Æ, etc.) to it, we're making the alphabets more equal in size, causing the advantage of c over b to diminish, whereas the advantage of b over c is unaffected.

Answer 6

I love entropy questions:

The Short Answer:

Yes, You are "technically" correct about having more entropy (best kind of correct).

The Long Answer

Entropy is factored largely by two things. Number of symbols a password can use, and length. In the NHS's scenario, it would be logical that "special characters" are available symbols to use in the 10 Character answer and therefore, the longer a password is, the higher the entropy, and theoretically more secure.

HOWEVER, we have have to deal with people and we are lazy. The question is trying to get people to include special characters in their password because it forces entropy to happen.

Without it, Randall's comic is mathematically correct, while being cheeky, but any SysAdmin that thinks correcthorsebatterystapler is a good password because it long needs to be slapped in the face, cause that's been in my rainbow tables for a while.

To be fair, I think taking four dictionary words an stringing them together is a good concept (which is what we call a passphrase), however people as I said are lazy and will likely fall for common patterns.

Answer 7

Both the quoted test and your counterarguments are wrong, fundamentally because entropy is a measure of randomness of a password—not length, not alphabet size. The XCKD comic scheme that you cite is secure to the claimed 44 bit security level if and only if the 44 little gray boxes below "correct horse battery staple" represent the outcomes of coin flips (or similar uniform, indpendent random events) that were used to select the passwords. If a human picked the words all bets are off.

Since neither the NHS nor you talk about this critical factor, it's impossible to say anything concrete about the security of the passwords, other than if they're not chosen uniformly at random they're likely to be weak.

It is my understanding that as a rule, extending password length adds more entropy than expanding the alphabet.

If d is the alphabet size and n is the password length, then a password chosen uniformly at random has log2(d) * n bits of entropy. Doubling the size of the alphabet therefore adds n bits of entropy; adding an extra symbol to the password adds log2(d) bits. So it all comes down to the concrete values of d and n; there really is very little point in having a rule of thumb like you're proposing there since we can just calculate the increases straightforwardly.

Answer 8

Here's the thing, like it or not this question is not about laboratory, or mathematically more secure passwords. It's about getting people to "think" about their passwords when choosing them.

a. Is incorrect because it only has letters.
b. is wrong because it only has letters
c. is correct because it is long enough and includes "special characters"
d. is wrong because it has only letters.

Or in other words, passwords using only letters are bad.

Now, it's true that you can create a more secure password by using only letters if it's long enough, or random enough. Surly "asefhesesnh" is better then "p4ssw0rd!", but to be honest that is an understanding beyond most people in the target audience of this test.

Instead it's "better" to get users to understand to pick a password that is "longer" and has letters, numbers, and special characters.

In other words C is correct when your talking about a wide range of users with different levels of technical skills, creating their own passwords. Sure the math might be off, but it doesn't matter. No provider, is going to sit there and figure out password entropy, but they can count the number of $ in a password.

Answer 9

Option b gives you 52 possibilities per character.

For c to be better, each of the 7 characters must have more than 52^10/7 = at least 283 possibilities.

This means ASCII or western ANSI character sets won't suffice. They'd have to allow the Unicode character set (or some very arcane Asian ANSI codepages) in order for option c to be better.

It's obviously an ill-phrased question. There are 62 numbers and letters (upper + lower case) so the correct answer would be:

c if 'special characters' means I can use Unicode characters or any other character set that contains at least 221 non-alphanumeric (i.e. 'special') characters, otherwise b.