[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
