[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_passwdqc wordlist .vs. cracklib word list



On Fri, Jun 07, 2002 at 05:30:51PM +1000, John Warburton wrote:
> I have been looking at PAM modules to ensure good passwords. Currently we
> use cracklib with PAM & a huge dictionary.
> 
> I have looked around & seen Solar Designer's pam_passwdqc as a drop in
> replacement. I have seen comments on the list saying that it will replace
> cracklib.
> 
> My question is that cracklib has a huge dictionary & I can add to it. But,
> pam_passwdqc has a small dictionary in wordset_4k.c (it doesn't even have
> the word "snoopy" ;-) I don't feel as safe with pam_passwdqc as it has a
> small dictionary, yet Solar Designer really has it in for libcrack, and I
> respect Solar Designer's opinion. The function is_word_based() in
> passwdqc_check.c states that the dictionary check is not very important -
> how true is that?
> 
> Can anyone shed any light on my quandary?

I'm not sure you wanted to hear my opinion again, but I may try to
explain why I think the wordlist check in pam_passwdqc is of little
importance.  The "small dictionary" you're referring to is in fact
primarily used for generating random passphrases (one of the features
of pam_passwdqc) and, yes, is also used for a wordlist check.  Just
because it's there anyway.

Basically, if you allow short passwords (and not just passphrases),
you have to insist that a sufficient number of different characters
from several different character classes are used.  That is regardless
of whether the password is based on a dictionary word or not.  Even if
it is not word-based, it shouldn't fall into a common sub-keyspace
that is fairly easy to search.  Once you do add this requirement, your
passwords won't be crackable by simple wordlist runs that don't use
word mangling rules.  And with default pam_passwdqc settings such
mangling rules would need to be quite heavy (that is, multiple kinds
of mangling applied at once) in order to catch possible word-based
passwords that could have passed the checks.  Now, for an attacker,
the choice is between using such word mangling rule sets and using
character frequency tables.  As you increase wordlist size and number
of word mangling rules, the latter approach is starting to become more
effective, -- and it doesn't care whether the passwords are word-based
at all!

Then, no matter how big your wordlist is, it _will_ miss strings found
in another wordlist (one an attacker might be using).  It will also
miss word-like strings which aren't dictionary words but which are
easily cracked by utilizing frequency tables (such as those John the
Ripper places in .chr files).

In practice, I've seen many times more weak (cracked) passwords that
have passed CrackLib checks than those that have passed pam_passwdqc.

Having that said, I agree that adding support for big wordlists into
pam_passwdqc would be an improvement.  This is on TODO, but with a low
priority.

pam_passwdqc's is_based() check is quite different from what CrackLib
does, -- and it has to be different in order to reasonably handle
longer passwords which may still be strong enough despite containing a
dictionary word.  What pam_passwdqc does is ensure that the password
with the weak substring removed would still pass the remaining checks.

-- 
/sd





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []