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

password strength

Am I wrong?

  • 199
    I like that they test people on the concepts of passwords, but that is a horrible set of possible answers.
    – schroeder
    Oct 6 '16 at 20:45
  • 29
    Ultimately it is a very poorly worded question with no clear answer. You are correct that generally length is more important than the character set when it comes to preventing a brute for cracking of a password but without defining what characters are included in "special characters" it is impossible to tell which is better. Option c also doesn't specify upper and lower case letters so it's entirely possible that it is a smaller character set and shorter password. 26 lower case letters +10 numbers +half a dozen common special characters is less characters than just upper and lower case letters Oct 6 '16 at 20:58
  • 57
    Did you have training, or was this quiz out of the blue? The right answer will be the one that the training provided, not the "true" answer. This is a sad state of affairs, but I expect it isn't limited to infosec and you hit similar issues with medical stuff. Props on being an NHS doctor; I'm British and you do amazing work.
    – paj28
    Oct 6 '16 at 22:11
  • 25
    Considering how many /banks/ are wrong about password security I can't say I'm surprised…
    – StarWeaver
    Oct 6 '16 at 23:22
  • 22
    @Michael we need a "i found out on the internet that someone is wrong IN REAL LIFE" xkcd for these occasions.
    – StarWeaver
    Oct 7 '16 at 2:06

By any measure, they're wrong:

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

Ten random alphabetics: 5210 = 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.

  • 25
    They didn't say ASCII, and many (most?) systems allow Unicode passwords. There are 128,172 Unicode characters, so "c" would be correct on that basis.
    – paj28
    Oct 6 '16 at 22:06
  • 8
    @paj28, the concept of capitalization is really only a feature of the Latin and Greek alphabets, and some of the alphabets derived from them.
    – Mark
    Oct 6 '16 at 22:27
  • 17
    With a quickscript I count 1984 lower and 1631 upper case characters. 3615 ** 10 = 381138671891365331133862350087890625 (for b) which is still less than 128172 ** 7 = 568266595760666481405057656211161088 (for c). Maybe we could trim some unprintable characters out of (c) to lower the number - but it's pretty clear the people who wrote the question did none of this maths!
    – paj28
    Oct 6 '16 at 22:31
  • 88
    @paj28 Broadly speaking this is a good point, but in practice I think it's not realistic to expect that the average doctor's system in an English-as-primary-language country will have anything but ASCII key inputs readily available (if they have to figure out how to configure multiple keyboard layouts on possibly multiple machines that might not be "theirs" to configure, and work input method toggle hotkeys into their password-entry flow, and possibly get locked out when they have to login into a workstation that isn't already thus configured, it might as well not exist).
    – mtraceur
    Oct 7 '16 at 1:06
  • 10
    This answer to a different question lays out the case against using non-ASCII characters in passwords. It's got nothing to do with the theory (larger character sets are better) and all to do with the practice (you cannot trust third party system implementers to process non-ASCII text reliably). Oct 7 '16 at 18:03

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.

  • 3
    Looking at an English-language keyboard near me (one that actually has engravings!) I found just over thirty avalailable non-alphanumerics (using only Shift as modifier - not Compose/Super/etc); same on a medical device touchscreen. So you can probably increase the score for C a bit (it's still never going to win!). Oct 7 '16 at 8:41
  • 3
    @TobySpeight Thanks for the input - did not expect there to be so many! I quess it is a question about wheater it is "available special chars" or "special chars people on average actually use". And then we are back to the fact that the original NHS question is to vague to be answered.
    – Anders
    Oct 7 '16 at 8:52
  • 11
    Password manager is not realistic in a medical setting. Doctors and other staff are logging into shared terminals in office spaces, hallways, patient rooms, etc. Not just on their own computer or device.
    – Dan Lowe
    Oct 7 '16 at 14:19
  • 16
    Excellent answer, but I subtly disagree with the conclusion in your last section ("What they should have asked"). Not because "Generate your passwords randomly with a password manager" is bad advice, but rather because it's good advice for end users, and less so for institutions like NHS, who, if they're really serious about password security they ought to be taking a hard look at two-factor authentication instead. Oct 7 '16 at 18:12
  • 2
    @MaciejPiechotka - as far as I can tell, the UK does not have any specific legislation similar to HIPA. That would mean that there is only a general duty under the Data Protection Act that controllers of confidential information should follow best practices in order to ensure that the information is not incorrectly disclosed, but which does not have any specific legislative requirements on actual technologies used. Oct 8 '16 at 2:11

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

  • 3
    From a practical standpoint the keyspace has to be restricted to what the user can reasonably type. Since this is the NHS the only language they can be sure of having available is English. Foreign speakers might have other things configured on their systems but that doesn't mean every computer they may need to use will thus be configured. Oct 7 '16 at 5:53
  • @LorenPechtel I understand that, and as I tried to imply I was not saying that the example is truly realistic, but merely that ambiguities like that are enough to make the question impossible to answer with any certainty.
    – Vality
    Oct 7 '16 at 5:55
  • 3
    I object to this "unanswerable" standpoint. Yes there are certain unknowns, meaning it's not possible to calculate absolute definitely correct numbers about possibilities. This does not mean it's unanswerable, as all we're looking for here are generalities. We know rough sizes of alphabets people tend to use. And also, is it not true that the number of possibilities added by extending length from 7 to 10 far outweighs a difference of, say, 40% or so in your alphabet size? Regardless of unknowns, there are definitely better and worse rules of thumb. Oct 7 '16 at 6:50
  • I agree with everything but the last paragraph. I think it is useful to teach people about the reasoning behind password complexity requirements in general (though not, I'd concur, the details of any one particular set of rules), because if they understand that reasoning many of them (in theory, hopefully) might be more inclined & able to choose stronger passwords on their own volition. Versus just doing the bare minimum to satisfy the requirements of whatever technical enforcement mechanism is in place. Oct 16 '16 at 20:46

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.

  • 1
    NTLM also splits the 14-character password into two 7-character hashes, so the effective password length is 7.
    – March Ho
    Oct 8 '16 at 13:00
  • @MarchHo: I think you might have just solved the puzzle! Updated my answer.
    – Jander
    Oct 8 '16 at 19:22
  • The NTLM hashing process does not split the password into two 7-character segments before hashing. You're thinking of the LM hashing process, which does indeed do this. LM also converts all alphabetic characters to uppercase before hashing.
    – PwdRsch
    Oct 9 '16 at 19:38
  • NTLM version 1 does use the process I'm talking about, which it inherited from LANMAN. See e.g. Wikipedia and MSDN. NTLMv2 is the one that fixes this issue by switching to an MD4-based schema. Good point on the conversion to uppercase.
    – Jander
    Oct 10 '16 at 17:05
  • 1
    It's certainly true that healthcare environments can be very slow to upgrade. In 2014 I was still seeing IE6 in web server logs for a healthcare-related web app. Oct 14 '16 at 10:39

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.

  • 6
    In order for "c" to be the correct answer, you need at least 221 special characters to choose from, in addition to the alphanumerics. Good luck finding a keyboard that will let you type your password!
    – Mark
    Oct 6 '16 at 21:36
  • 4
    These are training questionnaires for doctors, not a Comp Sec exam. While you can mathematically prove entropy in favor of another answer, their goal is to get people to think 'Pa$$w0rd' instead of 'password' Oct 6 '16 at 21:44
  • 1
    @Mark Yeah. And you better hope that keyboard doesn't offer more letters. Oh, wait. Basically any keyboard offers characters like à already, further increasing that number dramatically.
    – UTF-8
    Oct 6 '16 at 21:46
  • 3
    @ShaneAndrie The question was "Which of the following would make the most secure password?", not "Which password policy will make the users choose more secure passwords on average?". Furthermore, you can easily accidentally create passwords in accordance to option c which aren't part of the most popular million passwords. Users are far less prone to accidentally creating a password which isn't part part of the most popular million passwords if they only have to comply with option b. It should always be checked whether a password is one of the million most popular ones by the service.
    – UTF-8
    Oct 6 '16 at 22:04
  • 11
    @ShaneAndrie Their goal is wrong, then. They shouldn't be getting people to think "Pa$$w0rd" instead of "password"; they should be getting people to think "this is a passphrase and you can't guess it" instead of "password", which would work towards their real goal much more effectively.
    – mtraceur
    Oct 7 '16 at 1:12

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.

  • 4
    Thanks for this. Is there any evidence that people being forced to use special characters actually leads to more unpredictable passwords? Because I would posit that someone who's forced to come up with a 10 character password, with no other rules, might well produce one that is harder to guess than someone who's forced to come up with a 7 character one which includes special characters. This is the real question here. Oct 6 '16 at 20:58
  • 1
    And for the record, in my team we use "correct horse battery staple" in a couple of places ;). Places where we don't think there needs to be a password in the first place... Oct 6 '16 at 21:00
  • 2
    Quite the opposite, allowing people to select passwords is horrible. We tend to use mnemonics, and a not a very large list of patterns. This makes us easy to profile and therefore easy to guess. Password Physiology is a thing, and it one of the reason certificates are heavily pushed. Oct 6 '16 at 22:07
  • 2
    @RobinWinslow i would rather think that 10 letter english words would make up a large proportion of chosen passwords as users strive to make them memorable rather than unpredicatble
    – JamesRyan
    Oct 7 '16 at 10:15

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.

  • 3
    This seems unnecessarily pedantic. I am aware that entropy is about randomness, but I'm asking which is a better policy. Are you really saying there is no point having any password policy at all apart from "use a random generator"? Oct 6 '16 at 20:44
  • 2
    @RobinWinslow: My point is that unless we introduce randomness into the equation we don't really have any reason to believe either of these policies will actually be secure. Debating between those alternatives when humans choose the passwords is missing the forest for the trees. Oct 6 '16 at 20:53
  • 1
    @RobinWinslow: if we take 2^2 as the starting point, it is trivial to observe that 3^2 > 2^3. And my larger point is that there is no need to generalize when you have concrete examples that you can just calculate from. Oct 6 '16 at 20:55
  • 2
    There is nothing pedantic with this answer, and it does answer your question. If there is something else you want to know, I think you need to be more clear about it in your question.
    – Anders
    Oct 6 '16 at 21:08
  • 1
    @RobinWinslow: But the NHS examples that you quoted show an apparent linear growth of password lengths (5, 6, 7, 10) vs. an exponential increase of alphabet size (26, 52, 95). So the rule of thumb that x^y grows faster on y than on x risks leading you astray on this one example. And again, just doing the math is simple enough that we don't need to resort to rules of thumb. Oct 6 '16 at 22:38

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.

  • "Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess" Oct 10 '16 at 19:15
  • "C is correct when your (Sic.) talking about a wide range of users with different levels of technical skills, creating their own passwords" - most experts here seem to disagree. Do you have any evidence? Oct 10 '16 at 19:17
  • 1
    practically everyone else has said C is a bad answer (as well as saying the question in general is bad, and randomness is the best solution etc.). I believe that even when dealing with real people in the real world, if you tell them to come up with a 10 character password with only letters they will produce one that is harder for a machine to guess than if you tell them to come up with a 7 character one including special characters. "lazypsycho" is better than "Daphne!". Oct 10 '16 at 19:24
  • 5
    In the real world, requirement "c" will produce a password consisting of, in order, an uppercase letter, four lowercase letters, a digit, and a punctuation symbol. Further, the digit will usually be a "1" and the punctuation will be a period, exclamation point, or question mark. The overall result will be a complexity on the order of 26^5, or about twelve million possible passwords.
    – Mark
    Oct 10 '16 at 21:05
  • 1
    @Mark Clearly the solution to this problem is that we must make a rule that the number must not be a 1, and must not be at the beginning or the end of the password.That will solve the problem, you betcha.
    – barbecue
    Oct 10 '16 at 22:06

Option b gives you 52 possibilities per character.

For c to be better, each of the 7 characters must have more than 5210/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.

  • Except that anyone trying to crack a password will run it through a fairly extended alpha-num before bothering with special characters.
    – user83389
    Oct 14 '16 at 17:34

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