This is an old revision of the document!

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 mitigated. If we make the password policy less restrictive, we'll be a lot more vulnerable to #1 while maybe mitigating #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 mitigate 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 time for and cost of recovery from a compromise).

Back to passwdqc resources.

passwdqc/policy.1298260141.txt · Last modified: 2011/02/20 19:49 by solar
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate to DokuWiki Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Powered by OpenVZ Powered by Openwall GNU/*/Linux