[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151123044550.GA4303@openwall.com>
Date: Mon, 23 Nov 2015 07:45:50 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Aggressive password policy math
On Sun, Nov 22, 2015 at 09:34:54PM -0500, Rich Rumble wrote:
> I reference and use the http://openwall.info/wiki/john/policy (Effect
> of password policies on keyspace reduction) page all the time. I'm
> unsure how to do the math in some aggressive policies I've seen in
> other's networks.
> I don't know C or Python so I'm unsure, and I can't math, so I'm
> unsure how to alter the values in the code provided on the page to
> compute the outcomes.
> Here are two I've seen:
> ---Policy-1---
> Pass-min=8
> Alpha-min=2 (makes the next rules redundant)
> Upper-min=1
> Lower-min=1
> Must-not=$ (can't have this character at all) (makes this 94 vs 95 possible)
> No-repeat-chr=2 (case insensitive, hHh, TTt won't work)
> Policy-2
> Pass-min=8
> Alpha-min=2 (makes the next rules semi redundant)
> Upper-min=1
> Lower-min=1
> No-reapeat-chr=1 (case-sensitive, Aa will work!)
It's the other way around with the redundancies: the requirements on
uppers and lowers make the requirement on alpha redundant.
> Weird policies and weird software enforcing them :)
> Obviously it's the weird repeating patterns that are the most
> troublesome for me.
Yes, they are in fact non-trivial to accurately account for, but you can
estimate the keyspace reduction as small given that at most 1 or 2
characters (same as previous character) are excluded per position (and
nothing is excluded for the very first position). It's no worse than
having 92 characters total (for the first policy) instead of 95.
92^8/95^8 is 77.36%. The table gives 84.69% for 8 0/1/1/0. Multiplying
these percentages, you get 77.36*84.69/100 = 65.5%. This is your lower
boundary for the keyspace size (relative to policy-less). The actual
size is slightly larger than that.
We can arrive at a more accurate estimate (and higher lower boundary) by
accounting for the very first character separately: use 94*92^7 in place
of 92^8. That's 79.04%, and this gives 79.04*84.69/100 = 66.9%.
Overall, these policies don't look too bad to me in terms of keyspace
reduction. They're worse in terms of not being very effective.
Alexander
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.
