Description of problem: Password based on dictionary word with simple addition are accepted as secure. If I pick a dictionary word and add current date or year the password is accepted and given high security rating. Version-Release number of selected component (if applicable): libpwquality-1.2.2-2.fc20.x86_64 cracklib-2.9.0-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: echo abnegating2013 | pwscore echo abnegating2010 | pwscore echo abnegating1980 | pwscore echo abnegating0717 | pwscore echo abnegating1707 | pwscore Actual results: [root@localhost ~]# echo abnegating2013 | pwscore 81 [root@localhost ~]# echo abnegating2010 | pwscore 81 [root@localhost ~]# echo abnegating1980 | pwscore 81 [root@localhost ~]# echo abnegating0717 | pwscore 78 [root@localhost ~]# echo abnegating1707 | pwscore 81 Expected results: Password quality check failed: The password fails the dictionary check - it is based on a dictionary word for first two and low security rating for the latter three. Additional info: The accepted password have very low guessing entropy. Assuming 10bit entropy for the base password -- in line with NIST SP 800-63-1 -- we get: The password with current year will have 11bits of guessing entropy - the user followed the "add current year" rule which adds 1 bit of entropy. Password with recent year (last 8 years) will have around 13 bits of guessing entropy - very likely password reuse from some earlier system. Password with a year in this or past century is likely the birth year of the user, the estimate of last 50 years gives a password with 15.5 bits of guessing entropy -- enough for Level 1 system, but definitely should not be marked as strong (score > 50). Password with a date will have around 18.5 bits of guessing entropy -- enough for a Level 1 system, but, again, should not be marked as strong.
I am sorry but I disagree with this assessment of entropy estimate. You cannot add only one bit of entropy per rule "add a current year". All of these passwords should pass the basic checks. Maybe the security rating should be lower.
Adding current year is exactly what users tend to do, and this is what people cracking passwords try first. If it's one of the first rules that is used, it has minimal guessing entropy => gets 1 bit estimate. See https://www.owasp.org/images/a/af/2011-Supercharged-Slides-Redman-OWASP-Feb.pdf slide 36 for examples. RockYou list is also full of examples with recent year (as of the leak date), few statistics: $ wc -l rockyou.txt # no duplicates 14344391 rockyou.txt $ grep 2010 rockyou.txt | wc -l 11435 $ grep 2009 rockyou.txt | wc -l 13212 $ grep 2008 rockyou.txt | wc -l 26406 $ grep 2007 rockyou.txt | wc -l 32683 $ grep 2006 rockyou.txt | wc -l 30519 $ grep 2005 rockyou.txt | wc -l 22504 $ grep 2004 rockyou.txt | wc -l 15977 $ grep 2003 rockyou.txt | wc -l 14179 $ grep 2002 rockyou.txt | wc -l 13305 $ grep 2001 rockyou.txt | wc -l 13443 $ grep 2000 rockyou.txt | wc -l 17056 So, over 1% of passwords have "recent year" in them.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
We are not going to pursue this RFE at this point. If anyone wishes to work on this I'd suggest creating pull request on libpwquality upstream. https://github.com/libpwquality/libpwquality