Anaconda 22.17+ enforces "good" passwords

[Hubert Kario]

On Wednesday 25 February 2015 10:42:51 Stephen John Smoogen wrote:
> On 25 February 2015 at 06:47, Tomas Mraz <tmraz at redhat.com> wrote:
> > On St, 2015-02-25 at 14:32 +0100, Hubert Kario wrote:
> > > If nobody else is looking at your screen, you can use one of the
> > 
> > following
> > 
> > > random passwords:
> > > red mist
> > > second wanted degree
> > > however ready respect using
> > 
> > I do not think that two random words password from not too big
> > dictionary would be sufficiently strong. You have to understand that the
> > attacker will know which dictionary was used to generate it. And a big
> > dictionary means that the words will be so obscure that people will not
> > be able to memorize them much more easily than randomized single word.
> 
> Could we drop back from the weeds and go back to a core part. How many bits
> of entropy are we wanting to encourage towards passwords? Hubert is saying
> 20 bits, you have another but not expressed. Are we looking for 40 to be
> minimal? 90? 400?

Talking about entropy without talking about how severe will be the rate 
limiting or password lifetimes will also lead us nowhere.

I chose 20 only to show that passwords that look complex aren't while the ones 
that don't look complex are much more secure.

If we use the NIST recommendation of 100 unsuccessful login attempts to 
lockout account and 30 day password rotation, then we may be fine with just 10 
bit entropy - that of a random 4 digit PIN or single dictionary password.

If we want to increase the amount of allowed login attempts or password 
lifetime, then we need to increase the amount of required entropy in passwords 
to retain security level.

> > > (switch "entropy" with "score" if we want to be user-friendly and not 
> > > scare
> > > users with technicalities)
> > 
> > I am not too confident with the password entropy scoring as presented by
> > the NIST standard.
> 
> The NIST standard is meant for passwords which are limited in length and
> was designed to be used from the days when passwords were limited to 7 or 8
> characters. So trying to apply its scoring in unlimited length passwords is
> definitely suspect.

No, it didn't say anything about the max length of "Memorized Secret Token".
It said that if the system requires better protection than an "7 or 8 
character password" (14 bits of entropy) can provide, the system 
*can't use* passwords for authentication in the first place.

> However unless we can agree to some sort of measurement system then every
> thing we 'impose' is going to be no better than throwing salt over our
> shoulder and turning 3 times windershin.

I think the rules for Level 1 and Level 2 are quite reasonable:
The probability that an attacker guesses a password during password life time 
is 1% and 0.1% respectively for Level 1 and Level 2.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20150226/e86d5da3/attachment.sig>