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


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


  • At least eight characters

  • Contain three of the following
    • 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)
  • 87
    I'm a little surprised you dont have a hard-coded rule blocking correct horse battery staple Commented Jul 10, 2015 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
    Commented Jul 11, 2015 at 8: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. Commented Jul 11, 2015 at 23:08
  • 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
    Commented Jul 15, 2015 at 13:07
  • 4
    @Tony Yes, that's one hell of a leak. Go ahead and post that on TheDailyWTF
    – Navin
    Commented Jul 16, 2015 at 4:50

11 Answers 11


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

Dictionary Count Bit
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.

  • 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. Commented Jul 10, 2015 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
    Commented Jul 10, 2015 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. Commented Jul 10, 2015 at 23:05
  • 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. Commented Jul 11, 2015 at 6: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) Commented Jul 11, 2015 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).

  • 29
    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
    Commented Jul 10, 2015 at 19:14
  • 22
    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
    Commented Jul 10, 2015 at 22:10
  • 13
    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
    Commented Jul 11, 2015 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
    Commented Jul 11, 2015 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
    Commented Jul 12, 2015 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")
  • 3
    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
    Commented Jul 12, 2015 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
    Commented Jul 12, 2015 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
    Commented Jul 12, 2015 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
    Commented Jul 12, 2015 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
    Commented Jul 12, 2015 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. Commented Jul 10, 2015 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
    Commented Jul 10, 2015 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 :( Commented Jul 10, 2015 at 18:36
  • 4
    I'd also suggest blocking the 1,000 or so most common passwords. Commented Jul 10, 2015 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
    Commented Jul 10, 2015 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? Commented Jul 10, 2015 at 18:43
  • (my response has been moved to another answer)
    – Adam Katz
    Commented Jul 10, 2015 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. Commented Jul 14, 2015 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. :) Commented Jul 12, 2015 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. Commented Jul 12, 2015 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).


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
    Commented Jul 26, 2017 at 16:31

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:


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.


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. Commented Jul 14, 2015 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .