For the 2015-Jul-01 meeting as the Change Proposal was announced on devel-announce list on 2015-Jun-23.
Currently a number of places ask users to set passphrases/passwords. Some of them enforce some kind of rules for passphrases/passwords, others different rules. This change would create a common base policy for as many of these applications as possible, allowing for local users or products to override this base in cases they need to do so.
Proposal looks good but the policy should be able to allow customization for setting weaker passwords.
I'm confused. Are we approving the idea of the policy here, or are we supposed to wait until said policy is actually drafted? The Change doesn't actually specify a policy at all. I'd rather wait and approve that.
You are right. We do require actual policy draft before approving this Change.
Replying to [comment:5 jkurik]:
Is there any draft? I was unable to find one. If not, the meeting keyword should be removed until there is something to discuss.
Thanks!
There is not yet a draft, I am working on getting all the maintainers of the affected components together so we can make one.
There is two parts to this change:
Creating a draft policy, getting feedback and then getting fesco approval of it.
Making changes to components to meet the policy.
I was hoping the change could be approved now as a "yes, fesco is ok with moving forward with this" and we could address the draft as soon as we have one.
In the event there is no draft or it's not approved in time, the change would be dropped for this release.
In the event the draft is approved, but the changes to components isn't completed, this change could be dropped for this release.
Thoughts? perhaps we could discuss in next meeting?
Replying to [comment:7 kevin]:
There is not yet a draft, I am working on getting all the maintainers of the affected components together so we can make one. There is two parts to this change: Creating a draft policy, getting feedback and then getting fesco approval of it. Making changes to components to meet the policy. I was hoping the change could be approved now as a "yes, fesco is ok with moving forward with this" and we could address the draft as soon as we have one.
You don't need FESCo permission to create a draft of anything. You're creating more hurdles for yourself. Just go work! :)
In the event there is no draft or it's not approved in time, the change would be dropped for this release. In the event the draft is approved, but the changes to components isn't completed, this change could be dropped for this release. Thoughts? perhaps we could discuss in next meeting?
I think this leads to extra hassle for everyone. Why don't we just wait to approve it when the draft is available? Then we don't have to worry about forgetting to drop it if the draft isn't ready.
And if we do approve a draft, it might be better to rephrase the Change as an on-going effort if you're worried about getting the changes in the packages done. That way we don't have to worry about forgetting to drop it if e.g. only one package didn't make it. (Besides, a default policy is going to be an on-going effort as new packages come in anyway.)
Replying to [comment:8 jwboyer]:
I am. I am just trying to avoid a "Oh, this change wasn't accepted so you must defer it to Fedora 24".
I think this leads to extra hassle for everyone. Why don't we just wait to approve it when the draft is available? Then we don't have to worry about forgetting to drop it if the draft isn't ready. And if we do approve a draft, it might be better to rephrase the Change as an on-going effort if you're worried about getting the changes in the packages done. That way we don't have to worry about forgetting to drop it if e.g. only one package didn't make it. (Besides, a default policy is going to be an on-going effort as new packages come in anyway.)
As long as FESCo is ok with approving the draft / doing the work before the change deadline thats fine with me. I will strive to get something put together soon.
For now removing the meeting keyword, when ready with draft please add it again.
ok, we have some news here:
We determined that libpwquality is probibly the best place to have a central policy for local account passphrases.
tmraz has been working on a new release of libpwquality that will:
Have a pwquality.d directory. Products or users that wish to override the distro defaults can add a .conf file in that directory.
For defaults currently, see: https://bugzilla.redhat.com/show_bug.cgi?id=1241310#c16 which is:
8 characters
Once this new version lands the items that use libpwquality via pam should be mostly set. There will still be changes needed in anaconda, and not yet sure of the status there (but will work with them to find out).
Replying to [comment:12 kevin]:
For defaults currently, see: https://bugzilla.redhat.com/show_bug.cgi?id=1241310#c16 which is: 8 characters difok1
For idiots like me, is this the value that determines the minimum number of characters that have to be different from the last password? If so, then am I interpreting it correctly that a value of 1 means just one? So:
would be valid?
difok is: "Number of characters in the new password that must not be present in the old password."
So, correct, although both those passwords fail the dictionary check:
"Password quality check failed: The password fails the dictionary check - it is too simplistic/systematic"
I'd like to make sure https://bugzilla.redhat.com/show_bug.cgi?id=865521 is included in the coversation. The current wordlist (required by libpwquality) is quite large, and I think it's of increasingly dubious value for it to be so in the modern world. My suggestion is to use a smaller, smarter wordlist instead.
libpwquality allows for setting a different path to a cracklib dictionary, so I think it makes sense to ship smaller wordlist for Cloud image. But I am not interested in removing words from the current default cracklib wordlist.
Replying to [comment:16 tmraz]:
My concern with this is that changing the dictionary introduces inconsistencies into what passes and what doesn't. NIST recommends dictionary checks only for relatively short passwords, anyway (counting it as 6 bits of guessing entropy for passwords 12 characters and below, but decreasing as password length increases). I'd really rather have a small (50,000 words -- the 10k common password list plus most common words in common languages) default dictionary and make the huge list optional.
libpwquality allows for setting a different path to a cracklib dictionary, so I think it makes sense to ship smaller wordlist for Cloud image.
Can’t we agree on a better way to choose what the default dictionary set is than what we have space for? I.e. ''any'' other way?
It’s a pretty sure bet that the dictionary sizes chosen based on disk space available will not be correct, and both of the failure modes are pretty absurd:
“Sorry we have allowed uninformed users choose weak passwords and got your system compromised, we didn’t want to increase the image size by 9 MB.” “Sorry we are annoying you with too harsh dictionary requirements, we have enough space to be that harsh so we are.”
Except I do not think we can agree what is the appropriate wordlist size. It's quite a bit a bikeshed choice. And it really depends on what you consider as an attack vector. If the vector is local login only via gdm/console or remote ssh login with some throttling then the dictionary size can be quite small. But when considering cracking local password hashes I'd rather use as large dictionary as possible.
Also I've never seen any reports from users that they are annoyed with the current large dictionary as it would prevent them to use their favourite long word which they "think" that would be uncrackable by attacker.
Can’t we agree on a better way to choose what the default dictionary set is than what we have space for? I.e. any other way?
I don't think I'm suggesting that. I'm saying that a very large wordlist does not add a lot of value. Consuming a lot of space "because security!" doesn't make sense. We should obviously select the contents of that list intelligently.
The NIST guidelines suggest a 50,000 word dictionary. We currently have 1,797,746 unique, case-insensitive words.
From http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf:
''Either dictionary tests or composition rules eliminate some passwords and reduce the space that an adversary must test to find a password in a guessing or exhaustion attack. However they can eliminate many obvious choices and therefore we believe that they generally improve the “practical entropy” of passwords, although they reduce the work required for a truly exhaustive attack. The dictionary check requires a dictionary of at least 50,000 legal passwords chosen to exclude commonly selected passwords.''
Note that space isn't the only concern: using a dictionary actually reduces brute force entropy. For a small list, it "improves the 'practical entropy'"; as the list gets huge, we're actually making things worse (not just inconvenient for users trying to come up with something that passes).
Also, unless I'm missing something, a lot of the existing wordlists appear to be used incorrectly. For example, the list in "names.hp" consists of a number followed by the name; the list is clearly intended to be actually the name, with the number being some kind of count or score, but instead each of these is used as if that whole line is the dictionary entry. :-/
Another data point: of the list of 10,000 most common passwords on the Internet from the research linked in the bug, only thirteen pass libpwquality's basic validation and score above 50 with existing dictionary test completely disabled.
(And only one is above 75 -- "films+pic+galeries", which somehow made #4372 on the list.)
The NIST recommendation is to use only a dictionary of words which would otherwise pass basic tests, so maybe that's a reasonable way to cull the list.
So it looks like Workstation is planning to disable dictionary checks entirely at least when sshd is not running. This basically makes my concern about different policies in different situations irrelevant, because I guess we're doing that anyway.
Given that, for the cloud image and containers and whatever else, simply packaging cracklib-small separately seems sufficient. (That's a list of around 50k words.)
I still think some sanity could be brought to the wordlists, but that's a separate issue (and definitely not size-driven).
Replying to [comment:24 mattdm]:
So it looks like Workstation is planning to disable dictionary checks entirely at least when sshd is not running.
(This should be a decision pwquality configuration makes; not hard-coded anywhere; it would be bad if the only way an admin could change this policy were to replace Workstation with a different product, or even worse by locally patching out a hard-coded policy.)
IIRC Tomáš is right; the complaints were not about the size of the dictionary but about the “reach” every dictionary word has by applying various edit/substitution rules, which prohibit various prima facie random-looking passwords.
I vote for no password requirement/restriction at all.
Since when does linux forcefully hold the users hand? If a system administrator wants to set a password complexity requirement, that's fine, give them the ability to do that. It used to be you could click the continue button twice to use an unsafe password. Now, it just feels broken, stuck on a page where you can do nothing else until you enter a "complex password". I don't always need a complex password, which just makes this requirement a pain and a hassle and an annoyance. How often does a developer or sysadmin install a temporary/one-time-use VM with a quick and easy password. This is not a password for a public website where some company needs to worry about the security of their own servers. This is an operating system I'm installing on my own system which I alone am responsible for.
You can still set whatever password policy you want on your own system. That's not in dispute.
As a distribution, we have a responsibility to set a sane and reasonably-secure default. That's what this policy is for. There are different, reasonable viewpoints about the tradeoffs between user convenience and security (and sanity). If you have points to make about those, that's great. But emotional arguments about "forced hand holding" and "when has linux ever" aren't really helpful.
My point is what I experience when installing the OS. I'm on the page where I set my password, I click the "Done" button, nothing obvious happens. I mash the button, nothing obvious happens.. Only a small warning bar at the bottom telling me to use a more complex password. If I wasn't determined to use it, you'd almost turn me away before it even installs. What about a dialog box that asks "Let me enter a better password" or "Generate a password for me" or "Just let me use my easy password at my own risk". Three buttons that give me a choice, no forcing.
This isn't the place for ananconda UI design IMHO, but yes, I already discussed that with mizmo a while back and she had some good ideas. I definitely want to see the double-done go away, but still allow people to override.
Anyhow, back to the topic here:
I'd like to propose:
Default local policy (as shipped by libpwquality):
note that this only applies to local passwords/passphrases.
I agree about this not being the place for specific UI design, but maybe the policy could also recommend the use of a "ambient password strength meter" when possible? I think this is in line with current best practices (see e.g. http://blog.codinghorror.com/your-password-is-too-damn-short/), and avoids the circus of trying something, getting denied, guessing at rules, getting angry, etc.
Replying to [comment:31 mattdm]:
That would definitely be getting into UI design. I'd prefer that we keep this policy restricted to '''must''' statements and avoid '''should''' statements at all. The user experience discussion should happen, but not here.
I'm +1 to the policy exactly as Kevin proposed it.
I follow a practice that makes me the outlier. What I did is the following when I was in a large shop.
I would give the installation flashdrive to a stagière (summer student). He was told to use abcdef as the anaconda root and he was given the admin's name. He could choose the admin's password.
On a reboot, I would log into the just installed system and change root's password and that of the admin. The individual doing the installation was thus immediately removed from system access.
I would like to have anaconda provide an option to set the root and admin password to expired. On a first reboot immediately following anaconda installation the actual root and and admin passwords would be demanded. Perhaps password expiry could be provided as an optional setting within anaconda's password interface. Lets have
[x]] Force Password expiry for this logon
within anaconda.
Please feel free to file a RFE with anaconda for that. I don't think it's something that should be in the base default passphrase policy.
AGREED: Change is accepted. (+7,0,0) (nirik, 18:27:26)
I have created a draft page, would appreciate everyone looking it over:
https://fedoraproject.org/wiki/Passphrase_policy
It also occurred to me that we didn't mention the luks passphrase requirements (if they are the same as the rest or not). So, perhaps discuss that next week.
AGREED: : Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+7, 0, 0)
Also, Kevin is going to file all the needed bugs for this change.
The tracking bug for this Change is [https://bugzilla.redhat.com/show_bug.cgi?id=1250936 #1250936].
Hi, I want to point out that we are remain unable to implement the "root / admin users should be able to override quality checks (for purposes of this, the installing user is root/admin)" and "applications may use the libpwquality 'score' to display an analog strength meter to users as an informational tool, but should not use score as a decision making factor for acceptance" portions of this policy in Workstation, specifically gnome-initial-setup and gnome-control-center, due to pam_pwquality, which still rejects weak passwords. Anaconda was able to implement because it doesn't go through PAM. But GNOME shells out to passwd to hook into the existing audit infrastructure.
The problem is pam_pwquality has no idea whether the user is the "installing" user or not. We could add an option to pam_pwquality that would make all the checks just informative and non-blocking - basically it would behave for all users as for the root user currently. However this option cannot be on by default and it is questionable whether it would help in this situation - as for other users created on the workstation it might be unwanted to make the pam_pwquality checks non-blocking.
Another option would be to make pam_pwquality informative for members of wheel group or some another group set by pam_pwquality option (it could be the primary group of the installing user). However something would have to edit the password-auth/system-auth files to set this option for pam_pwquality.
Or there is another possibility - someone - Server WG or FESCo can decide, that the enforcement of strong passwords even on regular user password change should not be on-by-default and we can modify the pam_pwquality and the default PAM configuration so it would not enforce (just warn) the weak password check.
Login to comment on this ticket.