If my experience with folding CrackLib-2.5 into the CSO Nameserver package
is any guide, adding the Crack rules makes a password checker too strict with
insufficient feedback to the user. Passwords that were the first letter of
words in a random phrase would be rejected as being derived from a dictionary
word. Which word? What derivative operation? Unless the user has a clue
as to why a nonsense password is rejected, they can't be expected to choose
"better" ones.
My chief objection to CrackLib was that the rules were not spelled out in
a easily understood manner. To make such a proactive password checker
acceptable, the rules must be configurable. Rules that catch 90% of the
passwords (or 98%, 99%, 99.985%, etc) are what's needed. If I know that
the last 1% of the passwords require an additional 50 CPU hours to find,
then 99% is fine with me.
For me npasswd is part of an indepth defense. First someone has to get
a copy of my shadow password files before they can run crack. Ideally
what npasswd does for me is eliminate easily guessed passwords. For that
the 90% level is fine and eliminates most user resistance.
/pbp
Follow-Ups:
|
|
