GNOME Bugzilla – Bug 744735
Don't hard enforce password strength checks
Last modified: 2015-08-05 13:55:45 UTC
Let's do the sane thing and not hard enforce password strength checks. gnome-initial-setup doesn't do that either. See: commit 2587b774490718c962a5da73beec9e060ab202b6 Author: Matthias Clasen <mclasen@redhat.com> Date: Tue Sep 2 13:08:26 2014 -0400 Don't hard-enforce strong passwords This regressed when we synced the password page with the control-center. https://bugzilla.gnome.org/show_bug.cgi?id=735578
Created attachment 297128 [details] [review] user-accounts: Don't hard enforce strong passwords
Review of attachment 297128 [details] [review]: looks good
I agree that we should be consistent in g-c-c and g-i-s, however recently anaconda started enforcing passwords with score > 50 and there is patch to allow passwords also with negative score (e.g. with less then 8 characters for example). I don't think this is right way. I think we should enforce passwords with minimal length at least... See: https://bugzilla.gnome.org/show_bug.cgi?id=735578
Also there is problem, when you try to set weak password, UI allows you to do that, but passwd returns error... 1/ apply the patch 2/ open user accounts 3/ click to password 4/ try to change it to e.g. "x" and press change 5/ you got error from passwd "The new password is too simple"
So I think we should not allow to press change button before password is strong enough to go thru passwd...
(In reply to Ondrej Holy from comment #3) > I agree that we should be consistent in g-c-c and g-i-s, however recently > anaconda started enforcing passwords with score > 50 I don't think we want that change in Workstation. We will either override it in a Workstation specific change [1], or simply revert the change. [1] Something like: http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/fedora-workstation.py > See: > https://bugzilla.gnome.org/show_bug.cgi?id=735578 Anything particular in that bug you wanted to point at? I have read it and there is a lot going on there.
(In reply to Ondrej Holy from comment #4) > Also there is problem, when you try to set weak password, UI allows you to > do that, but passwd returns error... Aha, this explains why I don't get the "change password" dialog after creating an account with a weak password. It shows me a dialog which thinks that I haven't set any password. How does this work in gnome-initial-setup? What happens if I create an account with "123456" as the password?
(In reply to Debarshi Ray from comment #6) > (In reply to Ondrej Holy from comment #3) > > I agree that we should be consistent in g-c-c and g-i-s, however recently > > anaconda started enforcing passwords with score > 50 > > I don't think we want that change in Workstation. We will either override it > in a Workstation specific change [1], or simply revert the change. Ok, good to know... > [1] Something like: > http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/ > fedora-workstation.py > > > See: > > https://bugzilla.gnome.org/show_bug.cgi?id=735578 > > Anything particular in that bug you wanted to point at? I have read it and > there is a lot going on there. Nothing concrete, I just wanted to mention corresponding bug... (In reply to Debarshi Ray from comment #7) > (In reply to Ondrej Holy from comment #4) > > Also there is problem, when you try to set weak password, UI allows you to > > do that, but passwd returns error... > > Aha, this explains why I don't get the "change password" dialog after > creating an account with a weak password. It shows me a dialog which thinks > that I haven't set any password. > > How does this work in gnome-initial-setup? What happens if I create an > account with "123456" as the password? I tested it in VM and it seems it is working in g-i-s, but I saw some warning about keyring, but I forgot to copy it before deleting the VM. But I hope it is following one (which is printed when running g-i-s on my desktop): ** (gnome-initial-setup:3889): WARNING **: Failed to change keyring password: GDBus.Error:org.gnome.keyring.Error.Denied: The password was invalid It is working in g-i-s, because passwd allows you to set weak password, when you run it as root (e.g. thru accountsservice): $ sudo passwd oholy But for current user it doesn't work (and this is what we are doing in g-c-c for current user): $ passwd And we can't probably set the password thru accountsservice to avoid that, look at comment in the code: /* When setting a password for the current user, * use passwd directly, to preserve the audit trail * and to e.g. update the keyring password. */
*** Bug 734581 has been marked as a duplicate of this bug. ***
Review of attachment 297128 [details] [review]: After talking to Ondrej and Matthias (#control-center on GIMPNet): 12:02 <rishi> hadess: Hey! About bug 744735 ... 12:02 <Services> Bug http://bugzilla.gnome.org/show_bug.cgi?id=744735 normal, Normal, ---, oholy, NEW , Don't hard enforce password strength checks 12:02 <rishi> Relaxing the check in gnome-control-center is not enough, because PAM will enforce it. 12:03 <rishi> So, with my current patch, if you create an account with a weak password, that account won't get any password because passwd will error out. 12:03 <rishi> I spoke briefly with mclasen about it. 12:04 <rishi> This isn't a problem with g-i-s because it runs in an environment that is different from g-c-c's. 12:04 <rishi> There were some details involving accountservice and audit. 12:04 <rishi> And the outcome was something like "*shrug*, the whole thing sucks, fuck it". :) 12:05 <mclasen> g-c-c uses accountsservice to create the account 12:05 *** mkasik (~mkasik@nat-pool-brq-t.redhat.com) has joined channel #control-center 12:05 <mclasen> and indeed, the whole system sucks, and there's no way we can be consistent 12:07 <hadess> rishi, ok, can you mark the patch as needs-work then?
Well it's only in the PAM stack on Fedora, so that would IMO be a downstream issue rather than a GNOME issue. But anyway: I still think we can get everything consistent. :) At the last Fedora Workstation WG meeting (mclasen was there) we decided that we should either hard-enforce password strength check in g-i-s in addition to g-c-c (so leave g-c-c unchanged) and modify libpwquality to allow much weaker passwords than it currently does, or else remove libpwquality from the PAM stack and stop enforcing password strength check in g-c-c (so your current patch would not need changes), with a preference for the former if possible (the strength check can be configured to be stricter and is useful to have, especially in corporate environments). Kalev "volunteered" to work with the pwquality folks on this.
For Fedora Workstation we decided to enforce password strength here; presumably that's what we want to do upstream as well.