Password policy changes
mcatanzaro at gnome.org
Tue Mar 24 17:51:16 UTC 2015
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
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.
More information about the server