120

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)
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
Jason Coyne
  • 1,583
  • 2
  • 10
  • 10
  • 86
    I'm a little surprised you dont have a hard-coded rule blocking `correct horse battery staple` – David says Reinstate Monica Jul 10 '15 at 20:57
  • 39
    _"16 character or longer passphrase (unlimited max)"_ So, If I put GB of characters in that field, you allow me to post that to server? Interesting... – StupidOne Jul 11 '15 at 08:26
  • 33
    @KevinCoulombe If you do that, you are virtually *forcing* people to write down the password you are compelling them to use. And like it or not, many of those people who store the password somewhere because they can't remember it, are going to put it somewhere like their Google contacts database. – Craig Tullis Jul 11 '15 at 23:08
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/25819/discussion-on-question-by-jason-coyne-password-rules-should-i-disallow-leetspe). – Jeff Ferland Jul 14 '15 at 15:19
  • 1
    When a user chooses a password, search for it on Google and reject it if it returns results. But that's kind of a big leak... – Tony Jul 14 '15 at 21:03
  • My university teacher said many times that too complex passwords are bad because people tent to write them down on `post-it`s and stick them to monitors since they can not memorize them. – FallenAngel Jul 15 '15 at 08:48
  • 4
    "But in this case I think it's more an issue of habit/education." Reeducating all your users may be a noble cause, but a foolhardy one. Trying to change the habits of just one person is damn near impossible. – msw Jul 15 '15 at 13:07
  • 4
    @Tony Yes, that's one hell of a leak. Go ahead and post that on TheDailyWTF – Navin Jul 16 '15 at 04:50
  • Don't forget `SlowEquals()`. – Mark Buffalo Nov 06 '15 at 19:22
  • @FallenAngel: I've heard that alot, and keep wondering is that the biggest danger these days? I mean, if someone got past security to my desk, they presumably could also but a physical key logger on my keyboard, which moots a large portion of security. On the other hand, go ahead and try to remotely hack a post-it note. – sharur Dec 26 '19 at 18:10
  • @sharur which is why the best solution is a long random crap password, stored in a password manager, protected by a long but easy to memorize passphrase. That protects from both remote/hash attacks, and local/social engineering attacks – Jason Coyne Jan 21 '20 at 17:54
  • Drawing from [this answer](https://security.stackexchange.com/a/45852/10990) it seems `Tr0ub4d0ur` is vulnerable to `rule based dictionary attacks`. – Vorac Jul 11 '20 at 06:30

11 Answers11

215

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

SilverlightFox
  • 33,698
  • 6
  • 69
  • 185
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 2
    Offline attacks against a 7 char password with no rules would guess many passwords very quickly. – Jason Coyne Jul 10 '15 at 19:01
  • 28
    The OP mentioned they're working on a government site. If it's for the U.S. government, they'll have to follow NIST guidelines which require 12-character minimums - 7 won't do at all. – Iszi Jul 10 '15 at 19:14
  • 2
    In this particular case we are subject to the CJIS guidelines which are 8, and not a dictionary word. Forcing symbols implicitly makes it not a dictionary word, but I was trying to make it a bit more secure than that – Jason Coyne Jul 10 '15 at 20:08
  • 1
    Wow. Compared to NIST, they're mostly pretty lax. 8 characters vs. 12. 90-day expiration vs. 60. Password history of 10 vs. 24. Only things that beef it up are the bits about no dictionary words or proper names, and not being the same as the user ID. – Iszi Jul 10 '15 at 20:23
  • 1
    To eliminate gamification, simply have your program announce to everyone in the office what bad passwords people try to use. People are unlikely to experiment if people watch them experiment. – PyRulez Jul 10 '15 at 21:52
  • 21
    I'd add two more rules: the password cannot be the same as the username, and the password cannot appear in a dictionary or a list of the most common passwords. A five-try lockout doesn't help if the password is one of the first five things an attacker will try. – Mark Jul 10 '15 at 22:10
  • @Mark: At minimum, disallow "password" as a password. – supercat Jul 10 '15 at 22:18
  • Out of interest, is there any relevant compression algorithm (perhaps one using a pre-built dictionary of natural language) such that we can not merely limit the password length, but limit the *compressed* password length? My fear is that in the realm we're talking about, 7 or 12 bytes or whatever, there are no good compression algorithms, but you never know. And it could rule out people who go, "`123` doesn't work, what about `123123123`? Sorted". – Steve Jessop Jul 11 '15 at 02:49
  • @SteveJessop LZW or something similar would do a decent job of testing compression like you suggest, but so would just directly testing for repetition. – Jason Coyne Jul 11 '15 at 12:54
  • @JasonCoyne: Fair enough, `len(list(lzw.compress('123123123'))) == 8`. So it's a start in that it's identified 8 bits of "slack" in the password. As you say, testing for repetition would identify a lot more. – Steve Jessop Jul 11 '15 at 15:07
  • 12
    If the only rule really is "at least 7 characters" I think we can all agree that the amount of trivial dictionary words will be exceedingly high. And since we know that one of those is about as secure as 4 random alphanumeric letters (I'm really generous there) why not accept those too? Accepting one really bad password but not the other is rather unfair. Personally I'm all for people writing down their complex passwords for online systems - generally everybody who can get that much physical access to steal one of those scraps of paper could just as easily install a keylogger anyhow. – Voo Jul 11 '15 at 18:15
  • 13
    On a more conceptual level, the main problem is trying to _force_ the user to choose a "strong" password. To get decent security, the user should _understand_ what makes a password good or not. "Password rules" such as enforcing a punctuation sign are not effective for that; in fact, they make the user believe that '.' is somehow "more secure" than a letter like 'k', and that is counterproductive (it makes it _less_ probable that the user will actually understand things). Security requires user cooperation, which feeds on _freedom_ and _pedagogy_, not _rules_. – Tom Leek Jul 11 '15 at 21:27
  • 2
    I like much of this answer (FWIW), but it seems to be only half-heartedly challenging the frame of the question. One the one hand, you say that you can't legislate good passwords, instead users need to be educated to choose good ones. This justifies your strong advice that the password `password` shouldn't be rejected by the system. But then you advise banning 6-letter passwords. I don't follow the logic: if as a matter of policy you're going to permit terrible passwords that you know would fall quickly to brute force, since it's on the user not to choose one, then why reject 6 letters? – Steve Jessop Jul 12 '15 at 15:03
  • Is it just because it's so lightweight (in code) to enforce a length limit, whereas it's relatively heavyweight to check against a list of known common passwords that attackers will try first? – Steve Jessop Jul 12 '15 at 15:05
  • Well, length (especially when you get to 12/16/20 etc) just completely solves the problem. Everything else solves part of it, and leaves loopholes and places for people to do dumb things. getting users (and site owners) up to speed takes time tho. the "8 complex" rule is approaching a decade old now, non geeks don't understand why it wouldn't still be good enough. – Jason Coyne Jul 12 '15 at 17:17
  • 7
    @SteveJessop: by my logic there should be no lower limit on password length. However, if the system accepts (for instance) three-letter passwords, then quite a lot of users will feel invested with the sacred mission to warn you (the sysadmin) about the folly of three-letter passwords, and simply reading all these complaints will consume a lot of time. Enforcing a minimal length is something that average users understand and accept, and serves as a signal that you actually mind security. – Tom Leek Jul 12 '15 at 17:53
  • 1
    @Voo, unless they needed root/admin access to install a keylogger.....for which they would need a password.....conveniently taped to the screen. – Paul Draper Jul 12 '15 at 19:26
  • @Paul Hardware keyloggers exist and are incredibly cheap and quick and easy to install. And that's just the easiest of many available options. Look up all the evil maid attacks. There's a reason why security 101 says if the attacker has physical access to your machine you've lost. – Voo Jul 12 '15 at 20:30
  • 2
    "[Password strength meters] are not, and cannot be, reliable" - that seems like an oversimplification to me. Sure, [zxcvbn](https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/) isn't *perfect*, but it's arguably better than nothing. – Kevin Jul 12 '15 at 22:06
  • @TomLeek re your last comment, so you're basically saying that password minimum length is a form of *security theater*, but the good kind that mitigates a specific (human) cost? I think you are relying too much on the competence of average users. – AviD Jul 13 '15 at 09:43
  • My main point is that users should select non-weak passwords _on their own volition_ -- the more rules you enforce, the more users will find creative ways to generate weak passwords, instead of producing strong passwords. However, the system must still project the idea that strong passwords are important, and a minimal length is, in my view, the best compromise: not too harmful since users are ready to accept such a limitation (they feel that they understand it), and still a good conveyor of the idea that there is such a thing as security. – Tom Leek Jul 13 '15 at 12:35
  • I agree that its best to get users to really grok security, and do it on their own. But the reality shows that the vast majority of users do not. If this was an internal site, I could educate them, but this is a site accessible by the general public, yet still needs to be secure. My only choices are to enforce things, and try to educate as much as I can through the UI hints, while balancing what I think is right, what the law requires, and what the customer demands (and those three constraints often disagree) – Jason Coyne Jul 13 '15 at 13:02
  • @JasonCoyne You're missing the point. Increased restrictions = less secure passwords and password habits. It doesn't matter if the user has a 16 digit randomly generated password that your system made for him if he just writes it down and sticks it on his desk. – DanielST Jul 14 '15 at 14:32
  • 1
    @TonyEnnis Unfortunately "Educating users" is number 5 on the list of bad strategies http://www.ranum.com/security/computer_security/editorials/dumb/ – Murphy Jul 15 '15 at 14:40
  • @Murphy That list is hardly authoritative. It also doesn't appear that the author understands much about operating systems either, with statements such as "I still don't understand why operating systems are so dumb that they let any old virus or piece of spyware execute without even asking me." – Fax Feb 02 '21 at 11:50
  • @Fax some systems will only run signed code and/or restrict permissions by program rather than by user. It tends to make it much harder to turn such into virus infested botnet nodes. – Murphy Feb 03 '21 at 12:47
  • @Murphy Indeed, that is a much better solution than asking the user. – Fax Feb 04 '21 at 09:48
  • @Fax If you look at an android phone, asking the user is indeed the norm. Apps run not only with the users level of permissions but also for a list of individual permissions like access to files or ability to access certain hardware the app has to get the permission of the user. – Murphy Mar 10 '21 at 15:12
68

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

Michael
  • 2,432
  • 2
  • 20
  • 37
Adam Katz
  • 10,418
  • 2
  • 22
  • 48
  • 2
    Sorry for the confusion pre-clarification. Excellent answer. While I see the two word problem as real, I'm getting so much pushback at not allowing one word, two word is a non-starter. Babysteps. My goal is to encourage diceware or other passphrases as much as possible through the UI hints. I'm going to add zxcvbn which should at least warn users that the 2 word ones are weak. – Jason Coyne Jul 10 '15 at 20:27
  • 28
    It's vastly more important that you throttle password attempts. I assume you're doing this: 5 failures in 5 minutes from the same IP *or* the same username blocks the IP and/or locks the account). As long as your hash db is never compromised and your throttling is never sidestepped, password strength doesn't matter. Therefore, if you can't improve password strength, improve the security of that hash db. – Adam Katz Jul 10 '15 at 22:40
  • 3
    I am throttling attempts online. there are enough examples of vulnerabilities in OS/DB/SSL etc that having hashes leak is a legitimate concern. With short passwords its reasonable to crack them. Ive proposed to the customer dropping all complexity requirements, but making minimum length 16, we will see how it goes. – Jason Coyne Jul 10 '15 at 23:05
  • Whoa, reject repetition in that case, otherwise you'll get passwords like `asdfasdfasdfasdf` and `hiiiiiiiiiiiiiii`. Controlling for that, you should be fine since all lowercase letters still gives 26^16 which is 75 bits of entropy (equivalent to 11.5 random printable characters) ... or, via a dictionary attack assuming three words, 100k^3 at 49.9 bits, (equivalent to 7.6 chars, though with valid 2 word and 4+ word combos, you're over 9 chars). It's too bad you can't google each phrase to check its popularity (too much risk of information leakage). – Adam Katz Jul 11 '15 at 00:17
  • @JasonCoyne: 16 letters is way too high for the average user. Make it more reasonable (7-8 letters) and use bcrypt with an [extremely high number of rounds](http://security.stackexchange.com/a/83382/1508), if you're that worried about it. That way the general security rests on your shoulders, and can be increased later if necessary without inconveniencing the user. – BlueRaja - Danny Pflughoeft Jul 11 '15 at 05:45
  • 92
    I like how the asker accepted the answer he wanted to hear, and not the answer with more than five times as many votes. – Kevin Krumwiede Jul 11 '15 at 06:23
  • 4
    @KevinKrumwiede Although I could have been more clear in my question as to what I was asking, I accepted the answer that most directly answered my question. I was not asking about password rules or security practices in general. I was asking specifically about the dictionary lookup issue and leetspeak. (As I said, I could have made that more obvious in the question originally) – Jason Coyne Jul 11 '15 at 12:46
  • @BlueRaja-DannyPflughoeft Im using PBKDF2 due to FIPS certification issues, but the concept is the same. I am using very high rounds, but doubling the rounds adds the same complexity to a cracker as a single additional bit of password complexity. a length of 8 with no other significant complexity rules will have the password cracked very easily. People will absolutely use passwords that are easily crackable, even with slow hashing. – Jason Coyne Jul 11 '15 at 12:51
  • 1
    @AdamKatz Lockouts make a trivial denial of service attack for anyone who knows a username. – David Richerby Jul 11 '15 at 15:02
  • @JasonCoyne: I challenge your claim that *"a length of 8 [..] will have the password cracked very easily."* Say the user uses only upper- and -lower-case letters, no numbers or special characters. And say your PBKDF2 is set up so the server takes 0.3s to hash one password. And say the attackers have a botnet 1000x more powerful than your server. Then it will still take an attacker over an expected 250 years to brute-force that one user's password. Since you are salting, that's 250 years **per user**. – BlueRaja - Danny Pflughoeft Jul 11 '15 at 18:27
  • 1
    @BlueRaja-DannyPflughoeft For a RANDOM 8 char password, you are correct. But we know for a fact that users pick really bad passwords. The leetspeak passwords have an entropy of ~25 bits. in your scenario, where its just letters, a very high percentage of passwords are likely to just be words. Lets be GENEROUS and say between the vocab of average users(~10-20k), and the tad bit entropy/caps/numbers they will use its 50k-100k combinations. 100K x .3s = 8.3 hours and on average you would get a password half way through. And thats not even accounting for the botnet. – Jason Coyne Jul 11 '15 at 19:33
  • 1
    For the leetspeak ones 25 bits would give you 4.5 years average per password, before the botnet. Assuming the botnet, ~1.5 days – Jason Coyne Jul 11 '15 at 19:39
  • 1
    both of these times (~4 hours, ~4.5 years) ignore the fact that good crackers would try words/combinations in frequency order, and would likely crack things much earlier for most users. – Jason Coyne Jul 11 '15 at 19:47
  • @DavidRicherby Yes they do. It's what banks do, too. Otherwise, a botnet can brute force an account credentials. – Adam Katz Jul 11 '15 at 20:09
  • My lockout is for 10 min, which is enough to stop the online bruteforce, but not enough to permanently keep the user out (unless the botnet is dedicated to keeping it going) – Jason Coyne Jul 12 '15 at 00:06
  • 1
    @KevinKrumwiede That's why the mechanisms are independent. The OP can (and should) choose whatever best answers *their particular question.* The community voting decides what is best *for the history records and future visitors.* – Angew is no longer proud of SO Jul 13 '15 at 08:05
  • @Angew Not really, as the accepted answer is hoisted to the top. Most folks don't bother to scroll down to the second answer. I know I wasn't going to until I saw Kevin's comment. – nick Jul 13 '15 at 21:51
  • 1
    Disallowing any certain _"type"_ of password is silly and downright annoying without giving you any actual benefit. – Etheryte Jul 14 '15 at 01:36
  • 1
    @DavidRicherby, agreed. Lockouts are unacceptable. Even a 10 minute lockout could effectively lock a real user out of their account if someone writes a script to keep sending requests every 10 minutes. It's more than sufficient to just add a slight delay. Sleeping for a short period of time is an acceptable delay to a human, but makes brute forcing almost impossible. – Kat Jul 14 '15 at 20:30
  • the lockout is required by law in this case, so no choice. – Jason Coyne Jul 15 '15 at 03:07
  • 1
    @AdamKatz Great update to your post. 2 issue. 1) Troubador is really spelled Troubadour, that might put it into your small dictionary. 2) I think you might be significantly underestimating PKDBF2 hash speeds on GPUs. The 1 password guys estimate it at 1M/s https://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/ Thats actually the same article linked in that SO answer you linked to, but they didnt see the GPU estimate – Jason Coyne Jul 15 '15 at 20:45
  • @JasonCoyne **1)** Correct, `Troubadour` appears in all dictionaries, including the std 100k word dictionary, while `Troubador` is only in the lg 650k and wikipedia dictionaries. If you were to dub the latter a misspelling, it'd fit in the std+mispellings (100k * 6) dictionary and its entropy would drop mildly. **2)** Nice catch, but the 1M/s figure refers to 1k iterations, not 10k. Assuming iteration complexity is linear, 10k iterations would be 400k/s (still 4000x the SO answer). I can update my table and findings w.r.t. that. – Adam Katz Jul 15 '15 at 21:57
  • @JasonCoyne 1. lockout by IP, not by user (seems obvious) 2. detecting leet-style passwords specifically to *remove* them from the password space. Counterproductive. I'm a newb but the evidence here strongly suggests you accepted the wrong answer. – Steven Lu Jul 16 '15 at 06:43
  • @StevenLu Yes, it removes them from the password space. So does any kind of password complexity restriction at all. But the passwords that remain are ones that require exhaustive search vs ones that will be caught in rule based attacks in a few hours/days – Jason Coyne Jul 16 '15 at 14:27
  • Look.... `Tr0ub4dor&3` is a *superior* password to `Troubadore` or `Troubadour` or what have you. There's no point beating the dead horse because the other answer with 5x more upvotes already went over it better than I could. Think about how _this_ answer failed to use any logic to connect the recommendation to cull the leet-passwords. No convincing reason was given. There was a bunch of neat looking information (which I have no doubt is accurate). But the conclusion of the answer is a non sequitur. – Steven Lu Jul 16 '15 at 21:18
  • "If six random characters is too weak, you should disallow 'leetspeak' dictionary passwords." You have just reduced the entropy here (if the user continues with the word they have in mind) by a few more bits. That's counterproductive... Someone a bit more knowledgeable might use a password akin to "correct horse battery staple". But you cannot argue to me with a straight face that "C0rr3ct hOr5E b4773|2Y sT4P1e" is a worse password. It is a far, far superior password. – Steven Lu Jul 16 '15 at 21:19
  • @StevenLu - I never claimed that. I said that the complexity of a word in leetspeak form increases by 64, which is insufficient for a *single* leetspeak word (22.6b entropy, 3.4 chars) to serve as a complete password. c-h-b-s has 66.4b entropy (10.1 chars) while leet(c-h-b-s) has a higher 90.4b entropy (13.8 chars). – Adam Katz Jul 16 '15 at 22:02
  • @StevenLu reread the last sentence of the first paragraph. the leetcheck is only because they are so weak for SHORT passwords. In passphrases I do not care about leet. – Jason Coyne Jul 17 '15 at 03:02
  • Ok. My apologies for doing a bit too much skimming last night. I take it you already are checking against a dictionary for short pass*words* and your question's about where to *draw the line*. Seems to me at this level of sophistication you might as well engage in a number-theoretic entropy calculation (on the client?) using the provided password/phrase. Not sure how practical that could be nor how to really reconcile/combine that with the result of testing against the dictionary. But it would help obtain an entropy characterization from which to make a go/no-go decision. – Steven Lu Jul 17 '15 at 05:22
  • Not sure if it helps but sometimes when I write questions that grow rather large I would re-iterate the main question-nugget by repeating it and writing it out in bold. – Steven Lu Jul 17 '15 at 05:23
  • 1
    I have updated the table to use 1M pw/sec for PBKDF2 at 10k iterations. I'm not sure about >64bit counts though, they may be much higher. – Adam Katz Jul 23 '15 at 02:22
  • @AdamKatz Throttling login attempts is important, but not vastly so. The majority of passwords are compromised in offline attacks. Locking out accounts is completely unnecessary if you follow the current NIST guidelines. – Fax Mar 11 '21 at 12:13
  • @Fax – Yes, throttling is a good _secondary_ protection. I didn't mean to suggest that throttling is more important than password complexity but rather that practical complexity guidelines have their limits. As I said, “if you can't improve password strength, improve the security of that hash db.” – Adam Katz Mar 11 '21 at 16:29
23

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")
Cort Ammon
  • 9,216
  • 3
  • 26
  • 26
  • 2
    So what about people writing down their password in their day planners? To get access to those someone has to gain undisturbed access to the work place. If you're able to do that it's game over - it takes less time to install a keylogger (hardware not software if we want to be quick) than to find a password in a day planner. This is rule 101 of computer security: If the hardware is compromised you've lost. For most workplaces writing down passwords is a great option and probably about as safe as one can get. – Voo Jul 12 '15 at 16:06
  • @Voo it definitely calls for understanding your threat model. However, there are many cases where the place the password is written down (i.e. dayplanner) leaves the protected workplace. If you write all your passwords down, put them in a safe, and protect the safe password at the level of your most valuable password, it's a very safe approach. – Cort Ammon Jul 12 '15 at 19:09
  • *mistyped* Should have been "If you write all your passwords down, put them in a safe, and protect the safe at the level of your most valuable password, it's a very safe approach." – Cort Ammon Jul 12 '15 at 19:28
  • @Cort Definitely. It's not the right option in every situation (and it really depends how you do it as you point out). I just find that it gets bashed way too often and for the wrong reasons, since for many practical purposes it's the best security your layman will be able to achieve. – Voo Jul 12 '15 at 20:36
  • @Voo That is true, it does get bashed too often. I think I bash it because it seems so easy to just add another password rule. I've worked on some ASININE password systems in my life (I still slander the name of the IT fool who set up a system which required passwords changed every 60 days, at least one number but it won't count numbers at the end, mixed case but the first character wont count as a capital, can't be a dictionary word or l33t'd word, and wouldn't allow obvious keyboard aptterns... – Cort Ammon Jul 12 '15 at 21:10
  • ... but then had a 8 character MAXIMUM because the underlying software wouldn't take more than that) – Cort Ammon Jul 12 '15 at 21:12
  • At my previous company, I wrote all my passwords in my day planner. I had about 10 passwords to remember, all changing on unrelated schedules, and of course no central password repository. The passwords I wrote down were lightly encrypted. If my password was "bluecolt" for example, I wrote down "b45". – Tony Ennis Jul 13 '15 at 22:46
10

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

Community
  • 1
ztk
  • 2,247
  • 13
  • 22
  • 1
    For the most secure data we also have 2FA. I guess I AM worried about brute forcing. Even with PBKDF2 if users have crappy passwords, they are likely to occur in the fist 10k-100k guesses which is a short amount of time. I want people to use the passphrases, which I am not worried about. But if they aren't going to use them, then I want to stop John/hashcat from getting it in the easy rulesets. – Jason Coyne Jul 10 '15 at 18:30
  • 1
    Humans don't do complex passwords very well, so don't force them. Can you encourage a password manager like Lastpass? It would put complex passwords in your system without driving users crazy. – ztk Jul 10 '15 at 18:34
  • 1
    Well, my goal is to force diceware style passwords. They won't let me make the rule be "Must be 16+ chars" and end there, so for the shorter stuff, I'm trying to keep it secure. I put a link to keepass and makemeapassword.org in my UI, and they complained about linking to external sites :( – Jason Coyne Jul 10 '15 at 18:36
  • The complexity won't lead to better security, just frustrated users creating obvious password that minimally pass the rules. the numbers will always be 123, and the symbols !@#. Also, instead of linking to an external site, add a box in the UI with suggestions about creating strong passwords and refer to diceware and password generator sites without using a URL. – ztk Jul 10 '15 at 18:48
  • 3
    I'd also suggest blocking the 1,000 or so most common passwords. – Stephen Touset Jul 10 '15 at 18:50
  • The bottom portion of my OP is essentially the UI from the password screen. It has the rules, and the suggestions. What is the fastest/mostpainless way to educate people who are used to Tr0ubad0r&3 to correct horse battery staple tho? – Jason Coyne Jul 10 '15 at 18:50
  • 1
    There is no fast or painless way. The users don't want to be educated, most of them are quite educated already in things that matter to them. They want to log in and get to work. – ztk Jul 10 '15 at 18:54
  • your original answer is true, but both as an individual, as an employee of a consulting company, and as the agency who owns the site, CYA/liability are real concerns. As you rightly point out, one can never plug all the holes, one can merely move the most vulnerable vector to somewhere else. But moving the most vulnerable vector to a place outside of our control still saves us from getting sued. As stated in some of the other comments, we are using 2factor for the most sensitive data, but that doesn't mean I want to leave the doors open wide for the users who aren't forced to use TFA – Jason Coyne Jul 12 '15 at 00:11
6

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

Adam Katz
  • 10,418
  • 2
  • 22
  • 48
  • 1
    Too many users to use client certs. 2 factor is required for the most secure data, but thats a relatively small percent of the total users. If they use a diceware style password, all the rules are ignored.I could make the miniumum 9 without problems probably, but that doesnt really address the core of the question : Is disallowing leetspeak dictionary words like XKCD's too severe? – Jason Coyne Jul 10 '15 at 18:43
  • (my response has been moved to another answer) – Adam Katz Jul 10 '15 at 20:14
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.

Vincent
  • 201
  • 1
  • 3
  • I was perhaps unclear in my question wording. My intent was essentially as you mean it. It wasn't really disallow leetspeak, but rather in the rule that disallows single dictionary words, should I detect leetspeak. If you are using a multiple word passphrase and happen to leetify some of the words, thats fine. – Jason Coyne Jul 14 '15 at 16:09
2

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.

Loren Pechtel
  • 773
  • 4
  • 9
  • I've proposed something like this too to the customer. Stanford's policy is very similar. https://itservices.stanford.edu/service/accounts/passwords/quickguide But this doesn't answer the question as to for the short "complex" passwords, should words still be disallowed. the other problem with this solution, is that part of the problem is complexity/communication. while this allows for graduated complexity, explaining that to the user is even more complex (something that my customer complained about even for my "2 level" complexity rules. :) – Jason Coyne Jul 12 '15 at 13:16
  • I'm saying that a leet-speak "word" is basically dictionary + some complexity and should be scored accordingly. That Stanford policy is a simplified version of what I'm saying. – Loren Pechtel Jul 12 '15 at 19:17
2

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

basic6
  • 211
  • 3
  • 8
2

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.

berto
  • 121
  • 3
2

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.

Atsby
  • 1,118
  • 8
  • 6
  • You could try to "break" the unencrypted password perhaps; a couple seconds of that should be equivalent to a healthy amount of time trying to crack a sane password hash. Not sure if it's easier to pre-generate (ten/hundreds? of) millions of passwords and do a lookup or try to recreate them dynamically. – Nick T Jul 26 '17 at 16:31
0

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.

JDługosz
  • 1,139
  • 2
  • 7
  • 12
  • We do encourage such, but its not something you can enforce obviously. But that only solves them remembering the password, doesn't address what complexity/rules that password has. – Jason Coyne Jul 14 '15 at 14:27