Date: Sun, 29 Oct 2017 16:41:57 -0600
From: Royce Williams <royce@...hsolvency.com>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies
On Sun, Oct 29, 2017 at 3:32 PM, Solar Designer <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 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.
Now, if the plans for passwdqc 2.0 could include working that length
restriction into its parameters ... that might be an interesting
compromise, and dramatically decrease the size of the required blacklist,
and still remaining NIST-"compatible".
Royce
Content of type "text/html" skipped