This shows you the differences between two versions of the page.
|
passwdqc:policy [2011/02/21 04:49] solar link to the john-users posting on passwdqc vs. KoreLogic contest passwords; made minor edits to the "e-mail response" (OK, it no longer is, but that style continues to fit this wiki page well) |
passwdqc:policy [2011/02/21 04:51] (current) solar noted that the e-mail excerpt is "revised"; reverted one of the edits to it |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Password strength policy considerations ====== | ====== 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 [[:people/solar|Solar Designer]] (the original author and a maintainer of passwdqc) explains some of these issues. | + | 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 (revised) excerpt from an e-mail exchange between a user of passwdqc (a system administrator) and [[:people/solar|Solar Designer]] (the original author and a maintainer of passwdqc) explains some of these issues. |
| ---- | ---- | ||
| Line 13: | Line 13: | ||
| - Leaks of plaintext passwords from the users. | - 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). | + | 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 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. | Also, you might be over-estimating the difficulty of memorizing passphrases that pass the default requirements of passwdqc. I have lots of those memorized. | ||