Anaconda 22.17+ enforces "good" passwords

[Hubert Kario]

On Thursday 26 February 2015 11:25:59 Chris Murphy wrote:
> On Thu, Feb 26, 2015 at 3:30 AM, Hubert Kario <hkario at redhat.com> wrote:
> > Talking about entropy without talking about how severe will be the rate
> > limiting or password lifetimes will also lead us nowhere.
> 
> OK, so the password lifetime thing: I just fired my ISP for having 3
> month mandatory password changes. I think it's a bad idea that
> actually makes us less safe.
> 
> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html

and I agree, blanket requirement of changing the password every 30 days is bad

but if we say "password never expires" we need to assume (for purposes of 
calculation) a sufficiently long password life-time - like 100 years

we could go the route of - give me a good enough password and you won't be 
required to change it in next x-months or x-years

but every calculation of security level of a password needs to include:
 - amount of tries the attacker can perform per unit of time
 - how long the password is useful
 - how hard is the password to guess (entropy)

If the "amount of tries" is "5 million per second", the "how long" is "10 
years" then the password needs to be really complex to keep "1% chance to be 
guessed".

But if you enter "100 tries per 30 days", "30 days" and "10 bits of entropy" 
you get "1% chance for the password to be guessed".

We can tune any value we like, but some other value will change too, otherwise 
we will not end up with a system that is as secure as we would like/expect.

> > 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.
> OK yet my bank card 4 digit PIN doesn't rotate. It never expires. It's
> been the same for 8+ years.

it's also locked out after 3 unsuccessful attempts and requires possession of 
hardware token, not a favourable comparison

-- 
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/3a33b08a/attachment.sig>