Description of problem: Version-Release number of selected component (if applicable): How reproducible: Run Fedora installer (tried that on Netinstall x86) Steps to Reproduce: 1. Try to set up an encrypted root partition 2. In the password prompt, try to enter a password that consists of a few common English words Actual results: The password is not accepted because it is "insecure", even though it contains a lot of entropy. There is no way to proceed without choosing a different password. Expected results: Installer allows me to set up an allegedly insecure password. Additional info: I believe that this security "feature" needs to allow the user to somehow walk it around - not every password that contains English words is insecure.
Thanks for your report. Could you provide a specific example?
The installer uses the pwquality Python module, which is a wrapper for libpwquality.[1] The libpwquality package includes the commands:[2] pwscore pwmake $ pwscore fedora Password quality check failed: The password is shorter than 8 characters $ pwscore fedora78 Password quality check failed: The password fails the dictionary check - it is based on a dictionary word $ pwscore fedora78 foobar 95 $ pwmake Usage: pwmake <entropy-bits> $ pwmake 0 Gus5ipeGV3b@ $ pwscore Gus5ipeGV3b@ 81 [1] $ rpm -q python-pwquality libpwquality python-pwquality-1.2.2-1.fc19.x86_64 libpwquality-1.2.2-1.fc19.x86_64 [2] $ rpm -ql libpwquality | grep bin /usr/bin/pwmake /usr/bin/pwscore
I was trying to provide you with an example, but I can't find another password that fails this way. Mine does, but I obviously can't share it with you. The interesting thing is that if I take two words from my password and add another random one, I still quite often get the error. The longest failing password I could generate this way was 30 characters long. I'll keep trying.
Okay, got one: devouterinelegantbloodthirstinesssbratwurstsheeledpivoted Enough entropy to consider it a secure password? pwscore claims it's not good enough.
Wow! If that isn't a good enough password, I am Monty Python's mother. :-) $ pwscore devouterinelegantbloodthirstinesssbratwurstsheeledpivoted Password quality check failed: The password fails the dictionary check - it is too simplistic/systematic Out of curiousity, how did you generate that?
while true; do a="`LANG=en aspell dump master | sort -R | head -n8 | tr -d '\n' | tr -d "'" | tr '[:upper:]' '[:lower]' `" ; echo "$a `echo $a | wc -c`\t`echo $a | pwscore 2>&1 | tr -d '\n' `" | grep failed; done
Not the most efficient method (and not really readable, sorry about that), but got me generating the passwords pretty quickly. The -n8 parameter lets you decide how many words you want to put into the password - it works both for small (like 2) and huge values.
Thanks. Very nice. I never would have thought to do it that way: $ LANG=en aspell dump master | sort -R | head -n8 sharp's paleontology's butterfat Janis's mauling Juarez's poked nick's There are several bugs against libpwquality for problems with its password quality evaluations: $ bugzilla query -c libpwquality -t NEW --outputformat='Bug %{id} - %{summary}' | sort -r Bug 985463 - Shifting fingers on keyboard results in accepted passwords Bug 985411 - Commonly used passwords are accepted as secure Bug 985378 - Complex passwords are rejected as insecure Bug 985364 - Passwords with simple number patterns are accepted as secure Bug 985356 - Passwords with current year/date are accepted as secure Bug 983187 - [RFE][usability] Allow for easy configuration in line with NIST SP 800-63-1 Bug 970222 - Does not accurately evaluate use of multiple dictionary words Bug 953816 - [gu_IN] missing cracklib translations. Bug 925868 - libpwquality: Does not support aarch64 in f19 and rawhide
...which is exactly why the user should have an option to ignore its suggestions and just use the password that it says it's insecure.
The installer already lets users set root and user passwords that are identified as weak by clicking Done twice in the respective configuration dialogs. FYI, I copied your script to Bug 985378, Comment 1: Bug 985378 - Complex passwords are rejected as insecure
> The installer already lets users set root and user passwords that are identified as weak by clicking Done twice in the respective configuration dialogs. Yes, and that's good. Why couldn't it let do the same with partition keys?
Created attachment 792460 [details] screenshot showing Disk Encryption Passphrase dialog with red warning icon and tooltip After entering "aaa" as the passphrase and pressing Tab, a red warning icon is displayed. The icon appears to be a button that has no effect. That would be the perfect place for a button to toggle passphrase quality detection on and off. Tested with: $ qemu-kvm -m 4096 -hda f20-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
Tomas: This bug is about the anaconda user interface not allowing the user to override the libpwquality password quality evaluation. Please change the component back to anaconda and restore the bug summary. I will open a new bug for the problem with cracklib rejecting some long passwords, if that is what you need.
I think that if the underlying cracklib problem is solved the need to override the password quality evaluation will diminish.
I believe that it just shows that you cannot rely on the checks. And provided how many pwscore bugs there are, I'd dare to say that this application is just of low quality and fixing it all will take a lot of time.
(In reply to Tomas Mraz from comment #14) > I think that if the underlying cracklib problem is solved the need to > override the password quality evaluation will diminish. No. The user should be allowed to enter a simple LUKS password as is already permitted in the root and user account configuration dialogs of the installer (Comment 10). There needs to be a *new* bug for the issue you are addressing. Please change the component back to anaconda and restore the bug summary.
Created attachment 792850 [details] screenshot showing installer Root Password configuration dialog with instructions to click Done twice to override weak password detection After entering "aaa" for the root password, the message at the bottom reads: "The password you have provided is weak: The password is a palindrome. You will have to press Done twice to confirm it." Tested with: $ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
(In reply to Steve Tyler from comment #16) ... > There needs to be a *new* bug for the issue you are addressing. ... New bug filed against cracklib: Bug 1003624 - some long passwords rejected as "too simplistic/systematic" Jacek: I can't change the component back to anaconda and restore your bug summary, but you can.
(In reply to Jacek Wielemborek from comment #7) > Not the most efficient method (and not really readable, sorry about that), > but got me generating the passwords pretty quickly. The -n8 parameter lets > you decide how many words you want to put into the password - it works both > for small (like 2) and huge values. What is important here is your idea of *doing a search* for long passwords that are rejected by pwscore. Thanks for that. You would be good at QA: http://news.gmane.org/gmane.linux.redhat.fedora.testers https://fedoraproject.org/wiki/Fedora_Release_Criteria https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Generating a secure passphrase (40+ bits of entropy) for the user if the provided password fails the check would also increase the usability (of course a warning "don't use it if somebody could have seen your screen" should also be presented). See diceware[1] and http://xkcd.com/936/ 1: http://world.std.com/~reinhold/diceware.html
Here are two use-cases for weak passwords: 1. A user does not want to give the installer a valuable password, so a weak password is configured with the intention of changing it to a strong password from the installed system. 2. For installer testing, I almost always use a weak password, because it is easier to type, and easier to remember when logging into the installed system.
(In reply to Hubert Kario from comment #20) > Generating a secure passphrase (40+ bits of entropy) for the user if the > provided password fails the check would also increase the usability (of > course a warning "don't use it if somebody could have seen your screen" > should also be presented). > > See diceware[1] and http://xkcd.com/936/ > > 1: http://world.std.com/~reinhold/diceware.html Thanks for your suggestion: Bug 1004132 - [RFE] [usability] password generator
Switching to a friendlier resolution code: anaconda will complain at you but now accepts weak passwords