Password rules: Should I disallow "leetspeak" dictionary passwords like XKCD's Tr0ub4dor&3

Question

TLDR: We already require two-factor authentication for some users. I'm hashing, salting, and doing things to encourage long passphrases. I'm not interested in the merits of password complexity rules in general. Some of this is required by law, and some of it is required by the customer. My question is fairly narrow: Should I detect leetspeak passwords such as Tr0ub4dor&3 as being a dictionary word, and therefore fail passwords that primarily consist of a single dictionary word (even if leeted). Multiple word passphrases are always accepted regardless if leeted or not, this is only a question about those who choose to use more traditional short passwords.

I am the lead developer for an upcoming government website which will expose sensitive personal information (criminal history, SSNs, etc. primarily). The website will be consumed by the general public, for doing background checks on employees, etc.

On the backend, I'm storing the passwords hashed with PBKDF2 salted on a per-user basis with very high iterations, so brute force hashing attacks against stronger passwords are not realistic (currently), and the website locks the user out for 10 min after five bad tries, so you can't brute force really that way either.

I'm getting some pushback from my customers/partners about the severity of the password rules I have implemented.

Obviously I want people to use 16-20+ char passphrases, but this is a slow-moving bureaucracy. So in addition to allowing/encouraging those good passwords, I have to allow some shorter "hard" passwords. I'm just trying to limit our exposure.

In particular, the "no dictionary word" requirement is causing people frustration, as I disallow the classic leetspeak passwords such as XKCD's famous Tr0ub4dor&3. (For those curious, I run the proposed password through a leetspeak permutation translator (including dropping the char) and then compare each permutation against a dictionary)

Am I being too severe? I am a big proponent of "Avids rule of usability" - Security at the expense of usability comes at the expense of security. But in this case, I think it's more an issue of habit/education. I allow diceware/readable passphrase passwords with no restrictions, only the "normal" passwords get stronger requirements. XKCD #936: Short complex password, or long dictionary passphrase?

Should I try to solve this with just better UI help? Should I stick to my guns? The multiple recent high-profile hacks, especially ones that exposed passwords makes me think I'm in the right, but I also don't want to make things stupid for no reason. Since I'm protected from brute force attacks fairly well (I think/hope), is this unnecessary complexity? Or just good defense in depth?

For those that can't grok passphrases or truly random passwords, the "two words plus num/symbols" passwords seem to be both easy enough, and at least harder to hack, if I can get people to read the instructions...

Ideas:

• Better password hints/displayed more prominently (too subjective?)
• Better strength meter (something based on zxcvbn? - would fail the dictionary words on the client-side rather than after a submit)
• Disallow all "short" passwords, force people to use only passphrases, which makes the rules simpler?
• "make me a password" button that generates a passphrase for them and makes them copy it into the password fields
• Give up and let the leetspeek passwords through?

Heres what I currently have in my password instructions/rules:

• 16 characters or longer passphrase (unlimited max)

  or

• At least eight characters

• Contain three of the following
  • UPPERCASE
  • lowercase
  • Numbers 0123456789
  • Symbols !@#$%^&*()_-+=,./<>?;:'"
• Not based on a dictionary word
• Not your username

Examples of passwords that won't be accepted

• Troubador (Single dictionary word)
• Troubador&3 (Single dictionary word plus numbers and symbols)
• Tr0ub4dor&3 (Based on a single dictionary word)
• 12345678 (Does not contain 3/4 character types)
• abcdefgh (Does not contain 3/4 character types)
• ABCDEFGH (Does not contain 3/4 character types)
• ABCdefgh (Does not contain 3/4 character types)
• ABC@#$%! (Does not contain 3/4 character types)
• ab12CD (Too Short)

Examples of passwords that will be accepted (do not use any of these passwords):

• correct horse battery staple (Diceware password)
• should floating things fashion the mandate (Readable passphrase - link to makemeapassword.org)
• GoodPassword4! (multiple words, upper, lower, numbers, symbols)
• Yyqlzka6IAGMyoZPAGpP (random string using uppercase, lowercase, and numbers)

Answer 1

An index of entropy values (divide times by the number of nodes—state actors have lots of nodes):

Dictionary	Count	Bit Entropy	~Rand Chars	Crack MD5	Crack PBKDF2
Alphanumerics (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
Emoji (including emoji modifiers)	3700	11.85	1.8	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 as used in this table, 8.4y ago → 28.4/1.5 = 14551k/s → round to 15M/s in 2021).}

^{(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.

Answer 2

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:

1. 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;

2. write down their passwords, which are hard to memorize;

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

Answer 3

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

Answer 4

If you aren't afraid of anyone stealing and brute forcing your passwords, then your most likely case of a password being discovered is a phishing attack. Password complexity requirements won't protect you from phishing attacks.

If you use very complex passwords, users will find a password that works and stick with it, when it expires, they will make the most minor change and keep going. This means a determined phisher will be able to guess the new password fairly quickly.

Consider using 2-factor authentication because no password complexity scheme will protect you from user actions. (Remember, users are humans too, and want to get their jobs done without spending all day on a password)

BTW, here are a couple related questions:

Are password complexity rules counterproductive?

Recommended policy on password complexity

Answer 5

I'd say 8 is too low, even 9 is a order of magnitude more secure (literally) for something like this. You certainly want to consider 2-factor authentication given what this content is.

Also, consider how people approach mandated things like capital letters (almost always the first character) and numbers (almost always the last character). These actually weaken your entropy. I'd even suggest the use of words, as long as you can make it clear that they should be unrelated and most definitely not a quotation of any sort.

The most secure yet memorable passphrase you can have is a collection of words, one of which is a passcode. An attacker would have to know where to put that code or else assume the really long password can have the code anywhere.

One trick banks use to avoid keyloggers is to have images for you to click on. Some, like ING Direct (before CapitalOne bought them and changed the method), used a pin system; your password was a four digit pin that could only be entered with a mouse or by pressing randomized keys associated to the images, and if a persistent cookie was missing, you'd also have to answer a security question. This works almost as well as two factor authentication.

Both are subject to session hijacking. To deal with that, you can try using a browser fingerprint beyond that of a cookie. A somewhat decent approximation without going into the trouble of something like Panopticlick would be to merely use the IP address, the User Agent string, an SSL cookie, and a ten minute session timeout.

Requiring password rotation over time can help fight against phishing and keyloggers, but they again harm password complexity. These only help in that regard if the attacker has a long delay before trying to perform the access. This is where extra security questions for unknown computers can help.

You could also consider client SSL certificates, though they might not themselves be password protected (and you can't enforce that), meaning that a lost computer is a huge problem.

I recommend multiple layers. A secure passphrase is one layer, the second layer (only needed if the browser fingerprint doesn't match) is either external (two factor), a randomly placed known image sequence to click, or a client SSL certificate (which would alleviate the need for fingerprinting).

Answer 6

Why don't you simply handle leetspeak-Words like regular ones? In your examples you say that you you accept GoodPassword4!, as it has more than one word (and Symbols and Numbers). So the implicit rule you seem to apply here is:

“If you have to use a dictionary words, use more than just one (and also some Symbol and Number)”.

I guess that's a rule that's actually easy to understand and to accept from the user's point of view. But than it would be rather annoying to get G00dP4ssword4! or B4DTr0ub4dor1! rejected under that rule.

So, no, you should not disallow "leetspeak" dictionary words per se, but treat them like regular dictionary words.

Answer 7

How about a middle ground?

The rules you are giving basically say either long or hard with no middle ground.

Instead, how about a graduated system: Assign a certain complexity per character and a certain multiplier for the various hard features. If that number is high enough you accept the password. Thus if you'll accept basically anything at 16 characters you would accept 15 with one hard feature.

Answer 8

Ask your grandma (or any grandma within walking distance) to define a password. She'll have to follow the strict password rules (which you've printed out for her), but she's not allowed to talk to you. And it shouldn't take "too long".

Also, tell her that she will need that password the following days/weeks (to use your web service), so she'll have to make sure to remember it (probably by writing it down).

(Remember that, when you see your grandma reaching for a piece of paper, you could tell her not to write it down and stick it on the fridge - you won't be able to tell your real users that though. Unless you write a list of rules on the registration form, like "don't write your password on the fridge" and "no, not on your monitor either".)

Now, how'd it go? If the answer is "not so great" (did she give up after 5 minutes and ask you if you have eaten already because that also counts as "not so great"), that might be a strong indication that your password rules are too strong.

I generally agree with the answer that got most of the upvotes and with several of the comments:

One basic rule, which is the minimum length, like 7 or 12 or 15 or whatever. Yes, that will allow people to use "aaaaaaa" as password but at least it won't be written in clear-text where other people will see it because they can remember it. All those rules probably do nothing but harm (well, mostly). No matter how many millions of dictionary words you exclude, someone will use a word you haven't thought of (well, not "you" technically, you probably just get that list from somewhere). And for some reason, a human attacker will have success because the correct password "Mugwump" or "Smellfungus" is the first one he tried.

As for those "you have to use 3 uppercase, lowercase, numbers and special chars" rules, that will just make many people write ABCabc012!@# down on a piece of paper because they can't remember it. (If there's no fridge in the area, a convenient wall will do as well, see this article.)

And to be fair, people who understand how important this is are people too, they won't be able to remember those (artificial) passwords either and they will be annoyed. Most regular computer users (the "print the Internet" kind of users) will be annoyed anyway (even the single fact that a password is necessary is "annoying" to many, after all, computers should be able to magically identify the user in 2015).

Without these complicated rules, you'll have at least a chance of many people actually being able to remember their password.

However, as done by some services, increasing security if something fishy is detected might be an idea. You're already blocking authentication completely after a few failed attempts, which is good. You might think about steps inbetween, for example after one or two failed attempts, you could ask for a captcha. Also, a specific client which keeps trying to log in (even though login is already blocked) might be auto-blocked for a day (on a lower level, maybe even by a firewall).

Answer 9

Here's a brute-force solution to the problem of brute force password cracking: Dedicate a few PCs to actually trying to crack passwords using the same (few) cracking tools that the attackers use. When a password is successfully cracked, send an e-mail politely informing the user that their password was detected to be too weak and requiring the user to change their password.

Answer 10

I don't like password rules that have many, "this, but not that, one of these, but not too many of those" rules.

Am I being too severe?

I think so, here's why. I use 1Password. It generates random passwords for me. They look like this:

luaD/fcr61nt7A%NxBCR
NeTtVL7uuAqmL5_j&cm1
qwtlOjJsQor)9nM1%zl2

Some websites have rejected such passwords. Why? Arbitrary rules.

Prior to this I hadn't considered a system that is the reverse: rather than asking me to create a password, the system assigns me one that satisfies its rules. The password will invariably end up on paper or pasted in some file by the person, but it's unique and not in a dictionary.

IAM within Amazon Web Services does pretty much this, so this idea even has some prior art out there.

Answer 11

Again, I’m not an expert in information security by any stretch, but perhaps you could just encourage your users to use LastPass or Keeper to generate and store large (truly) random passwords for them, and store them in the secure vault? And to use 2-factor authentication too.

I realize LastPass was recently hacked, but users that chose long, secure LastPass passwords should still be safe from having their vault opened. Users that chose a weak password as their master password can't be helped anyways.

Of course, it's not the best plan, but it should at least put your users on the right track. There is a lot of inconsistency in security between websites. I understand that (for example, my bank allows a maximum password length of 16 characters, but my reddit password is 100 characters). But 16 random characters is still better than having to write down the password because you can't remember it.