GNOME Bugzilla – Bug 754213
g-i-s should NOT hard enforce password strength checks
Last modified: 2018-04-12 03:43:04 UTC
The Fedora Workstation WG has agreed to enforce password strength in g-i-s. FESCo is about to mandate the same thing, with the system password policy. What is left undefined is the rules for password strength. Those we do not bother with here: they are left up to pwquality and specifically pwquality.conf. Distros can choose to make the policy extremely lenient, fairly lenient (the upstream default), or fairly strict by modifying this file. This will unify the behavior of g-i-s and g-c-c.
Created attachment 310148 [details] [review] Revert "password: don't set a checkmark in the first password entry" This reverts commit b7f05cf285c0809563b51a0f9981c53d62c2f0bb.
Created attachment 310149 [details] [review] Revert "Don't hard-enforce strong passwords" This reverts commit 2587b774490718c962a5da73beec9e060ab202b6.
(In reply to Michael Catanzaro from comment #0) > Those we do not > bother with here: they are left up to pwquality and specifically > pwquality.conf. But you do realize that this is exactly the problem that leads to the terrible user experience, right ? These rules basically define the user exerience of setting passwords. Either it is ok, or it is just broken. And leaving this up whoever maintains some deep-in-the-stack library or some committee is just a recipe for bad UX.
Attachment 310148 [details] pushed as 55774e2 - Revert "password: don't set a checkmark in the first password entry" Attachment 310149 [details] pushed as 0c67a98 - Revert "Don't hard-enforce strong passwords"
At least now, we can have a centralized policy that will be consistently respected by GNOME. If you are running an enterprise and want employees to have 20 character passwords, or if you're building a distro and want there to be no enforcement at all, now you can change pwquality and GNOME will obey. Well, g-c-c already obeyed, but now g-i-s does too. Or, is that exactly what you did not want? Anyway, if you want to change the default policy in Workstation to be "allow everything," we can still do that!
Reopened because we need to revert the revert (of the revert?), at least in Fedora, as FESCo has ruled we must not enforce the password strength, which I somehow missed. I haven't done the revert for g-i-s yet because we need to change g-c-c as well, and that requires changes in Fedora's PAM stack.
Closing because I totally misunderstood the policy... we're doing the "right" thing (for Fedora) now. For reference: https://fedoraproject.org/wiki/Passphrase_policy
Well, maybe we don't know what it means. "root / admin users should be able to override quality checks (for purposes of this, the installing user is root/admin)" I think that means g-i-s and g-c-c must enforce password strength for non-admin user accounts but not for admin accounts (so it would never be enforced when installing a system). That probably makes sense....
(In reply to Michael Catanzaro from comment #8) > Well, maybe we don't know what it means. > > "root / admin users should be able to override quality checks (for purposes > of this, the installing user is root/admin)" > > I think that means g-i-s and g-c-c must enforce password strength for > non-admin user accounts but not for admin accounts (so it would never be > enforced when installing a system). That probably makes sense.... Ooops, I forgot about this. The required behavior is to never enforce the password strength check in new user mode, because in that mode the user is an administrator. And we do not set password in existing user mode. So g-i-s must never enforce password strength. Some reverts will be needed. The behavior required by FESCo for gnome-control-center is to not enforce the password strength check when the password is being set by an administrator, but to continue enforcing it when the password is being set by a standard user. That's a wholly-separate bug. The gnome-control-center maintainers will have to decide whether we implement that upstream or downstream.
BTW this is somewhat urgent, we need to fix it before fedora-devel notices :)
The following fixes have been pushed: 98c4adc Revert "Revert "password: visibly warn the user when the password is bad"" 985f2a0 Revert "Revert "Don't hard-enforce strong passwords""
Created attachment 370829 [details] [review] Revert "Revert "password: visibly warn the user when the password is bad"" This reverts commit 0c62c71b5754ded5557b759783084bdb7b40176b. With some changes to account for the fact that pw_strength() of 1 is considered weak now.
Created attachment 370830 [details] [review] Revert "Revert "Don't hard-enforce strong passwords"" This reverts commit 0c67a9800c7832dd55c046adc372833a96a96cf0. This is a requirement for Fedora, but I suspect few distros want to irritate users right off the bat by dictating which passwords may be used.