Password policy changes

Miloslav Trmač mitr at redhat.com
Thu Apr 2 12:58:06 UTC 2015


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


More information about the server mailing list