Banning specific passwords?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.