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.