Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ