Index: passwdqc/password-strength.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ passwdqc/password-strength.txt	2010-03-16 15:21:07.370060152 +0100
@@ -0,0 +1,66 @@
+## 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
