Hey, folks. I'm writing with my Server SIG member hat on, here. We've been discussing password policy changes at our meeting today.
So the Great Password Policy Bunfight of 2015 was resolved by anaconda creating a mechanism for products/spins to set their own password policy:
https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc...
I'm slightly worried, however, about the possibility that everyone goes out and picks a more lenient policy more or less at random and we wind up with different policies on every Fedora medium. That seems like it'd be needlessly confusing to users and difficult to document.
I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one).
The obvious choice would be the pre-F22 policy, which I believe should be:
--nostrict --minlen=6 --minquality=50 --nochanges --emptyok
(though it's not *entirely* clear from the code - I think it used pwquality upstream defaults - so I may be a bit off).
What's the general feeling here? Have other SIGs discussed this yet? Come to any decisions? Thanks!
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 messages....
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.
Michael
On Tue, 2015-03-24 at 12:51 -0500, Michael Catanzaro wrote:
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.
You're pointing out the same thing I was wondering about when I read about this kickstart mechanism: We don't want to configure password policies in two places - thats only going to lead to anaconda disagreeing with the installed system.
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.
I think the difference of opinion is only about the enforcement part. If pwquality gives us useful information about that quality of the password then we absolutely show that to the user and help her to come up with a better password.
On Tue, Mar 24, 2015 at 08:36:28AM -0700, Adam Williamson wrote:
I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one).
I won't speak for everyone, but I *think* the general cloud attitude here is to use private/public keys and certificate-based auth instead of passwords in any case.
Hi Adam I am not aware of the distribution of Fedora users. I would suspect individuals comprise 90% and small business another 5% and others.
From my business experience, we know about separation of duties. We assign one group to setup the hardware and install Linux, and the second group to receive a hand-over. In the handover process, root and admin passwords are changed.
What we practiced in the hardware/Software setup group, was to use the simplist of passwords. Yes, 123456, or Vancouver, (I went to UBC). I could see a single password rule as follows:
Anything goes.with the caveat
On first system logon, Root and adminstrator passwords must be replaced with ones respecting Fedora security rules.
I fully agree with you, that the rules from anaconda, used for installing Fedora 21, were just fine. I am happy to return to them. My workaround for the new rule(s) was to use #montreal001 as a password for both admin and root, with a change for each, following first boot.
Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada
From: Adam Williamson adamwill@fedoraproject.org To: server@lists.fedoraproject.org; desktop@lists.fedoraproject.org; kde@lists.fedoraproject.org; cloud@lists.fedoraproject.org Sent: Tuesday, March 24, 2015 11:36 AM Subject: Password policy changes
Hey, folks. I'm writing with my Server SIG member hat on, here. We've been discussing password policy changes at our meeting today.
So the Great Password Policy Bunfight of 2015 was resolved by anaconda creating a mechanism for products/spins to set their own password policy:
https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc...
I'm slightly worried, however, about the possibility that everyone goes out and picks a more lenient policy more or less at random and we wind up with different policies on every Fedora medium. That seems like it'd be needlessly confusing to users and difficult to document.
I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one).
The obvious choice would be the pre-F22 policy, which I believe should be:
--nostrict --minlen=6 --minquality=50 --nochanges --emptyok
(though it's not *entirely* clear from the code - I think it used pwquality upstream defaults - so I may be a bit off).
What's the general feeling here? Have other SIGs discussed this yet? Come to any decisions? Thanks!
On Tue, Mar 24, 2015 at 9:36 AM, Adam Williamson adamwill@fedoraproject.org wrote:
Hey, folks. I'm writing with my Server SIG member hat on, here. We've been discussing password policy changes at our meeting today.
So the Great Password Policy Bunfight of 2015 was resolved by anaconda creating a mechanism for products/spins to set their own password policy:
I thought the medium term (Fedora 23/24) strategy was to disable root by default, and then:
- Server was going to rely more on Cockpit to do authentication setup as it's virtual equivalent of first boot, but also the on-going primary interface (Cockpit is enabled by default, it should be pretty straightforward one day to get it to accept a user generated or supplied TLS certificate, and then also enable key based ssh logins maybe even requiring that step to even enable sshd)
- Workstation prefers to rely on g-i-s to configure the first user at first boot.
- Cloud seems more like Server, except possibly without cockpit helping out it'd be more of a conventional CLI approach to key based login setup.
If anything, Anaconda's password UI is obviated by the products' intended behaviors in this area. The short term solution would be better off as "no change" until the various WGs establish they have their first access modes implemented, and then Anaconda password UI can be suppressed for Fedora products — and spins can continue to use it so long as it meets their needs — and then WG's can diverge on password policies once their own infrastructures are ready.
On Thu, Mar 26, 2015 at 01:20:49PM -0600, Chris Murphy wrote:
- Cloud seems more like Server, except possibly without cockpit
helping out it'd be more of a conventional CLI approach to key based login setup.
FWIW, Cloud uses cloud-init for key provisioning; passwords are already out.
On Thu, Mar 26, 2015 at 1:25 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Mar 26, 2015 at 01:20:49PM -0600, Chris Murphy wrote:
- Cloud seems more like Server, except possibly without cockpit
helping out it'd be more of a conventional CLI approach to key based login setup.
FWIW, Cloud uses cloud-init for key provisioning; passwords are already out.
Yes, you've said this before, and I just spaced it. Does cloud-init apply to both netinstall of Cloud, and Cloud images?
On Thu, Mar 26, 2015 at 01:54:28PM -0600, Chris Murphy wrote:
FWIW, Cloud uses cloud-init for key provisioning; passwords are already out.
Yes, you've said this before, and I just spaced it. Does cloud-init apply to both netinstall of Cloud, and Cloud images?
In theory, yes, although the netinstall of Cloud is a bit iffy since _really_ to make it "Cloud" you need all a bunch of kickstart stuff... including the current password setting. So, maybe there's room for a password policy there after all.
On Thu, Mar 26, 2015 at 2:08 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Mar 26, 2015 at 01:54:28PM -0600, Chris Murphy wrote:
FWIW, Cloud uses cloud-init for key provisioning; passwords are already out.
Yes, you've said this before, and I just spaced it. Does cloud-init apply to both netinstall of Cloud, and Cloud images?
In theory, yes, although the netinstall of Cloud is a bit iffy since _really_ to make it "Cloud" you need all a bunch of kickstart stuff... including the current password setting. So, maybe there's room for a password policy there after all.
Or I'd wonder what the use case is for netinstall of Cloud that can't be met (now or with enhancement) by Cloud images?
I'm thinking it's at best 80/20, in which case I'd be inclined to say the 20% (or less) with a use case for netinstall Cloud maybe are better off with netinstall Server. And then if I'm way off and the use case for netinstall Cloud is higher than 20%, look at how Cloud images could adapt to one or two of the most common use cases causing a dependency for Cloud netinstall.
desktop@lists.stg.fedoraproject.org