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 of leetness 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 customer/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 the 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 character 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 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)
  • 77
    I'm a little surprised you dont have a hard-coded rule blocking correct horse battery staple – David Grinberg Jul 10 '15 at 20:57
  • 33
    "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 8:26
  • 29
    @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 Jul 11 '15 at 23:08
  • 3
    "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 4:50

11 Answers 11

up vote 58 down vote accepted

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.

  • 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
  • 25
    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
  • 87
    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 6:23
  • 3
    @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

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

  • 25
    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
  • 17
    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
  • 10
    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
  • 10
    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
  • 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

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

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

  • 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
  • 3
    I'd also suggest blocking the 1,000 or so most common passwords. – Stephen Touset 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

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

  • 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

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.

  • 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

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.

  • I've proposed something like this too to the customer. Stanford's policy is very similar. 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

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

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.

  • See my reply in chat. – Jason Coyne Jul 14 '15 at 16:32
  • This seems not to address the question. – Neil Smithline Jul 15 '15 at 4:38
  • @NeilSmithline I do answer the OP's question about whether the restriction is too severe. I do offer quite a lot of additional suggestion/opinion however. – berto Jul 15 '15 at 7:28
  • Yeah. I guess it answers at the beginning. – Neil Smithline Jul 15 '15 at 13:38

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.

  • 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

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.

  • 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

protected by Jeff Ferland Jul 14 '15 at 18:28

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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