Password policy changes

[Adam Williamson]

Hey, folks. I'm writing with my Server SIG member hat on, here. We've 
been discussing password policy changes at our meeting today.

So the Great Password Policy Bunfight of 2015 was resolved by anaconda 
creating a mechanism for products/spins to set their own password 
policy:

https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e...

I'm slightly worried, however, about the possibility that everyone 
goes out and picks a more lenient policy more or less at random and we 
wind up with different policies on every Fedora medium. That seems 
like it'd be needlessly confusing to users and difficult to document.

I'm wondering if those products/spins intending to set a policy weaker 
than the default could all agree on the same one, so there'd only be 
at most two policies to care about (and if all products/spins overrode 
the upstream default, there'd only be one).

The obvious choice would be the pre-F22 policy, which I believe should 
be:

--nostrict --minlen=6 --minquality=50 --nochanges --emptyok

(though it's not *entirely* clear from the code - I think it used 
pwquality upstream defaults - so I may be a bit off).

What's the general feeling here? Have other SIGs discussed this yet? 
Come to any decisions? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Michael Catanzaro]

Ah, I'm not sure how well this discussion is going to work, cross-posted
to so many lists, unless the list moderators are very quick at approving
messages....

On Tue, 2015-03-24 at 08:36 -0700, Adam Williamson wrote:
>  --nostrict --minlen=6 --minquality=50 --nochanges --emptyok 
I added Tomas Mraz, libpwquality developer, to CC, in case he's not on
any of these lists.

My understanding (Tomas may correct me) is that --minquality should be
set to 1 for each product. 0 quality doesn't mean "worst password ever,"
it means "any unacceptable password." Then 1 is the worst acceptable
password. pwquality.conf determines what is acceptable and what isn't.
pwquality is part of the PAM stack and rejects 0-strength passwords once
the system is installed. It doesn't make sense for Anaconda to enforce a
different policy than will be enforced after installation, so it follows
that we should all use --minquality=1 and just have different
pwquality.conf to adjust the strength of the passwords if need be. I
think that should be acceptable for all products.

--minlen is redundant with pwquality.conf, because pwquality has its own
min length and will set the password's quality to 0 if not reached. So I
guess the right choice for that is 0 if it's a check in addition to
pwquality's, but if it's used to override pwquality.conf, then right
choice is "whatever is in pwquality.conf", since it should be the same
as we use on the installed system. But for the LUKS password, there's no
need for --minlen to match pwquality.conf; I'd be interested in setting
that higher (but not so high as to discourage people from using LUKS).

For Workstation, I guess --emptyok is fine for both user account and
root, though this situation is not a good long-term solution as it sucks
that the user can choose to create his account in either anaconda or
gnome-initial-setup. Removing --emptyok from the user account password
would "solve" that problem, but in the wrong direction since I think we
want account creation to be done by gnome-initial-setup.

The remaining issue is pwquality.conf. For Workstation, I think we want
it to be much more lenient than it currently is. Min password length is
currently 9; 6 (pwquality's hardcoded limit) would be much better. If
any product wants to enforce a stricter password quality, then I think
we're going to need to figure out a way to set up this file differently
on different installations. Perhaps the firewalld-style configuration
package split would work well here.

We also need to make sure that our solution is acceptable to the
gnome-initial-setup developers, which currently uses pwquality to
display password strength but allows setting any password. If they won't
accept any form of password strength enforcement, then I would favor
ripping pwquality out of the PAM stack to resolve the problem. (Perhaps
that could move to a subpackage.) I suspect a very lenient
pwquality.conf may be the only way to reach a compromise here.

Michael

[Matthias Clasen]

On Tue, 2015-03-24 at 12:51 -0500, Michael Catanzaro wrote:
>  
>  the system is installed. It doesn't make sense for Anaconda to 
>  enforce a
>  different policy than will be enforced after installation, so it 
>  follows
>  that we should all use --minquality=1 and just have different
>  pwquality.conf to adjust the strength of the passwords if need be. I
>  think that should be acceptable for all products. 
You're pointing out the same thing I was wondering about when I read 
about this kickstart mechanism: We don't want to configure password 
policies in two places - thats only going to lead to anaconda 
disagreeing with the installed system.

>  We also need to make sure that our solution is acceptable to the
>  gnome-initial-setup developers, which currently uses pwquality to
>  display password strength but allows setting any password. If they 
>  won't
>  accept any form of password strength enforcement, then I would favor
>  ripping pwquality out of the PAM stack to resolve the problem. 
>  (Perhaps
>  that could move to a subpackage.) I suspect a very lenient
>  pwquality.conf may be the only way to reach a compromise here. 
I think the difference of opinion is only about the enforcement part. 
If pwquality gives us useful information about that quality of the 
password then we absolutely show that to the user and help her to come 
up with a better password.

[Miloslav Trmač]

Hello,
>  It doesn't make sense for Anaconda to enforce a
>  different policy than will be enforced after installation, so it follows
>  that we should all use --minquality=1 and just have different
>  pwquality.conf to adjust the strength of the passwords if need be. I
>  think that should be acceptable for all products. 
Yeah, I generally agree that anaconda’s policy and installed-system pwquality.conf should
be the same.  Whether that ends up as anaconda allowing kickstart (and products) to
specify pwquality.conf, and obeying the configuration in there, or having pwpolicy also
edit pwquality.conf, is not hugely important to me; I would slightly favor keeping the
policy in the pwquality package, though.

<snip>
>  We also need to make sure that our solution is acceptable to the
>  gnome-initial-setup developers, which currently uses pwquality to
>  display password strength but allows setting any password. If they won't
>  accept any form of password strength enforcement, then I would favor
>  ripping pwquality out of the PAM stack to resolve the problem. 
That doesn’t make sense to me; if pwquality.conf is configured to be strict, _everything_
on the system should enforce that.  Individual upstreams refusing to be strict should be
handled in Fedora by patching the software to implement distribution-wide consistency.  A
product wanting to consistently not enforce strict policy rules should ship with a weak
pwquality.conf, still allowing administrators to harden the system, instead of ripping
pam_pwquality, or worse, individual instances of code, out and making enforcement more
difficult or impossible.

(It might be worth considering whether pwquality should be configurable to set the
enforcement level and the UI warning level separately.  I’m not sure.)
    Mirek

[Matthew Miller]

On Tue, Mar 24, 2015 at 08:36:28AM -0700, Adam Williamson wrote:
>  I'm wondering if those products/spins intending to set a policy
> weaker 
>  than the default could all agree on the same one, so there'd only be 
>  at most two policies to care about (and if all products/spins overrode 
>  the upstream default, there'd only be one). 
I won't speak for everyone, but I *think* the general cloud attitude
here is to use private/public keys and certificate-based auth instead of
passwords in any case.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Leslie S Satenstein]

Hi Adam
I am not aware of the distribution of Fedora users. I would suspect individuals comprise
90% and small business another 5% and others.
> From my business experience, we know about separation of duties. We
> assign one group to setup the hardware and install Linux, and the second group to receive
> a hand-over. In the handover process, root and admin passwords are changed. 
What we
practiced in the hardware/Software setup group, was to use the simplist of passwords. Yes,
123456, or Vancouver, (I went to UBC). I could see a single password rule as follows:

                        Anything goes.with the caveat

On first system logon, Root and adminstrator passwords must be replaced with ones
respecting Fedora security rules. 

I fully agree with you, that the rules from anaconda, used for installing Fedora 21, were
just fine. I am happy to return to them.
My workaround for the new rule(s) was to use #montreal001 as a password for both admin and
root, with a change for each, following first boot.  

 
Regards 
 Leslie
 Mr. Leslie Satenstein
Montréal Québec, Canada


 
      From: Adam Williamson <adamwill(a)fedoraproject.org&gt;
 To: server(a)lists.fedoraproject.org; desktop(a)lists.fedoraproject.org;
kde(a)lists.fedoraproject.org; cloud(a)lists.fedoraproject.org 
 Sent: Tuesday, March 24, 2015 11:36 AM
 Subject: Password policy changes
   
Hey, folks. I'm writing with my Server SIG member hat on, here. We've 
been discussing password policy changes at our meeting today.

So the Great Password Policy Bunfight of 2015 was resolved by anaconda 
creating a mechanism for products/spins to set their own password 
policy:

https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e...

I'm slightly worried, however, about the possibility that everyone 
goes out and picks a more lenient policy more or less at random and we 
wind up with different policies on every Fedora medium. That seems 
like it'd be needlessly confusing to users and difficult to document.

I'm wondering if those products/spins intending to set a policy weaker 
than the default could all agree on the same one, so there'd only be 
at most two policies to care about (and if all products/spins overrode 
the upstream default, there'd only be one).

The obvious choice would be the pre-F22 policy, which I believe should 
be:

--nostrict --minlen=6 --minquality=50 --nochanges --emptyok

(though it's not *entirely* clear from the code - I think it used 
pwquality upstream defaults - so I may be a bit off).

What's the general feeling here? Have other SIGs discussed this yet? 
Come to any decisions? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop