Differences

This shows you the differences between two versions of the page.

Link to this comparison view

passwdqc:policy [2011/02/20 19: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/20 19: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.
passwdqc/policy.txt ยท Last modified: 2011/02/20 19:51 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