Summary of password strength discussion

[Matthew Miller]

On Thu, Jul 23, 2015 at 11:55:47AM -0500, Michael Catanzaro wrote:
> 4) Our requirements for local password strength will allow passwords
> that would be much too weak were remote access via SSH to be enabled.
> We should have some user interaction when enabling SSH in the Sharing
> panel to force the user to pick a much stronger password.

How would this work when there are multiple users on the system? Would
they all need to pick new passwords at this point?

For that matter, how do you know that the original passwords weren't
already strong enough?

> We still need more effort to define what should be acceptable
> passwords. One possibility: "Examples of acceptable passwords include
> 'berlin,' 'wombat,' and 'butter.' Any of these would work great at
> keeping out a human typing on the keyboard." This implies that we
> disable pwquality's use of cracklib in the pwquality configuration
> file, and reduce the minimum acceptable characters down as far as
> pwquality allows (6, I think).

I didn't look at the code, but I was just playing with libpwquality a
little bit, and it appears that a number of basic checks, like looking
for palindromes, are actually disabled as part of disabling dictionary
checks. That may or may not be what you want. An alternative to
disabling dictionary checks would be to use a smaller dictionary -
still restricting password, 123456, qwerty, and the like (I think it's
reasonably argued that these would not be "great" at keeping out a
human typing on they keyboard).

> Keep in mind that we've established that pwquality is not very good at
> rating password strength.

Sorry if this was already discussed while I was on vacation. There's a
nice NIST paper on this topic:
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf>
For what it's worth, the basic guidelines you suggest seem in line with
those recommended for what the government describes as "level 1
identity assurance", which is appropriate for low-risk situations.

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader