Date: Thu, 7 Apr 2016 20:56:34 -0400 From: Matt Weir <cweir@...edu> To: passwords@...ts.openwall.com Subject: Re: Re: Password creation policies Eugene, Addressing your comments out of order: >> (b) policy creators are ret****d and instead of bottom-limiting the length they attempt to extend the alphabet which is plainly futile. I *strongly* disagree with this statement. You are free to think and say what you want but I'd appreciate it if you kept personal attacks out of this discussion. I've meet and worked with many people who have struggled with creating and implementing password policies. Heck I've been there myself. You can certainly disagree with different approaches but disagreeing with someone doesn't make it acceptable to insult them. Now on to actual password discussions :) >> (a) S.Entropy is based on a GUESS: "the universum of expected outcomes" which is outright irrelevant to our problem. Believe it or not, that's not my issue with Shannon Entropy. Admittedly I'm cool with models which are only an approximation of the real world. Full disclosure I'm currently working on getting a submission approved to submit to the PasswordsVegas conference talking about using probabilistic context free grammars to model human password selection, (Yes, I know, I need to come up with a snappier title ;p). Back on track though, you can totally calculate a fairly accurate Shannon Entropy of password sets and it tracks across different data sets. A quick and easy way to confirm it is to see if Markov based attacks are successful or not, (they are!). My issue is Shannon Entropy is the value isn't directly actionable to someone designing a password policy, or even someone developing a personable strategy. If you want to read more about my reasoning for that, (with graphs!!), please see the following link: http://reusablesec.blogspot.com/2010/10/ccs-paper-part-2-password-entropy.html That being said, I fully understand why NIST went with Shannon Entropy since it at least was an attempt to base defensive policies on perceived attacker strategies. It also was fairly straightforward to design a policy around it, (complexity is a huge negative when designing policies), The challenge is to come up with a better solution which admittedly what this entire thread is dealing with. Matt On Thu, Apr 7, 2016 at 5:37 PM, e@...tmx.net <e@...tmx.net> wrote: > To avoid confusion, let me start by defining what I mean when talking >> about password creation policies vs password creation strategies. >> >> A password creation strategy is an individual's approach to password >> security. It involves their own sense of how to pick a password, where >> to use it, where to store it, etc. >> >> A password creation policy is an organization's rules governing password >> usage. >> > > These are exactly my definitions, I have implied and failed to articulate. > > > To respond to your point, yes policies can be viewed as marketing and >> coercion. Making people wear seat-belts in cars could be classified the >> same way. >> > > Exactly! (by the way, seat-belts should not be enforced as long as the > driver is alone in the car, same with the "P. policies") > > My point is: > The p.policies discussion can not precede p.strategy discussion. > When we are done with defining "password strength", > then we can talk about p.strategy, and only when we figure out a good > strategy, then we can try to build a p.policy on top of it. > > > Rules can be good or bad. Part of the effort to >> make sure they are the least burdensome as possible while achieving >> maximum benefit requires open dialog about them though. >> > > taking in account "state of the art" > the best move here and now is to trash all present p.policies. > quote: > "Shannon Entropy based policies provide no actionable information for the > defender, while being overly burdensome..." [i forgot the rest] > > I only want to add WHY exactly this is the case, > because > (a) S.Entropy is based on a GUESS: "the universum of expected outcomes" > which is outright irrelevant to our problem. > (b) policy creators are retarded and instead of bottom-limiting the length > they attempt to extend the alphabet which is plainly futile. > (all in all they took a wrong measure and failed to implement it) > > -Eugene > Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.