Anaconda 22.17+ enforces "good" passwords

Chris Murphy lists at colorremedies.com
Thu Feb 26 20:01:36 UTC 2015


On Thu, Feb 26, 2015 at 12:12 PM, Hubert Kario <hkario at redhat.com> wrote:

>
> 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.

I just don't see this being even remotely tenable in an OS installer.
There are no examples of this being successfully foisted on users yet
either. I think the burden is high both for user and development. I
think this GUI application needs to be standalone, with no dependency
on the installer for now.

>
>> > 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

Perhaps not favorable, but it's quite useless and relevant because
it's exactly what any ordinary user wonders when they're burdened with
disproportionate password requirements. Why? It's the mitigating
factors. So how do you create mitigating factors that don't affect the
user at all? I've never run into the 3 attempt limit of a bank card, I
had no idea the limit was that low, because I've never gotten it wrong
three times in a row.


-- 
Chris Murphy


More information about the security mailing list