Password rules: Should I disallow "leetspeak" dictionary passwords like XKCD's Tr0ub4dor&3
The mistake here would be to believe that extra password rules increase security. They do not. They increase user annoyance; and they make users choose passwords that are harder to memorize. For some weird psychological reason, most people believe that a password with non-letter symbols is "more secure" in some ontological way than a password with only letters. However, this is fully unsubstantiated.
There is one "password rule" that is not harmful to security: a minimum password length. This is because of the combination of two things:
The most stupid brute force attacks enumerate all sequences of symbols, starting with sequences of 1, then 2, and so on. In that sense, a password that contains only 4 symbols can be said to be irremediably weak.
Users understand that notion of enumerating all small passwords. They are ready to accept that they need to type at least 6 or 7 letters.
All the other rules will be, at best, neutral, but most of them will in fact decrease security, because they will induce users to:
design and share with each other "methods" for generating passwords that your server will accept, methods which usually have a lot of punctuation characters but very little entropy;
write down their passwords, which are hard to memorize;
reuse passwords on other systems, for the same reason of difficult memorization.
"Password strength meters" are also harmful, because:
They are not, and cannot be, reliable. A password strength meter only measures how long a given password would stand against the exact brute force strategy incarnated by the meter code, but no attacker is constrained to follow the exact same strategy.
Password strength meters cannot measure the entropy that prevailed in the password selection, since they only see the result (the password itself).
They turn password selection into a game that encourages witty strategies on the part of the user, and wit is exactly what we do not want for passwords. Secure passwords strive on randomness.
What can help a lot is to provide a password generation system. Take care to make that system optional: you want users to willingly use it, not to force it upon them, lest they would rebel (and write down passwords, and share, and reuse).
So my recommendation would be:
- Reject passwords shorter than 7 characters (since you have a mitigation system against online attacks -- namely the autolock for 10 minutes after 5 wrong tries -- you can tolerate relatively short passwords). BUT NO OTHER RULE. Any sequence of 7 or more characters is fine.
- Provide one or, even better, several optional password generation mechanisms, e.g. diceware, the "correct horse" thing, and so on.
- Encourage the use of password managers.
- If possible, try to find something else than passwords for authenticating users.
My assertion is that you are pushing things in a somewhat skewed direction, not exactly the right one. In particular, password rules that insist on some specific characters are a bad thing (a common thing, but a bad thing nonetheless).
An index of entropy values (divide times by the number of nodes—state actors have lots of nodes):
BIT ~RAND CRACK CRACK DICTIONARY COUNT ENTROPY CHARS MD5 PBKDF2 ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ Alphamumerics (letters, numbers) 62 5.95 0.9 0s 0s Random printable char (any key on a US keyboard) 94 6.55 1.0 0s 0s Diceware dictionary word 7776 12.92 2.0 0s 0s Standard American English (en_US) dict word 100k 16.61 2.5 0s 0s Large American English dictionary word 650k 19.31 2.9 0s 1s Any word in any Wikipedia (any language) 58.4M 25.80 3.9 0s 58s Standard en_US dictionary with raNDomIZed cASE 6.3M 22.60 3.4 0s 6s Standard en_US dictionary with l33t variations 6.3M 22.60 3.4 0s 6s Std en_US w/ typos + (either rand case or leet) 38M 25.18 3.8 0s 38s Std en_US w/ rand case + typos + leet 2.4B 31.18 4.8 0s 41m Wikipedia word with raNDomIZed cASE (or l33t) 3.7B 31.80 4.9 0s 1h Wikipedia word w/ typos + (rand case xor leet) 22B 34.39 5.2 0s 6h rand order: 5 lower, 1 special, 1 num, 1 upper 1e11 36.52 5.6 2s 1d rand order: 6 lower and two of upper/num/special 4e11 38.67 5.9 10s 5d rand order: 6 lower, 1 spec/upper, yr 1900-2100 4e12 41.70 6.4 1m 49d rand order: 7 lower and two of upper/num/special 1e13 43.37 6.6 4m 131d rand order: 8 lower and two of upper/num/special 3e14 48.07 7.3 2h 4y* 4 word diceware passphrase 4e15 51.70 7.9 2d 8y* 8 char (random printable) passcode 6e15 52.44 8.0 2d 9y* 5 word diceware passphrase 3e19 64.62 9.9 6y* 27y* 10 char (random printable) passcode 5e19 65.55 10.0 6y* 29y* 4 standard en_US words 1e20 66.44 10.1 7y* 31y* 3 std en_US words and one large en_US word 6e20 69.10 10.5 11y* 35y* 3 std en_US words and 3 random printable chars 8e20 69.46 10.6 12y* 35y* 6 word diceware passphrase 2e23 77.55 11.8 26y* 47y*
"Any Wikipedia" includes Wiktionary, Wikibooks, etc, in all languages, with 58.4M unique words in 2009. Diceware was the basis for the xkcd comic. I assume a word size of six characters for random mixed case (so there are 2⁶ extra iterations) and I assume leet variations are as plentiful as mixed case. I'm using a value of six for intentional typos/misspellings.
Crack times are estimates for top-of-line single node cracking systems, with upgrades every 18mo to account for Moore's Law (when you see an asterisk, *). A space is considered cracked when half of it has been examined. GPU-based cracking can test MD5s at 23B/s on a single computer node. PBKDF2 is more robust, estimated at 300k/s on a 4 GPU system in 2013 (27mo ago → 227/18, so 300k × 2.828 = 849k/s → rounded to 1M/s).
(Note to self: read and incorporate/refute Jeffrey Goldberg's password-cracking math on Quora)
The question was clarified in the comments to my other answer (which I'm leaving since it may still be helpful). It's really just asking about whether or not to allow leetspeak. Two factor authentication is already in use for high security areas.
The word "troubador" is not in my standard dictionary but is in my large dictionary. Capitalizing the first letter of a word is not random mixed case (it's a common password topology), so it only doubles the count. Its random printable character equivalent is therefore log₂(650k × 2⁶ × 2) / 6.55 which is only four characters!
Therefore Tr0ub4dor&3 is equivalent to six random printable characters of complexity. A weak password, yet about as strong as most passwords people create to minimally fit complexity requirements.
If six random characters is too weak, you should disallow "leetspeak" dictionary passwords.
To be fully thorough, you may also want a large dictionary so you can count words as I have, otherwise a password like presidentclinton (33.22 bits, 5 chars, lower in reality due to being related) would be accepted by your system.
Additional password rules should always be tempered with the following rule:
"The more difficult it is to get a valid password and keep it current, the more likely people will write write them down in their day planners."
Accordingly, your question is a social one. How much education regarding good password management can you provide versus how much enforcement can you provide. You have to balance this for your own business. It sounds like you have important information to protect... is anyone training operators how to work with such sensitive information? Or are they just blindly relying on you and a hash algorithm to do it for them.
Just because it's different, I'd consider suggesting a learning experience when a bad password is given. I think it could be a balance between the approaches. More importantly, it might inspire you to find an even better solution:
- Have a minimum password length. This is the bare bones requirement, and you will have to enforce it
- If a password is weak, let them know it is weak, and offer to let them use it anyway (with some text indicating that you are trusting them to protect their own credentials properly)
- When accepting a weak password, include some text explaining what you consider weak about it ("It looks like you used l33t to make your password look safer. Guess what: it's not! This password is about 45000 times weaker than you actually think it is")