Description of problem: In Fedora Workstation, we expect passwords to be used to provide good security against nontechnical human beings with physical access to the computer, physically typing away at the keyboard. By default, they aren't intended to protect against sophisticated adversaries. We therefore want to allow users to set much weaker passwords than are currently permitted by libpwquality, since longer passwords don't provide any practical benefit to most of our users. Examples of acceptable passwords include "berlin," "wombat," and "butter." Any of these would work great at keeping out a human typing on the keyboard. Currently, we aren't willing to use libpwquality to enforce password strength in gnome-initial-setup due to its strictness. We are trying to remove the password strength enforcement from gnome-control-center as well, to match gnome-initial-setup, but are foiled due to libpwquality's PAM module -- hence we've been considering either removing the libpwquality PAM module or going around PAM entirely. The disadvantage of either approach is that it would then be much harder to configure Workstation to enforce password strength in environments that really do need a password strength check (e.g. corporate deployments or computer labs, which we want to support but not optimize for), whereas ideally enforcing stricter passwords would be as easy as editing pwquality.conf. So ideally we would just change the defaults in Workstation to be much more permissive; then we could enforce them in gnome-initial-setup and continue enforcing them in gnome-control-center. I see a few problems with the current defaults: * The default setting of difok in pwquality.conf is currently 5. This seems to be responsible for much frustrating when seemingly-good passwords are rated as weak. I'd like to try 1. * The current default setting of minlen in pwquality.conf. It's currently 9. I've faced much resistance to the idea of any enforced password length at all. I think 6 (the minimum possible) is a reasonable limit, but it's kind of pointless. I'd prefer to lower this. * cracklib integration should be disabled by default. We don't want to prevent users from using English words as passwords. These defaults might not be appropriate for other Fedora products, hence I suggest the creation of product-specific configuration files if the Server folks want stricter password strength requirements. I believe the Cloud folks don't care. Bonus points if we could simultaneously have two separate pwquality configurations: one for local accounts (allowing the weak passwords), and one stronger configuration (maybe stricter than the current default) for network passwords. Example use cases: we could use the stricter configuration for checking passwords submitted to web sites before allowing users to remember the password in Web; we could automatically switch to the stricter configuration for enterprise login; we could automatically switch to the stricter configuration when remote access is enabled.
So, just to be clear here: This is the official position of the Workstation Working group? Some thoughts: 1. Do we really want to train people that "its ok to use a weak password here, but not there"? What if they get confused which is which? Wouldn't it be better to get them to use somewhat more secure stuff everywhere especially since currently (and all the time in the past) we didn't allow weak passwords? 2. If they can use 'berlin' and 'wombat' is it really that much harder to use 'berlin wombat' ? 3.Yes, I am looking at pwquality config to be the one place to change things and yes, we could look at a workstation specific config, but it would sure be nice not to have to. ;) 4. difok should only happen when changing passwords and there's an old one. There is no enforced password changing so are people really hitting that one very often?
(In reply to Kevin Fenzi from comment #1) > So, just to be clear here: This is the official position of the Workstation > Working group? Hm, I wouldn't say that. We can discuss this specific text at our next meeting if you want. Based on our last password-related meeting, I'm comfortable saying the official position is "libpwquality should accept weaker passwords than currently." The full text of our last meeting on this topic is at [1] (discussion starts at 15:16:04) so you can get an idea of where everybody stands. > 1. Do we really want to train people that "its ok to use a weak password > here, but not there"? What if they get confused which is which? Wouldn't it > be better to get them to use somewhat more secure stuff everywhere > especially since currently (and all the time in the past) we didn't allow > weak passwords? If we want to train people to use passwords that are safe for the Internet, where they're regularly stored as unsalted MD5 hashes which attackers routinely gain access to, we're going to need to bump up the requirements to be dramatically greater than the currently are. What I want to do is train people to use long randomly-generated passwords on the web, stored in a password manager (Firefox Sync is a good one). If you can remember your password it isn't strong enough. That doesn't work for a PC where you have to be able to remember your password to log in. :) > 2. If they can use 'berlin' and 'wombat' is it really that much harder to > use 'berlin wombat' ? Personally, I don't think it's much harder, but I also don't think there's any point to enforcing it since in practice the longer password is not actually going to make you safer. Others feel more strongly about this than I do. :) > 4. difok should only happen when changing passwords and there's an old one. > There is no enforced password changing so are people really hitting that one > very often? The problem is that it is enforced when you do change your password (in gnome-control-center), and it's silly to require password strength to be much greater the second time a password is set. [1] http://meetbot.fedoraproject.org/fedora-meeting/2015-04-01/workstation.2015-04-01-15.00.log.html
In my limited testing of libpwquality while I was working on gnome-initial-setup, I was unable to find any password it would rank as anything but the absolute weakest, outside of running its own password generation tool. And I tried passwords like "##r3dh4t%%", or "correct horse battery staple", or otherwise. I have no idea what it wants from me, and the error messages it gives aren't very helpful. More context here: https://bugzilla.gnome.org/show_bug.cgi?id=735578
Well, those both sure seem fine to me: % echo "##r3dh4t%%" | pwscore 35 % echo "correct horse battery staple" | pwscore 100 My understanding is basically that anything over 0 is ok, less than 0 is "not ok" and higher "score" is "better". (Note: I am not a pwquality maintainer).
Read the linked bug report. Anaconda, and thus g-i-s / g-c-c, treat any password with less than a score of 50 as poor quality. The xkcd password was around 10 when I last tried it, but it seems that has been fixed.
Yes, I am completely aware of that. I was talking about what libpwquality considers acceptable (anything over 0).
OK, so what you're suggesting is that we should fix Anaconda to accept anything over 0? I would be OK with that, but the bar between 0 and 1 seems to be extremely low, I'm not sure what we're getting for that. See also: https://lists.fedoraproject.org/pipermail/security/2015-February/002075.html
(In reply to Jasper St. Pierre from comment #7) > OK, so what you're suggesting is that we should fix Anaconda to accept > anything over 0? Yes, that's a given. > I would be OK with that, but the bar between 0 and 1 seems > to be extremely low, I'm not sure what we're getting for that. In that case... this has all been a huge miscommunication? We are only considering lowering the bar between 0 and 1. pwquality does not fail passwords with strength >0, nor does g-c-c nor would g-i-s. 1 is the weakest acceptable password. That Anaconda thinks differently is an unrelated Anaconda bug. (Actually, anaconda allows configuring this nowadays, but that's silly: pwquality.conf is where the configuration should take place.) You say 1 is weak enough for you, so that implies we're good? Matthias? Kalev?
The GNOME bug report always suggested to match what Anaconda is doing. I just tried out a few more passwords, and all the ones I thought of were rejected, so I'm not super pleased, especially when it mostly gives me "based on a dictionary word" (of course it is! I'm trying to remember it!), so I'm not overly pleased, but I'll live. Isn't pam_pwquality similarly configured to reject passwords with a quality below 50?
Note: I am talking to pam/passwd and anaconda folks out of band. Lets wait until we have a proposed policy here so we can see if it will meet your needs or not. :)
OK. From my two seconds of testing, I've come across this: jstpierre@jstpierre-lappy ~ $ echo 's3cur43' | pwscore Password quality check failed: The password fails the dictionary check - it is based on a dictionary word jstpierre@jstpierre-lappy ~ $ echo 's3cur42' | pwscore 1 jstpierre@jstpierre-lappy ~ $ echo 's3cur41' | pwscore 0 Michael and I were both under the impression that 0 meant "failure / error", but it seems this isn't the case. Notice the strange and random deviations in password quality values for passwords I would consider equivalent difficulty to a cracker. Michael thinks this case is a bug. I found it almost immediately after posting the last comment. If my ten seconds of testing caused this, I'm not comfortable shipping it to a user. If we had a working password quality library, I'd be OK with it. But given how nonsensical and broken libpwquality's checker is, I'm going to suggest that Workstation does *not* mandate any minimum password score, since I can't even figure out what determines that.
I think s3cur43 is actually a bit easier to crack: start with secure, do common replacements to get s3cur3, then add a digit. But I have no clue what is up with the difference between s3cur42 and s3cur41, nor why s3cur41 was considered permissible. I have been assuming for several months than 0 meant impermissible -- I thought Tomas said this, actually -- but I guess not.
Er, also the default minlen in /etc/security/pwquality.conf is 9, which confusingly means the min possible size is 8. Those passwords are all length 7....
This is really a miscomunication. The score value in the current libpwquality scoring implementation is only indicator of approximate entropy present in the password. It should not cause rejection of a password and should be used only for things like password quality indicators for example 0-30 being less than medium quality, 30-60 medium, 60-100 strong if the caller wants to have such indicator. The reason for rejection of a password (which could be overridable in situations where the user is the one who is privileged to do the decision such as in case he is root) is only when negative value is returned (or in case of the Python bindings the exception is thrown). The reason of the error is also returned.
(In reply to Michael Catanzaro from comment #13) > Er, also the default minlen in /etc/security/pwquality.conf is 9, which > confusingly means the min possible size is 8. Those passwords are all length > 7.... Here the problem is that the minimum length check is adjusted with a bonus credits value for each class of characters used. I think we should set credits value to 0 in the default pwquality.conf so that confusion is removed.
So in the upcoming release of libpwquality I am implementing these changes: 1. change the library default for difok to 1 2. change the library default for minlen to 8 (6 is too low to be reasonable for most purposes) 3. change the library default for *credits to 0 so the confusion of the length check being adjusted with the credits bonus is removed 4. add new configuration option dictcheck with default of 1 (to allow disabling the cracklib check) 5. add support for /etc/security/pwquality.conf.d/ directory of *.conf files so products can add its own configuration - there I am still undecided whether /etc/security/pwquality.conf settings should override the settings from the conf.d or the other way around.
I guess we would want the /etc/security/pwquality.conf.d/* files to override the base one (or else we could just have the base one include the files in the directory and have default vaules in a 00-distro.conf and later files would override it?)
I decided that the base file overrides the subdirectory conf files. The base file will contain normally only the default values as comments and its purpose will be the adjustments of configuration by sysadmin. The distro conf could be in 00-base.conf. And the products can ship additional conf files. I believe the new library defaults are completely fine for the base configuration, so there should be no need for the 00-base.conf though.
Thanks, these changes seem good!