Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 10 down vote accepted

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 lost 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 without guile) side with 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.

share|improve this answer
    
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 Feb 12 '13 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. –  Thomas Pornin Feb 12 '13 at 17:26
    
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 Feb 12 '13 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. –  Stephen Touset Jul 16 '13 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).

share|improve this answer
    
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 Feb 1 '13 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 Feb 1 '13 at 21:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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