There have been a couple of questions about enforcing good passwords, so I thought I'd add my own:

In addition to enforcing a minimum Shannon entropy, would it generally be a good practice to prohibit the use of specific passwords or elements outright, based on criteria such as:

  • Appeared at least once on SplashData's "Top 25" list ("password", "letmein", "qwerty")
  • Publicly famous proper name ("parishilton", "hasselhoff")
  • "Interesting" in the field of IT security ("correcthorsebatterystaple", "orpheanbeholderscrydoubt")
  • Any password previously used in our system and known to have been compromised
  • etc.

These are obviously all really bad choices for passwords, and yet at least the first category is bad because they're so commonly used. The lesson is obvious; don't let your users use these bad passwords.

It would be trivial to take a submitted password, strip spaces and convert all letters to lowercase, and then run a "contains" comparison with the blacklist items, subverting attempts to add entropy using spaces, capitalization, or adding additional letters/numbers. It would be a little harder, not impossible, to detect letter substitutions (perhaps a minimum Levenshtein distance). It would also be easy to store the reason why the entry is banned, and return it to the user, encouraging them to try something substantially different and hopefully more unpredictable (though such a specific reason for rejection could provide too much information if the "user" is an attacker).

Good in theory? What problems might you foresee in practice?

  • When a website does so, users may end up writing down the password on a piece of paper (or even just leave the website) instead of storing it in a password storer. Attacks from around the world might then be harder, but attacks from physically-neaby-people would be easier. Note that this can be extended by building up a dictionary, and forbidding passwords that are less than X combinations of dictionary's words. I would instead show a "password strength indicator" to user, and let them use a weak one if they really want.
    – Xenos
    Commented Apr 5, 2017 at 16:09
  • Worth noting: Microsoft decided to do this. Commented Apr 1 at 21:05

3 Answers 3


The theory is that you would like to run the same tools as the attacker. The attacker will run a list of "probable passwords" based on what he knows or guesses of the psychology of the users. John the Ripper is a well-known password cracking software which includes lots of "usual passwords" and rules commonly employed by users to derive witty passwords.

Your advantage is that the server code has access to the password itself when the user registered. Contrary to the attacker who must run each guess through a potentially expensive hashing process (and it can be heavy if you crank the bcrypt iteration count to its full power), your code can work on the actual stuff and do some optimizations such as, as you suggest, normalization to lowercase.

However I think this is not a very good idea on a general basis. The attacker is not restricted to openly available software; he can adjust his list of potential passwords to the actual target (e.g. using more derivations around the names of the children of the specific user whose password is under the fire of the attacker). Even keeping up with the list of "common weak passwords" is likely to be a tiresome process. Moreover, the user himself will enter the game: since password restrictions are felt as an irksome hindrance by users, they will use all their creativity to find even wittier password generation rules which evade your tests.

Enforcing complex password exclusion rules on the server is somehow fighting the attacker on his battleground, and will bring the user to the feast; the user may unfortunately (and unintentionally) help the attacker.

Therefore, I would recommend against such rules. What you need is the collaboration of the user, and you will have it by being transparent about the rules you employ; the user must be able to find a password which "passes your test" without entering a trial-and-error process. Nothing is more annoying than choosing ten successive passwords until one is finally accepted by a rigid server. You do not want to annoy the user, because an annoyed user will help attackers (he will not think about it like this, but that's the net effect). Explicit rules ("at least 8 characters, at least 1 digit") are much better for pedagogy.

And, of course, nothing beats proper education and training of users about the dangers of non-random passwords.

  • I guess I agree with the maintenance aspect and the use of more sophisticated cracking tools based on hints more tailored to the user. This measure was supposed to be a relatively simple guard against low-hanging fruit. Would a more descriptive error message about why the password was rejected help obviate the concerns with user frustration?
    – KeithS
    Commented Feb 12, 2013 at 16:39
  • Knowing why a password was rejected is certainly better, from the user point of view, than getting his password rejected without any explanation. Yet, knowing the rules in advance is even better. Commented Feb 12, 2013 at 17:26
  • 1
    True. This could also be explicitly stated in advance as the rule "the password cannot consist of or contain any of the terms on the 'banned list'", providing some sort of link that would allow the user to view said list and the reasons words are on that list. I'm just worried that that might actually be going to far in itself, providing information to an attacker that can feed a cracking algorithm ("these strings will not be in the user's password"). But, would those entries really provide much of an advantage, when really all they're doing is removing the obvious ones he'd try first?
    – KeithS
    Commented Feb 12, 2013 at 17:45
  • Given that it's impractical for a user to search the banned list for passwords before creating a new one (especially if the banned list is millions of passwords long), it might be best to simply offer a warning indicating the weakness of the password. If they choose to ignore it, accept the password anyway. Commented Jul 16, 2013 at 23:52

Sounds good in addition to other sane practices (e.g., bcrypt).

I'd use as large of a password blacklist as possible. If your password is in a disclosed list of 100000 passwords (or only different from a password in that list by one or two characters), its a bad password and GPUs can likely defeat it. Its also possible that someone is reusing that password. The only good reason to relax this criterion is if you don't want to frustrate your users who may turn to a competitor that allows weak passwords. (Also to state the obvious, don't use passwords from your own systems to build up this blacklisted password list--that's storing the password in plaintext an big no no.)

Additionally, you may want to create a password suggester feature that always generates a password that passes your criteria and have this pop up whenever a password fails. (Though still require the user to type it twice.)

I'd also make sure that your scheme doesn't inadvertently prevent strong passphrases. E.g., fork scorn loss cope endow yin is a great randomly created diceware passphrase and shouldn't be forbidden if one of the common blacklisted passwords reduced down to fork (and fork is contained within your passphrase).

  • In the context of my specific scenario, I'm writing in-house software to be used by employees; while there are "competitors" for the types of systems I write, we stopped using the primary one a long time ago. Good point for a web app or retail software developer though.
    – KeithS
    Commented Feb 1, 2013 at 21:19
  • The use of words common enough to be blacklisted by themselves in a much stronger password is a legitimate concern; perhaps this could be part of a "soft" analysis and considered in combination with Shannon entropy score.
    – KeithS
    Commented Feb 1, 2013 at 21:21

In fact, Jeff Atwood advocates this exact practice in his blog post: https://blog.codinghorror.com/password-rules-are-bullshit/

In his role with Discourse, he recommended enforcing a minimum length of 10 characters, and then checking for matches with the top 10,000 most popular passwords longer than 10 characters.

See the blog post for some other good recommendations.


You must log in to answer this question.

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