Is the NHS wrong about passwords?

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.

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 woulb be better than a really long 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 occurrence in leaked databases).

I could go on speculating 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.

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