Is the NHS wrong about passwords?
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?
I like that they test people on the concepts of passwords, but that is a horrible set of possible answers.
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
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.
Considering how many /banks/ are wrong about password security I can't say I'm surprised…
I suspect the authors are looking at this from the practical standpoint rather than theoretical. Fact is, most cracking attempts start with dictionary based searches, possibly with a few trivial substitutions. So while more letters may be less guessable than fewer characters including punctuation, crackers are fairly likely to try all letters first before widening the character set much. So _practical_ time-to-break may be very different from theoretical.
This is one of those Internet questions that gets me all riled up and wanting to start and angry letter writing campaign to someone.
@Michael we need a "i found out on the internet that someone is wrong IN REAL LIFE" xkcd for these occasions.
The "c" answer is also bad because it mentions a 7-char password, which is *way* too short for all standards.
@keshlam This is kinda my question. I'm actually more interested in the practical implications than the absolute total number of random possibilities. The problem with that logic about special characters though is that anyone *trying* to break into somewhere with the special characters requirement will know about the requirement. I am guessing that people tend to use special characters in very predictable ways, and so the benefit of increased length (ahem) is still way superior. But I'd welcome anyone who knows of research on this.
The only problem I have with that comic is that I won't be able to use that password almost anywhere because everyone has requirement for number, case (and sometimes even special char).
And secure from what threat? If the server stores the password in plain text then they are all equally secure from that. You might argue the shortest on is most secure then, as you are least likely to write it down and leave it on your desk.
This the same NHS which still funds homeopathy, remember! Don't get me wrong, I think the NHS is one of the best things we have in Britain - but it has chronic management problems, and its track record with IT is best summarised by the Despair.com quote: "Sometimes your purpose in life is to serve as a warning to others". So surprised at the fact they can't get some basic IT training right? Not very.
There is the point that the C password will (if appropriately constrained) contain some "special" characters, preventing the use of simple names or common words/phrases. This doesn't increase the statistical strength of the password but does make it less susceptible to a dictionary cracking scheme.
No, it doesn't. The point the OP is asking/making about common substitutions is dead on the money, and current password cracking algorithms use heuristic analysis, not simple brute force dictionary attacks. No matter what characters are in a 7 character password, it's going to be broken in a relatively shorter period of time. There just aren't enough permutations and the computer can try every single possibility regardless of complexity in a short timespan. 8 chars is an order of magnitude better but still too short. 9 is vastly better than 8, and 10 vastly better than 9, by *huge* margins.
10^26 >> 26^10. That is, twenty six digits has much greater combinations than ten letters. Length is nearly always more important than width.
Entropy depends upon the alphabet and number of symbols used. In case of English words (which number around a million) : a pass word of four such randomly chosen words gives an entropy of 79 ie (log2(10^[6*4]). Clearly when we are choosing English words-- our alphabet is not one , of some 52 odd elements...as some seem to confuse here.
Of course even a 26 symbol set can describe a string of words ...In this regards one need only ensure adequate length so that the password entropy as 'seen' with 26 symbol alphabet view is comparable; for an entropy of more than 72 here we require a total of around 17 characters . i.e.72/Log2(26)
Reminds me of the IT security compliance quiz administered by a healthcare provider in Texas, where one of the quiz questions tried to see if people would project their knowledge of biological viruses onto computer malware. Unfortunately for the supposed experts writing the quiz, computer viruses are highly likely to cause an increase in system temperature and sluggishness, as a result of the CPU load caused by the malware trying to spread.
Note that a **human factor** may be involved in their decision. Pushing them away from letter-only passwords (even if that means they don't use quite as long a one because it's hard to remember) could, on average, create more secure passwords simply because you get fewer people are using things like `secretpass` (which is 10 chars...yet would probably be broken quite quicktly) or other extremely simplistic word-style passwords. ...still a crummy question though.
Possible duplicate of XKCD #936: Short complex password, or long dictionary passphrase?
I think most of the answers here are missing the point. The question is not asking a bunch of network admins "what password _requirements_ are best to enforce?", it's asking a bunch of users "which password (assuming all of them meet the minimum requirements) is better to pick?". In other words, it's trying to get the user to think about how they choose a password, to think about the very factors which many answers identify as key (randomness is not a valid real-world assumption unless we enforce the use of password managers, most of which use a non-random password to gain access).
Not for any specific radomly generated password, but for a policy, or, as Adam mentions, requirements, they are correct that the special characters make it more likely that more difficult to guess/reason passwords will be generated, since users generally don't create completely random ones.
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.
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.
In fact for "b" they didn't say they were upper and lower case LATIN letters. I expect Unicode has a job load of non-latin upper and lower case.
@paj28, the concept of capitalization is really only a feature of the Latin and Greek alphabets, and some of the alphabets derived from them.
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 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 If you're taking security seriously enough to do questionnaires on them, you're probably beyond the point of typing them in manually, they're bound to have physical access keys (like an RFID chip or a thumb drive with the key).
@Kevin if only... With plenty of mutually incompatible systems the NHS is the type of institution that runs on written down passwords. aboutthe best you can hope for is that it's not on a post-it under the keyboard. Some *more sophsticated* hospital staff I've come across have had a plaintext document on a password-protected phone. Others a book.
@ChrisH Seriously? I'm an app developer who makes apps for Dutch healthcare institutions, the NHS is going to be our first international customer next year. Almost all Dutch healthcare organisations use RFID chips to authenticate, the healthcare inspection basically forces them to do so. If NHS is really that insecure I'm not looking forward to next year lol :P
@Kevin I only have my own eyes to go on, and don't spend a lot of time in healthcare places so things may have moved on. But there are still a lot of legacy systems in use, and the classic problems of mutliple passwords with different rules, all of which much be changed at different frequencies. The NHS were one of the biggest bodies to pay for extended XP support after end-of-life. I believe they've stopped now but that doesn't mean everything has moved on
Any american keyboard has diacritics and can be configured in us-intl to print è, é, ò, ç, ë, õ.. 5 diactritics, usually on the 5 vowels, that's 50 more characters, or `145^7 = 1.3 10^15` or just 100 times less.
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).
And moreover, in the case of c, if the system requires that all passwords contain some mixture of upper/lower symbol and numbers, then the number of possible passwords decreases a good bit, depending on the rules, of course.
@JimmyJames, just as increasing the alphabet size doesn't help things much, decreasing it doesn't harm things much -- in theory. In practice, everyone puts the uppercase letter at the start of the password, and the digit and symbol at the end.
@Mark Please help me understand this. Let's say the rules require at least one uppercase, one numeric and one symbol. The number of possible passwords is then 23*10*26*95^4 = 487,074,737,500 or 143 times less than the 95^7 figure. 143 times less is a lot in my book e.g. 143 months to brute force all hashes is a lot more than 1 month. Either my math is wrong or we have different ideas about what 'much' means.
@JimmyJames, Two errors in your math. First, there are 33 symbols, not 23, and second, the restricted characters can appear anywhere in the password. The correct formula is (33*10*26*95^4*7!)/(3!*4!) = 24,459,622,687,500, or about a third as large as 95^7.
@Mark Yeah, I realized the second error as I was enjoying my dinner beer. Clearly I was B12 deficient. So OK not as big a difference as I had thought but still, 1/3 is not an insignificant difference.
@njzk2: it is just silly to assert that typical users are going to put diacritics in their passwords. It just isn't going to happen, end of story. The length of the password is paramount. And the variety of the input **in practice** is smaller than the full ASCII character set.
@Craig right, because typical users are of course Americans. How silly of me to consider the rest of the world.
@njzk2: nice ignition. They use a lot of umlauts in Britain, do they? English is a language that isn't used much for, say, business in the rest of the world? I'm just speaking to practicality. Bottom line, the actual size, in practice, of the alphabet from which passwords are chosen is much smaller than the full Unicode character set. Theory is nice, but reality is what it is. Besides, **you're** the one who was talking about American keyboards and diacritics.
@Craig yes, because that's the keyboard I happened to be writing that comment on. But that should only emphasis the fact that even people who don't usually use diacritics can still put some in their password. (but like you said, that's theory. In practice, we all know that the password is always "123456") (I should point out, though, that my initial point was that *even* by considering various common diacritics, we would be shifting the order of magnitude, but not the outcome of the comparison)
The problem with this answer is that people don't choose passwords randomly *at all*. So it's better to look at a large database of actual passwords and compare for each of these constraints how easy the average password meeting the constraint is to crack.
Flipside is that if you have only letters the chances are that the password contains a dictionary word.... Probably only a dictionary word/s
@Kevin The NHS does indeed have a smartcard-based authentication solution. However, as with any SSO solution, integration is a pain, and many vendors don't do it, and of course it's not integrated into solutions that predate its introduction.
Disagree with the "by any measure" - who creates a password that is completely random? Almost no one, because it is difficult to remember. So, since we're already imposing some kind of pattern or order on the selection process, which of the options is more likely to re-introduce a level of randomness that would be difficult to guess or reason for someone trying to crack the password? Regardless of the number of characters, if I pick something like MyNameIsAndy, that might be easily guessed, where requiring that I include an odd character, somewhere, will make it more random - MyName#IsAndy