Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 23 Nov 2015 07:05:26 -0500
From: Rich Rumble <richrumble@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Aggressive password policy math

On Sun, Nov 22, 2015 at 11:45 PM, Solar Designer <solar@...nwall.com> wrote:
> 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%.
That should be lower, at length 8. I didn't include numeric/digit!
Doh! It should be
Policy-1 = d/l/U/s no chr_x, and no repeats over 2.
Policy-2 should be d/l/U/s and no repeats of any chr together (case
sensitive however, again Aa works)
So if 6634204312890625 (100%) becomes 3025989069143040 (100/46) at
length 8 when requiring the 4 standard policies I'd think you'd reduce
it even further. 94*92^7 = 5243758051622912 (5.2 quadrillion) and down
another 46% is 2412128703746539 (2.4 quad)
That's .3635 (2412128703746539 / 6634204312890625) that's more
significant at length 8! I hope I did that right...

> 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.
I agree on the effectiveness. And I wonder how those stats fall apart
further when you use real user's passwords, the 36% is "best case",
once your start to throw hundreds of user chosen passwords in there,
that number is going to get a lot worse :)
-rich

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.