Bug 985356

Summary:	Passwords with current year/date are accepted as secure
Product:	[Fedora] Fedora	Reporter:	Alicja Kario <hkario>
Component:	libpwquality	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	stephent98, tmraz
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-12-20 15:15:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alicja Kario 2013-07-17 10:41:58 UTC

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.

Comment 1 Tomas Mraz 2013-07-17 14:42:13 UTC

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.

Comment 2 Alicja Kario 2013-07-17 15:12:14 UTC

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.

Comment 3 Fedora End Of Life 2013-09-16 14:34:55 UTC

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

Comment 4 Fedora End Of Life 2015-05-29 09:11:19 UTC

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.

Comment 5 Tomas Mraz 2018-12-20 15:15:08 UTC

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