I agree. Unfortunately, the Fedora security team does not :(

well, shhhhh, better nobody tell them about the installer, then.

is there somewhere this change was discussed/documented so I can go break some heads^H^H^H^H^^H^H^H^H^H^H^H effect a peaceful and considered re-evaluation?

This came back with this commit:

https://git.gnome.org/browse/gnome-initial-setup/commit/?id=59be1ba5fec4a40229704a39c6f305ab3f04030d

I think we can just 

diff --git a/gnome-initial-setup/pages/password/gis-password-page.c b/gnome-initial-setup/pages/password/gis-password-page.c
index 7ab9662..7661302 100644
--- a/gnome-initial-setup/pages/password/gis-password-page.c
+++ b/gnome-initial-setup/pages/password/gis-password-page.c
@@ -59,7 +59,7 @@ page_validate (GisPasswordPage *page)
 {
   GisPasswordPagePrivate *priv = gis_password_page_get_instance_private (page);
 
-  return priv->valid_confirm && priv->valid_password;
+  return priv->valid_confirm;
 }
 
 static void

This seems wrong to me. There can't be a good reason why gnome-initial-setup and gnome-control-center should accept different sets of passwords. If we're going to say anything goes in gnome-initial-setup, we ought to do so in gnome-control-center as well.

Ondrej, what do you think about making gnome-control-center more permissive to match g-i-s?

For Fedora purposes we'd like consistency between GNOME and anaconda/initial-setup, note, that was the initial conflicting experience.

I do think the password check should be defeatable somehow, but I'm fine with it being a little harder than 'it's totally advisory and you just get a not-that-scary grey warning text' - bigger flashing warnings and 'do you really want to do this?' buttons are fine by me.

We'll address g-i-s / g-c-c consistency next cycle when we merge g-i-s into the g-c-c repository.

(In reply to comment #7)
> For Fedora purposes we'd like consistency between GNOME and
> anaconda/initial-setup, note, that was the initial conflicting experience.
> 
> I do think the password check should be defeatable somehow, but I'm fine with
> it being a little harder than 'it's totally advisory and you just get a
> not-that-scary grey warning text' - bigger flashing warnings and 'do you really
> want to do this?' buttons are fine by me.

libpwquality is garbage at actually telling me a good password, so I don't want a giant warning dialog when I can't find any password ever that passes its checks.

(In reply to comment #8)
> We'll address g-i-s / g-c-c consistency next cycle when we merge g-i-s into the
> g-c-c repository.

Is that actually going to happen? Why?

I've been over this issue in a few places, and have repeatedly bumped up against libpwquality. I wish I could remember all the details of those encounters...

In terms of the design, though, I think that some very minimal hard requirements are desirable, just to avoid really silly passwords. Something like requiring passwords that:

 * Are 6 characters or longer
 * Contain two of: upper case, lower case, numbers, symbols

We can and should provide guidance on creating a strong password, but enforcing complex logic rules is a) unfriendly and b) error prone.

(In reply to comment #10)
> (In reply to comment #8)
> > We'll address g-i-s / g-c-c consistency next cycle when we merge g-i-s into the
> > g-c-c repository.
> 
> Is that actually going to happen? Why?

Bastien suggested that it would make sense to improve code sharing between the very similar modules, and prevent divergence. I think it makes sense, now that g-i-s is mostly done.

For an example of the needless divergence that happens, compare um-realm-manager.c in both modules.

allan: "I think that some very minimal hard requirements are desirable, just to avoid really silly passwords."

yeah, I think in theory that's fine. For testing purposes, FWIW, "Contain two of: upper case, lower case, numbers, symbols" is kind of a pain: I find passwords like 'aaaaaa' or '111111' most efficient for test purposes, but I realize it doesn't make sense to optimize for QA ;)

I'll also note, which covers a more general case, that it doesn't allow xkcd-style passwords.

(In reply to comment #13)
> I'll also note, which covers a more general case, that it doesn't allow
> xkcd-style passwords.

Which is a big problem. If you're going to measure password quality then you have to take the "complex" libpwquality approach; otherwise it's better not to use any quality rules at all. Rules like "Contain two of: upper case, lower case, numbers, symbols" just encourage users to have weaker passwords when enforced regardless of password length.

(In reply to comment #12)
> > > We'll address g-i-s / g-c-c consistency next cycle when we merge g-i-s into the
> > > g-c-c repository.

This appears to be a one-line change, so I'm not really seeing a good case for delay. Let's either revert it in g-i-s, or else make the corresponding change in g-c-c.

(In reply to comment #5)
> I think we can just 
> 
> diff --git a/gnome-initial-setup/pages/password/gis-password-page.c
> b/gnome-initial-setup/pages/password/gis-password-page.c
> index 7ab9662..7661302 100644
> --- a/gnome-initial-setup/pages/password/gis-password-page.c
> +++ b/gnome-initial-setup/pages/password/gis-password-page.c
> @@ -59,7 +59,7 @@ page_validate (GisPasswordPage *page)
>  {
>    GisPasswordPagePrivate *priv = gis_password_page_get_instance_private
> (page);
> 
> -  return priv->valid_confirm && priv->valid_password;
> +  return priv->valid_confirm;
>  }
> 
>  static void

Yes, this should be enough, but we have to change it also in g-c-c (and anaconda?) and warn user about setting weak password at least. So, it involves also design changes...

It is consistent with g-c-c currently thanks to the mentioned commit.

(In reply to comment #6)
> This seems wrong to me. There can't be a good reason why gnome-initial-setup
> and gnome-control-center should accept different sets of passwords. If we're
> going to say anything goes in gnome-initial-setup, we ought to do so in
> gnome-control-center as well.
> 
> Ondrej, what do you think about making gnome-control-center more permissive to
> match g-i-s?

It doesn't depend only on me. It should be discussed with security team...

(In reply to comment #8)
> We'll address g-i-s / g-c-c consistency next cycle when we merge g-i-s into the
> g-c-c repository.

That's great idea :-), because at least account pages are almost identical with g-c-c!

(In reply to comment #15)
> It is consistent with g-c-c currently thanks to the mentioned commit.

No it's not consistent; g-c-c won't allow you to use a bad password, and g-i-s does since this patch was pushed....

(In reply to comment #16)
> It doesn't depend only on me. It should be discussed with security team...

I know this group was recently formed, but they don't seem to have a wiki page or a mailing list, so no idea how to contact them.

(In reply to comment #18)
> (In reply to comment #16)
> > It doesn't depend only on me. It should be discussed with security team...
> 
> I know this group was recently formed, but they don't seem to have a wiki page
> or a mailing list, so no idea how to contact them.

http://fedoraproject.org/wiki/Security_Team

Well that was nice while it lasted, but now anaconda has decided to enforce password strength checks (again? I lose track, I really do):

https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html

so I suppose if we want it to be consistent we have to flip g-i-s back again?

Personally I think I'm going to go and flip some desks.

With my user hat on, I'd be fine with this change if I was ever able to get a "good" password past libpwquality. All my attempts at picking a password, *keyboard mashing included*, have said that my password is the lowest of the low. This includes a password with multiple symbols, numbers, and letters of either case.

This isn't my password nor my password scheme, but try "##r3dh4t%%", which I think is a fairly strong password. libpwquality scores it a 0.

jasper: iirc it's okay with 'correcthorse' at present, though I don't know how long that's gonna last. bcl suggested something like 1q0o2w9i3e8u (a keyboard pattern).

(In reply to comment #20)
> Well that was nice while it lasted, but now anaconda has decided to enforce
> password strength checks (again? I lose track, I really do):
> 
> https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html
> 
> so I suppose if we want it to be consistent we have to flip g-i-s back again?

Why there isn't comment that it was reverted to not enforce strong passwords:
https://git.gnome.org/browse/gnome-initial-setup/commit?id=2587b774490718c962a5da73beec9e060ab202b6

I didn't know about...

(In reply to comment #21)
> This isn't my password nor my password scheme, but try "##r3dh4t%%", which I
> think is a fairly strong password. libpwquality scores it a 0.

pwquality_check returns for "##r3dh4t%%" value 35 (from range 0-100). So it isn't so low (depends on PWQ_SETTING_MIN_LENGTH)...

Maybe the function pw_strength, which get the strength level (weak, low, medium, good, high) should be improved. There is table, how it is determined:
error ... weak
0-50 ... low
50-75 ... medium
75-90 ... good
90-100 ... high

However this code were there before libpwquality and it is probably too hard, maybe something like would be better:
0-25 ... low
25-50 ... medium
50-75 ... good
75-100 ... high

But it is no change, when libpwquality returns error (which is what makes some people angry)...

(In reply to comment #20)

> so I suppose if we want it to be consistent we have to flip g-i-s back again?

No.

(In reply to comment #24)
> pwquality_check returns for "##r3dh4t%%" value 35 (from range 0-100). So it
> isn't so low (depends on PWQ_SETTING_MIN_LENGTH)...

Why is that password low-strength? From my understanding of Anaconda, it will reject low-strength passwords, which seems extremely bizarre to me. If I follow the advice it gives (add more numbers), it seems to actually make the password strength go down *even more*!

libpwquality's ratings have never made any logical sense to me, and seem to be completely at odds with whatever the rest of the internet uses for a password strength meter.

Ops, it looks like anaconda doesn't accept passwords with score 0-50, so:

anaconda accepts passwords with score > 50
g-i-s accepts all passwords (even with libpwquality errors)
g-c-c accepts passwords with score > 0

we should really unify it at least in g-i-s and g-c-c...

There is little value in enforcing great passwords for local access to a machine. Let's pick a lower bar (dramatically lower than 35 if ##r3dh4t%% is 35) for g-i-s and g-c-c, then we can file a bug against anaconda to suggest they use the same.

Now, a distraction for another bug: if the user turns on Remote Access in the Sharing panel, we should not allow that unless his password is dramatically better than 35.

What's wrong with ##r3dh4t%% ? Do you honestly think it's an insecure password for the network? What's the attack to get in there with that?

(In reply to comment #29)
> What's wrong with ##r3dh4t%% ? Do you honestly think it's an insecure password
> for the network? What's the attack to get in there with that?

It will fall to a simple dictionary attack if there's no restriction on authentication attempts, but it looks like sshd only allows 6 guesses every two minutes by default, so there's no problem, pay me no mind.

Do dictionary attacks have "redhat" in the PW list, and do the symbol prefixes? Also, yes, any network authentication system we ever ship should be rate limited. If there's any that aren't, then we can talk about enforcing password limits.

Anyway, I'm not the maintainer of g-i-s anymore, so treat my feedback as "just a user". If this could get to the libpwquality / Anaconda guys, then that would be nice.

(In reply to comment #31)
> Do dictionary attacks have "redhat" in the PW list, and do the symbol prefixes?

Surely, but it doesn't matter for this case as it's rate limited and not protecting encrypted data. Like I said, pay me no mind. :)

What anaconda does is really not relevant for whether or not we implement reasonable password policies in gnome-initial-setup.

Note the case anaconda is concerned about is where sshd is running with password access enabled OOTB, which is the case on Fedora Server but I think not Fedora Workstation?

I agree with Matthias: GNOME is upstream, Anaconda is one of many downstreams. Saying that g-i-s should or shouldn't enforce password strength checks because Anaconda does is like saying that g-i-s should run passwords through cracklib instead of pwquality because that is what YaST does.

Regardless, Anaconda is probably going to need different defaults for Server and Workstation if Server is concerned about OOTB sshd. After a little testing with g-c-c, even 0 (supposedly the weakest possible password) is clearly much too strict. 50 is unreasonable. Strong passwords matter for encryption passwords (disk encryption, wi-fi encryption) where guesses are not rate-limited, not local passwords for home desktops.

(In reply to comment #27)
> Ops, it looks like anaconda doesn't accept passwords with score 0-50, so:
> 
> anaconda accepts passwords with score > 50
> g-i-s accepts all passwords (even with libpwquality errors)
> g-c-c accepts passwords with score > 0

I did a little work to make g-i-s warn somewhat more noticeably when the user chooses a weak password, then took a stab at changing g-c-c to accept all passwords like g-i-s, but I ran into a snag. g-c-c uses passwd to make the change, but passwd runs the change through PAM, which on Fedora hooks into pam_pwquality to enforce a password strength check. OK, well at least it's pwquality and not something completely different like pam_cracklib (which, by the way, *will* be used outside Fedora whether we like it or not)... but it prevents us from allowing passwords with strength 0 in g-c-c, since even if we present the password as acceptable in the UI, it will still be rejected by passwd. So that's worse than the status quo.

I think we need to take the opposite approach: mandate a quality score of 1 in g-i-s, and change pwquality to be more lenient. Probably a chat with the pwquality folks is in order at this point. I'm thinking we need product-specific default configurations, so distros can choose for themselves what to enforce by default: for Fedora we would use a very weak check for Workstation and a stronger check for Server. Thoughts?

My other issue is that I often have low-security accounts for testing Wayland or other things as a developer (e.g. my password for Wayland testing is often just "test" or "hunter2")

If we fix libpwquality to not be so ridiculous and inconsistent so that I can actually get literally any password through (you know my typical examples here), I'll be fine with it, but still skeptical.

I'll also say that we probably shouldn't check pw quality on any non-wheel user.

(In reply to Michael Catanzaro from comment #35)
> I think we need to take the opposite approach: mandate a quality score of 1
> in g-i-s, and change pwquality to be more lenient. Probably a chat with the
> pwquality folks is in order at this point. I'm thinking we need
> product-specific default configurations, so distros can choose for
> themselves what to enforce by default: for Fedora we would use a very weak
> check for Workstation and a stronger check for Server. Thoughts?

So talking with Tomas Mraz, who wrote libpwquality... he is not keen on product-specific configuration. I brought up a couple specific points regarding the password requirements at [1], most importantly the number of characters in the new password that must not be present in the old password, which is currently set to 5 but which he's willing to lower to 1. That should be a significant improvement. I also requested the minimum length for a password be lowered from 9 to 6, but got 8. So, eh, an improvement.

Tomas also requested anaconda switch from accepting passwords with score >50 to score >0, like gnome-control-center does, so this makes me more confident that we should have gnome-initial-setup match gnome-control-center, leave gnome-control-center unchanged, probably anaconda will change, and we will all be on the same page again. Then we can continue to haggle about the details of the default configuration, including pushing for lower defaults for Workstation if need be, and other distros can do whatever they want with pwquality.conf.

So: I propose we revert commit 2587b774490718c962a5da73beec9e060ab202b6 so that g-i-s again rejects passwords that score 0 to match g-c-c, and ask Tomas to change the default libpwquality.conf to make it much easier to score higher than zero. Any password that scores 1 or higher still gets accepted. Matthias, Jasper, does this sound OK?

[1] https://fedorahosted.org/fesco/ticket/1412#comment:31

(In reply to Michael Catanzaro from comment #37)

> 
> So: I propose we revert commit 2587b774490718c962a5da73beec9e060ab202b6 so
> that g-i-s again rejects passwords that score 0 to match g-c-c, and ask
> Tomas to change the default libpwquality.conf to make it much easier to
> score higher than zero. Any password that scores 1 or higher still gets
> accepted. Matthias, Jasper, does this sound OK?

No. Still against it.

I don't think we should enforce password strength in g-c-c but not g-i-s, so alternative proposal: leave g-i-s unchanged, and change gnome-control-center to use accountsservice always when changing passwords, instead of passwd [1], so that we can set passwords with pwquality score of 0 there. Would that be fine? Ondrej?

[1] https://git.gnome.org/browse/gnome-control-center/tree/panels/user-accounts/um-password-dialog.c#n178

Note the disadvantages:

/* When setting a password for the current user,
 * use passwd directly, to preserve the audit trail
 * and to e.g. update the keyring password.
 */

We can use [1] to update the keyring password instead. Not sure what to do about audit trail.

[1] https://developer.gnome.org/gnome-keyring/stable/gnome-keyring-Keyrings.html

(In reply to Matthias Clasen from comment #38)
> (In reply to Michael Catanzaro from comment #37)
> 
> > 
> > So: I propose we revert commit 2587b774490718c962a5da73beec9e060ab202b6 so
> > that g-i-s again rejects passwords that score 0 to match g-c-c, and ask
> > Tomas to change the default libpwquality.conf to make it much easier to
> > score higher than zero. Any password that scores 1 or higher still gets
> > accepted. Matthias, Jasper, does this sound OK?
> 
> No. Still against it.

I tested g-i-s in VM yesterday, I chose password "q" and 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

So not sure it is working properly with weak passwords? Could you prove it?

(In reply to Michael Catanzaro from comment #40)
> Note the disadvantages:
> 
> /* When setting a password for the current user,
>  * use passwd directly, to preserve the audit trail
>  * and to e.g. update the keyring password.
>  */
> 
> We can use [1] to update the keyring password instead. Not sure what to do
> about audit trail.
> 
> [1]
> https://developer.gnome.org/gnome-keyring/stable/gnome-keyring-Keyrings.html

That's exactly the reason why I am against, because passwd doesn't allow you to set weak password directly and I'm not sure what to do with the audit trail (and designers are definitely against thing like adding popup forcing user to restart his session to apply changes)...

I would like to mention there is corresponding bug 744735 in g-c-c opened recently.

This feels hopeless.

Here are a couple of tweaks to the password page for the world where we do not enforce password strength. Note the second one is for 3.18 since it has string changes. But I think this is just going to be broken as long as pwquality is in our PAM stack.

Created attachment 297510 [details] [review]
password: don't set a checkmark in the first password entry

Currently, when the password is bad there is no checkmark in the initial
password entry, and when the password becomes good a new checkmark is
added. This is a holdover from when the password quality check was
enforced. Remove it.

Created attachment 297511 [details] [review]
password: visibly warn the user when the password is bad

(In reply to Michael Catanzaro from comment #43)
> This feels hopeless.

Agreed.

> But I think this is just going to be broken as long as
> pwquality is in our PAM stack.

Agreed.

Attachment 297510 [details] pushed as b7f05cf - password: don't set a checkmark in the first password entry
Attachment 297511 [details] pushed as 3049f2c - password: visibly warn the user when the password is bad

(In reply to Ondrej Holy from comment #41)
> I tested g-i-s in VM yesterday, I chose password "q" and 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
> 
> So not sure it is working properly with weak passwords? Could you prove it?

Hm, I think we forgot about this bug :(