Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Oct 2017 22:32:21 +0100
From: Solar Designer <solar@...nwall.com>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies

Arnold,

You must have been reading my thoughts.

On Sun, Oct 29, 2017 at 03:39:07PM -0400, Arnold Reinhold wrote:
> 1. As suggested earlier in this thread, exclude the user's login name, email address, and other personal info that can be easily scraped from public social media and the like from the length calculation. (I would credit each as one letter)

Earlier in this thread, I oversimplified and said passwdqc removes such
substrings, but actually in 2010 I made a commit to "Partially discount
rather than fully remove weak substrings."  (That's the commit message.)
There's no point in removing them fully when a too-short substring of
such a substring wouldn't have triggered the weak substring detection
yet.  Moreover, that would be inconsistent and confusing - would result
in cases when a longer password (with a substring above the detection
threshold) fails the policy check, but a similar shorter one (with a
similar substring truncated to be just below the threshold) passes the
check.  Thus, such substrings just need to be given as much credit as a
just below the threshold substring would be, but not fully removed.

> 2.  Require a password that doesn't crack easily.
[...]
> such testing can be done quite efficiently using a Bloom filter.

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.

Of course, actually installing this Bloom filter on a system will be
optional, or a differently-sized one could be installed.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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