= phenomenon = changes to enforce strong passwords in anaconda seem to be going down like a lead balloon. The package developers are turning a blind eye to critical feedback with valid reasoning.
= background analysis = http://www.forums.fedoraforum.org/showthread.php?t=302792
= implementation recommendation = please review it and advise the package developers of your views on this. If possible also could someone from FESCo post the outcome in the thread linked to above.
There's been discussion of this change on anaconda-devel-list and test as well, providing those threads for completeness:
I apologize on behalf of Da Community for the tone of some of the comments on the test@ list, but there is some constructive discussion in there too.
Thanks for adding the additional links for completeness Adam. As far as I'm concerned personally I don't have an issue since I set strong passwords anyhow and stated as much on fedoraforum. I can however see the arguments of those giving constructive feedback. Indeed some of the concerns aren't pleasantly voiced at all.
My suggestion would be for an opt-out system if the change has to be committed to anaconda for the benefit of the SSHD issue. How it is implemented is debatable as it will still entail extra mouse or keyboard input of some form. e.g. you set a weak password and a dialogue appears below the password entry fields saying 'tick this box to confirm you wish to use a weaker password than recommended'.
Note that I've requested that this change be made product-specific, since it is enforcing product-specific policy in the installer:
https://lists.fedoraproject.org/pipermail/test/2015-February/124973.html
For the record, to hopefully avoid confusion, some recent discussion suggests that pwquality in F22 is being much stricter than pwquality was in F21, which I think may not have been expected/intended when making this change:
https://lists.fedoraproject.org/pipermail/test/2015-February/125074.html
That's kparal quoting a list of passwords mizmo provided. mizmo tested with F21 and found they all came up as 'good' or 'strong'; kparal got very different results in F22. We should look into this some more, but it's certainly possible that newer pwquality being stricter is a compounding factor here.
There are couple of bugs opened about this as well:
https://bugzilla.redhat.com/show_bug.cgi?id=1191842 https://bugzilla.redhat.com/show_bug.cgi?id=1192147
All closed as NOTABUG (or duplicate) with very short explanation.
Note that there is no difference between libpwquality and cracklib in Fedora 21 and Fedora 22. The only possibility would be that anaconda somehow calls it differently.
I will probably not be able to make today’s meeting, reiterating my +1.
Replying to [comment:13 mitr]:
I will probably not be able to make today’s meeting, reiterating my +1. Wrong ticket, sorry.
As far as ideal solutions go, https://lists.fedoraproject.org/pipermail/security/2015-February/002079.html .
As far as a practical immediate resolution, I am leaning towards asking anaconda to revert. There really are cases where strong passwords are not necessary, we don’t have that good automation to allow the system to have strong passwords that are invisible to the user, and the workaround, “use a strong password and then change it later” is so obviously not what we would want the user to do. (But note that this is not a vote yet.)
As the author and maintainer of libpwquality (not a FESCo member anymore) I agree with mitr's statement above. There are also no generally accepted password policy requirements and as you can see in the various discussions there can be strong opinions on what is a sufficiently strong password and what not which completely differ among interested parties. If anything the effort should be spent on implementing per-IP rate-limiting of ssh connection attempts where I can see much bigger possibility to thwart the brute force attacks.
I think that's already implemented, judging from these default settings in /etc/ssh/sshd_config:
{{{
}}}
I would assume that means a given IP can make 6 guesses every 2 minutes.
Replying to [comment:16 catanzaro]:
I think that's already implemented, judging from these default settings in /etc/ssh/sshd_config: {{{ LoginGraceTime 2m MaxAuthTries 6 }}} I would assume that means a given IP can make 6 guesses every 2 minutes.
AFAICS that is 6 guesses per a TCP connection; and you can have up to a hundred open at the same time, and closing a connection and re-connecting gives you new 6 guesses.
There is rate limiting of unauthenticated TCP connections and it is configurable with MaxStartups option. However note that the default is fairly permissive allowing at most 100 concurrent unauthenticated TCP connections. Also this rate limiting is not per-IP which allows for DoS although due to the random early drop implemented it is not as easy as if there was a straight hard limit.
So no, this is not a real brute-force prevention at least not for really weak passwords.
Talking with Peter Jones briefly, he pointed out that Fedora does not have a password policy at all. Which means that this change, the discussion on the list about it, and any decision we make amounts to random people on the internet arguing about what they personally think password policies should be.
I'd be somewhat opposed to asking anaconda to do a straight up revert in the absence of an agreed upon project password policy. I'm also fairly confident that we will not come to a consensus on such a policy for the entire project.
Replying to [comment:20 jwboyer]:
Talking with Peter Jones briefly, he pointed out that Fedora does not have a password policy at all.
We have an http://fedoraproject.org/wiki/Features/PasswordQualityChecking , though that doesn’t go very far.
Ultimately, “password policy” is a wrong abstraction level to deal with this: we want something like “preferred authentication mechanism policy”; or rather, design and implementation rather than policy. Writing policies, while not ''wrong'', will not get us significantly beyond where we are now.
Much of the discussion around the password strength change in anaconda has been focused on the removal of choice. I'm not sure I really buy in to that too much because the enforcement at installation time does not enforce how things go on the installed system. Plus, kickstart installs still have the same password flexibility as they always have. I think the real issue is that something has changed for people doing frequent installs and now they have to get out of the habit of clicking twice to accept a simple password.
But it does raise a point about passwords in Fedora. Many have pointed out that anaconda appears to be dictating password policy for the distribution. It's really not, it's just that anaconda is the first thing used to get up and running. From a FESCo perspective, I would like to see a decision around password checking and strength requirements as well as a preferred backend (or backends) to use for that. We have a history of consolidating on centralized backends for major parts of distribution functionality and I see no reason why this should not be one of them.
I do not like the idea of configurable password strength on a per variant basis (I've heard this discussed a few times). That seems like unnecessary complexity and unless we have a strong reason to pursue that on a per variant basis, we should lean towards the same FESCo decision for each.
Replying to [comment:22 dcantrel]:
I think we do have a strong reason. The thing is, in Fedora Workstation, sshd is disabled by default, the user account password is just a local password. The threat to protect against is people with physical access to your computer actually typing at your keyboard, and the user account password is good security to prevent someone from wandering over to your computer and unlocking it trivially, regardless of how strong the password is. (Well, maybe something stronger than 123 would be good.) Against someone who actually wants to copy files off your computer, the strongest account password ever will help less than putting a MasterLock on the case. Enforcing a very strong password policy for the disk encryption password would make a lot of sense for us, but not for the user account password. That's just my perspective (am I missing something?). The workstation WG is going to discuss this today and might or might not provide a recommendation.
Now, a corporate deployment might legitimately want to enforce a stronger password policy to make it harder for an attacker with physical access to reverse the hash of a local account (these still exist :) to then try that password in other places. That's not a realistic threat for most Workstation users.
I would like to see anaconda to match the same password policy as used by gnome-control-center, which allows passwords with pwquality score > 0, when installing Fedora Workstation. Currently gnome-initial-setup allows all passwords, because 0 is currently too high a bar. It would be really nice to get that eased a bit, so we can also fix the asymmetry between gnome-control-center and gnome-initial-setup. (gnome-control-center's requirement is stricter because it uses passwd so that the change gets logged, and pam_pwquality will reject the change.)
Replying to [comment:23 catanzaro]:
Replying to [comment:22 dcantrel]: I do not like the idea of configurable password strength on a per variant basis (I've heard this discussed a few times). That seems like unnecessary complexity and unless we have a strong reason to pursue that on a per variant basis, we should lean towards the same FESCo decision for each. I think we do have a strong reason. The thing is, in Fedora Workstation, sshd is disabled by default, the user account password is just a local password. The threat to protect against is people with physical access to your computer actually typing at your keyboard, and the user account password is good security to prevent someone from wandering over to your computer and unlocking it trivially, regardless of how strong the password is. (Well, maybe something stronger than 123 would be good.) Against someone who actually wants to copy files off your computer, the strongest account password ever will help less than putting a MasterLock on the case. Enforcing a very strong password policy for the disk encryption password would make a lot of sense for us, but not for the user account password. That's just my perspective (am I missing something?). The workstation WG is going to discuss this today and might or might not provide a recommendation. Now, a corporate deployment might legitimately want to enforce a stronger password policy to make it harder for an attacker with physical access to reverse the hash of a local account (these still exist :) to then try that password in other places. That's not a realistic threat for most Workstation users. I would like to see anaconda to match the same password policy as used by gnome-control-center, which allows passwords with pwquality score > 0, when installing Fedora Workstation. Currently gnome-initial-setup allows all passwords, because 0 is currently too high a bar. It would be really nice to get that eased a bit, so we can also fix the asymmetry between gnome-control-center and gnome-initial-setup. (gnome-control-center's requirement is stricter because it uses passwd so that the change gets logged, and pam_pwquality will reject the change.)
There are clearly a few paths Fedora can take with passwords. I'd rather see FESCo choose the path for the distribution to get everyone on the same page.
For example, if FESCo were to decide that using libpwquality on the backend for consistent password enforcement, changes should take place there. It's worth noting that the change in anaconda was to remove the ability to waive the libpwquality check. It's been doing that for a really long time now. So if we, as a distribution, feel that libpwquality is too restrictive for our users maybe we should adjust its defaults or simply remove it entirely from Fedora.
Huh, having the waiveable check with some at-least-somewhat reasonable default password quality check is still better than having no quality check at all. The suggestion to remove it altogether does not make any sense to me at all.
My point there was that a large number of people now have asked for the old functionality, which is to waive the libpwquality check. Which means that everyone dismisses the functionality of libpwquality's check anyway, so I question why even go to the trouble of checking the password strength anyway if the users who care about it just want to waive it anyway.
But I still would like the topic here to be around what does Fedora want to do when it comes to enforcing strong passwords. There should be a decision here from FESCo that we can work towards achieving in Fedora, for consistency across all variants and packages. When people ask why a particular password check is in place, we can point to the stated engineering decision/goal of FESCo as our guiding principle.
From today's FESCo meeting:
FESCo defers on this. * People seeing issue with seemingly strong passwords should file bugs. FESCo will revisit when all know bugs are resolved
The problems with libpwquality scoring is known, many bugs are filed, and many are over a year old with no progress other than acknowledging this is a difficult problem. https://lists.fedoraproject.org/pipermail/security/2015-February/002075.html
And in that message, it's further suggested two prerequisites be met before this installer change should happen.
Also, the installer UI provides no password quality guideline to inform the user, therefore the user can't produce a minimally compliant password in a single attempt. It's unacceptable UI/UX to expect users to iterate, which is what the new behavior entails.
Okay, thank you for discussing this matter and the logical outcome.
Replying to [comment:27 jwboyer]:
From today's FESCo meeting: FESCo defers on this. * People seeing issue with seemingly strong passwords should file bugs. FESCo will revisit when all know bugs are resolved
IMHO anaconda should follow the same password policy as used by gnome-control-center, which allows passwords with pwquality score > 0. If it currently rejects password with nonzero pwquality score, it is overzealous. The low password score is only a hint and not something that should block the password use. The only passwords that should be rejected are those that do not pass the default settings of pwquality including the dictionary check - that is the pwquality check throws an exception for such password.
Replying to [comment:30 tmraz]:
IMHO anaconda should follow the same password policy as used by gnome-control-center, which allows passwords with pwquality score > 0. If it currently rejects password with nonzero pwquality score, it is overzealous.
It currently rejects passwords with score < 50, so a big step one to a compromise would be to change that.
There is currently a huge disconnect between us Workstation folks and the proponents of stronger passwords. We've been discussing this on IRC and just don't see any actual safety benefit to having a stronger local password. Maybe someone can convince us otherwise. So the next step: if we could change the pwquality defaults to be product-specific, Anaconda would not need to know the difference, I can change gnome-initial-setup to match gnome-control-center and stop ignoring pwquality, and deployments can still change pwquality.conf as they please. For instance, we could have pwquality-config-server and pwquality-config-workstation, like we do for firewall currently. (That is, if the Server WG wants a stricter password policy than we do.)
For instance, while it's important to avoid serialization (password+1, password+2 on each password change) for network passwords, settings like this make no sense for a local password, and just discourage the user from ever changing his password at all:
And this:
6 would be a big improvement for us.
I think that lowering the built-in difok value to for example 1 could be acceptable, there is currently no enforced policy for periodical change of password (I am not a fan of such policy anwyay) and if any system administrator wants to set it up, he can change the difok value in the configuration as well. On the other hand the minlen value of 6 is not that useful because too many passwords of such short length would not pass the cracklib dictionary test anyway. But we could lower it to 8 at least.
Also I don't think it is necessary to ship different policy for Server and Workstation.
So, as a compromise would everyone accept anaconda changing to accept passwords with a score > 0 ?
That would be less strict than anaconda folks wanted/have now.
That would be more strict than workstation folks wanted.
That should ease pain for qa/tester folks.
But then it would at least be consistent over the products and things that change passwords. Additionally we could work with tmraz to adjust libpwquality.
Replying to [comment:34 kevin]:
Setting aside the questionable ethics of changing from voluntary compliance to coercive compulsory compliance without a wider community conversation; and setting aside unmet onus probandi on Anaconda in the first place for why this change is even necessary; any change that adds password complexity along with compulsory compliance requires an accessible guideline in each UI that enforces both, so that the user can produce a minimally compliant password in a single attempt. The goalpost can't be changed while also not informing the user precisely how to succeed. Merely claiming "no goal" while they shoot repetitively in the blind is hostile. And naturally it will make users mad. I'm uncertain if text install could be immune from this requirement, but GUI programs can't just enforce unstated rules.
Just for the record, since we didn't discuss it at the meeting, do we need to treat this as a blocker issue for Alpha? I'm reasonably confident that it doesn't violate any Alpha criteria.
Proposal: Request a Freeze Exception to include it in the Alpha release if it becomes available, otherwise get to it in Beta.
(+1 from me; I don't think we need to rush it in)
+1
Bug proposed as Beta blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1191842
ccing
Anaconda now has the ability to allow users to create a consistent policy for the various password entries during installation. The new kickstart %anaconda section and pwpolicy command implement this, as documented here - https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181
Products can implement their own policy by including a modified copy of https://github.com/rhinstaller/anaconda/blob/f22-branch/data/interactive-defaults.ks in their product.img -- drop it into /usr/share/anaconda/ and it will overwrite the default.
Currently you can adjust the policy for the root configuration spoke, the user spoke and the luks passphrase entry.
From today's FESCo meeting: AGREED: In f22, default back to f21 anaconda password behavior, ask anaconda developers, fedora-release and releng folks to make this change happen before Beta freeze. ACTION: nirik to work with anaconda developers for anaconda password policy
Replying to [comment:45 pnemade]:
Beta Freeze is tomorrow, has any action were taken? (Checking if I missed it, otherwise I'll start poking here)
I have a meeting with anaconda folks in 40 minutes. I'll update this ticket afterwards.
I guess this comment comes too late for your meeting, but note that the options provided by anaconda, while sufficient to get the behavior we want, don't make very much sense: when looking through them I picked out "correct" settings that I think should work for every product, which suggests they shouldn't be settings. I think there was a misunderstanding about how libpwquality scores are intended to be used. I'd like password strength requirements to be solely configured in pwquality.conf, rather than Anaconda kickstart files. (Although it might be reasonable to have Anaconda write pwquality.conf based on the settings in its kickstart.) See https://lists.fedoraproject.org/pipermail/desktop/2015-March/011776.html
I have submitted a [https://github.com/rhinstaller/anaconda/pull/59 pull request] to anaconda upstream to re-enable the double-click override as FESCo decided upon.
When I spoke to the anaconda devs yesterday, they were amenable to this as a temporary solution in Fedora 22, provided that we move ahead with a distro-wide policy for Fedora 23.
Replying to [comment:49 sgallagh]:
I have submitted a [https://github.com/rhinstaller/anaconda/pull/59 pull request] to anaconda upstream to re-enable the double-click override as FESCo decided upon. When I spoke to the anaconda devs yesterday, they were amenable to this as a temporary solution in Fedora 22, provided that we move ahead with a distro-wide policy for Fedora 23.
What is the status of the request? we are in Final TC stage. do we have a suitable solution? can this ticket be closed? or does this need discussed at the meeting?
Now that Fedora 22 has been released, can we close this ticket?
closed
It's worth noting that we still need to come up with a distro wide password policy and ask everyone to follow it. The revert of this change in anaconda was only for fedora 22.
I don't think the Workstation folks and the Server folks are likely to agree on a distro-wide policy. What we could agree on is a place where the policy which all password-setting software in the distro must adhere to shall be defined (pwquality.conf would be ideal for us, but only if pwquality is changed to accept lower minimums: the most lenient policy configurable right now is still too strict for us).
I've previously noted my objection to the anaconda change in comment 48.
Replying to [comment:54 catanzaro]:
I don't think the Workstation folks and the Server folks are likely to agree on a distro-wide policy.
I think that's overstated. I'd prefer that we try before declaring failure.
What we could agree on is a place where the policy which all password-setting software in the distro must adhere to shall be defined (pwquality.conf would be ideal for us, but only if pwquality is changed to accept lower minimums: the most lenient policy configurable right now is still too strict for us).
Standardizing on pwquality.conf seems sensible regardless of whether Server and Workstation diverge. It'll be easy to handle such a divergence as well (using the Per-product config guidelines).
Login to comment on this ticket.