## From http://openwall.info/wiki/passwdqc/policy
# 2010.03.15.1510
#
Password strength policy considerations
Many system administrators are tempted to relax passwdqc's default policy
settings in order to make it easier for the users to choose and remember
passwords that would pass the policy. Unfortunately, this very likely results
in unacceptably weak passwords being allowed. The following excerpt from an
e-mail exchange between a user of passwdqc (a system administrator) and Solar
Designer (the original author and a maintainer of passwdqc) explains some of
these issues.
â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”
I appreciate what passwdqc is, but I think that the default minima are too
restrictive […] If the system enforced too restrictive passwords, users are
forced to write them down on paper.
This is not necessarily such a bad thing. It depends on what threats we
primarily protect against. Off the top of my head, I can identify the following
relevant threat classes:
1. Offline attacks against stolen/leaked password hashes.
2. Online attacks against remote systems. (Also similar attacks against
not-so-remote systems in some cases.)
3. Leaks of plaintext passwords from the users.
Your concern above is about #3, whereas #1 and #2 are avoided. If we make the
password policy less restrictive, we'll be a lot more vulnerable to #1 while
maybe avoiding #3 in some cases. Please note that with #1, the attack is
usually system-wide (a certain large percentage of accounts may get compromised
- say, 20% - and this would be difficult to recover from on a large system).
For comparison, with #3 the attack is per-person, so a much smaller percentage
of accounts gets compromised. Also, in some cases it's about “formalâ€
responsibility - for #1 it is the system admins', for #3 it is the specific
user's (even if the system admins were “at fault†for enforcing “too strict†a
policy).
Also, you might be over-estimating the difficulty of memorizing passphrases
that pass the default requirements of passwdqc. I have lots of those memorized.
Over the last years, I have thus used the following settings:
min=disabled,12,8,6,5 enforce=users
These might protect against #2 (although length 5 feels too low even for remote
attacks), but definitely not against #1. I'd call these unreasonable for most
systems and typical threat models (based on my experience).
while the defaults are
min=disabled,24,11,8,7 enforce=everyone
While the enforce option is surely a policy decision, I would like to hear
your opinion on the minima strengths. I think that the ones you chose are
possibly a bit too strong.
passwdqc's default requirements are about the minimum needed to prevent
not-too-powerful offline attacks.
I see no way to relax the requirements yet have much protection against offline
attacks, which are a primary concern for systems with large numbers of users
(because of the cost of recovery from a compromise).
passwdqc/policy.txt · Last modified: 2010/03/15 20:32 by solar