[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <473c394a-57de-2dc2-50f9-2124829b863f@bluepopcorn.net>
Date: Mon, 30 Oct 2017 14:06:31 -0700
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies
On 10/29/2017 03:41 PM, Royce Williams wrote:
> On Sun, Oct 29, 2017 at 3:32 PM, Solar Designer <solar@...nwall.com
> <mailto:solar@...nwall.com>> wrote:
>
> That's my tentative plan for passwdqc 2.0. Not so much for processing
> and shipping a password cracker output, although that can be done, but
> rather to take advantage of the recent (and not so recent)
> availability
> of large password leaks, widespread acceptance of their use for the
> purpose, and to be consistent with the new NIST guidelines.
>
> The 320 million SHA-1 hashes of leaked passwords (without even
> re-cracking them first, although folks did that) from
> https://haveibeenpwned.com/Passwords
> <https://haveibeenpwned.com/Passwords> would comfortably fit in an
> 8 GiB Bloom filter with negligible false positive rate and nearly
> instant checks.
>
>
> I'm pretty sure that the new NIST guidance was intended to encompass
> blacklists on the order of Dropbox's zxcvbn or similar, not a
> blacklist of such colossal size as the HIBP 320M.
>
> From a usability standpoint, and taken in isolation, such a blacklist
> is completely untenable. It would result in a never-ending "gotcha"
> guessing game of "nope, not that one" for the user.
>
> And even if NIST did intend this, such guidance would be ...
> misguided. Fully 80% of the HIBP 320M list can be eliminated entirely
> by simply requiring passwords of a length greater than 12. Such a
> limit would also eliminate millions of other equally poor future
> passwords - passwords that would otherwise eventually find their way
> into such a monstrous, ever-growing blacklist.
There is definitely a tradeoff between blacklist size and user
frustration--a blacklist that is too long is even worse than a complex
set of composition rules, because you can't predict what will be
acceptable and what won't.
At PasswordsCon Las Vegas 2016, I mused a bit on blacklist size and
arrived at 100k as a rough order of magnitude for a reasonable
blacklist. That may even be a little big, since the idea is to eliminate
the passwords that are vulnerable to online guessing (with rate
limiting).
https://www.slideshare.net/jim_fenton/toward-better-password-requirements
The approach is different for offline attacks: in addition to salting
and iterated hashing with an expensive key derivation function, SP
800-63B recommends an additional keyed hash with the key stored
separately (as in an HSM, or on a separate machine not otherwise
accessible). So if the verifier can keep the key secret, the hashes
aren't usable by password cracking at all.
Additional guidelines on the size and composition of blacklists is
planned for the implementation guide that is a companion to SP 800-63B,
currently under development.
-Jim
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.
