Bug 985378 - Some complex passwords are rejected as insecure due to removal of special characters
Some complex passwords are rejected as insecure due to removal of special cha...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: cracklib (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-17 07:14 EDT by Hubert Kario
Modified: 2015-05-29 05:16 EDT (History)
5 users (show)

See Also:
Fixed In Version: cracklib-2.9.1-2.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-29 05:16:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hubert Kario 2013-07-17 07:14:20 EDT
Description of problem:
Passwords based on dictionary word with addition of random special characters are rejected as insecure and based on dictionary word.

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 'abnegating:-%' | pwscore
echo 'abnegating]+~' | pwscore
echo '\{^abnegating.*`' | pwscore

Actual results:
[root@localhost ~]# echo 'abnegating:-%' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
[root@localhost ~]# echo 'abnegating]+~' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
[root@localhost ~]# echo '\{^abnegating.*`' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word

Expected results:
High score values (>50)

Additional info:
Assuming 10 bits of guessing entropy for the base password, the passwords have following complexity:
 * abnegating:-% - 25 bits - NIST SP 800-63-1 Level 2 password
 * abnegating]+~ - 25 bits - Level 2 password
 * \{^abnegating.*` - 40 bits - Level 2 password

The rule used was "pick a random special character, append to base password", every iteration provides around 5 bits of guessing entropy.
Comment 1 Steve Tyler 2013-08-31 13:56:43 EDT
See also, Bug 1003169, Comment 4. A script to generate complex passwords that are rejected by pwscore follows:

[Copied from Bug 1003169, Comment 6]
Jacek Wielemborek 2013-08-31 17:10:41 UTC

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
Comment 2 Steve Tyler 2013-08-31 14:08:44 EDT
Here are a few examples generated by the script in Comment 1:

$ echo 'federalistsdefaults[bramsplayhousessunstroke:onnevilleunzippingrretchens' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is too simplistic/systematic

$ echo 'excisedlhristendomdisciplinedsupernovaewesternersbipedsgablesturdily' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is too simplistic/systematic

$ echo ':orodinflouts]ackcoauthortalonsbuttonedcappuccinosenticingly' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is too simplistic/systematic

$ rpm -qf `which pwscore`
libpwquality-1.2.2-1.fc19.x86_64
Comment 3 Steve Tyler 2013-08-31 15:05:24 EDT
Here is an even more extreme example with 32 words:

$ echo 'rest china stuart cdc abbott nc augur melt ww chalk onward keyed keith loath spay beep gabon ibid have cowry entry 2345 fum polio pivot den froze exult macon yv store elfin' | pwscore
Password quality check failed:
 The password fails the dictionary check - it is too simplistic/systematic

Generated with a custom Python script and the diceware[1] English word list:

$ while true; do sen=$(./rsen.py < diceware_en.lst); pws=$(echo $sen | pwscore 2>&1); echo "$sen: $pws" ; done | grep failed


[1] http://world.std.com/~reinhold/diceware.html

$ wc -l diceware_en.lst
7776 diceware_en.lst
Comment 4 Steve Tyler 2013-09-02 07:07:52 EDT
> Summary: Complex passwords are rejected as insecure → Complex passwords are rejected as insecure due to removal of special characters

The examples in Comment 2 and Comment 3 do not have special characters, so why was the bug summary changed?

Or do we need yet another bug against libpwquality?
Comment 5 Tomas Mraz 2013-09-02 07:26:02 EDT
I used bug 1003169 for the other case.

These are different causes.
Comment 6 Steve Tyler 2013-09-02 07:52:10 EDT
(In reply to Tomas Mraz from comment #5)
> I used bug 1003169 for the other case.
> 
> These are different causes.

OK. Then I would suggest changing "complex" to "some" in the bug summary:[1]

some passwords are rejected as insecure due to removal of special characters
^^^^

Hubert: Thanks for opening this bug. Did you have a precise definition for "complex" in mind when you opened this bug?

[1] $ echo 'ECg)N:}5Yz/N,%((zqNkn2#bp?xLLk)N' | pwscore
100
Comment 7 Hubert Kario 2013-09-03 06:30:28 EDT
(In reply to Steve Tyler from comment #6)
> 
> OK. Then I would suggest changing "complex" to "some" in the bug summary:[1]
> 
> some passwords are rejected as insecure due to removal of special characters
> ^^^^

I've added the "some" to summary, but I'd argue that this is implied in all the bug reports against cracklib/libpwquality

> Hubert: Thanks for opening this bug. 

No problem, I'm working on more thorough test matrix for cracklib/libpwquality so you can expect more reports :)

> Did you have a precise definition for
> "complex" in mind when you opened this bug?
> 
> [1] $ echo 'ECg)N:}5Yz/N,%((zqNkn2#bp?xLLk)N' | pwscore
> 100

I consider passwords that have above around 20-25 bits of guessing entropy to be complex. Any system that requires more than 20 bits of security shouldn't be using passwords as the sole authentication mechanism anyway (see NIST SP 800-63-1 requirements for Level 3 and Level 4 systems).

That being said, I'd like to be able to set the bar at 30 bits and more, but that may be "unsupported". There's also the problem of using libpwquality as a password quality checker for disk encryption... (the NIST document applies only to online attacks). Considering current GPGPU market and cloud computing, password with 32 bits of entropy for disk encryption in an offline attack scenario is more akin to a post it note with "please, don't look inside" on it...
Comment 8 Steve Tyler 2013-09-03 09:41:48 EDT
Thanks, Hubert. That all sounds good. The password quality functionality definitely needs some QA ... :-)

> Considering current GPGPU market and cloud computing, password with 32 bits of entropy for disk encryption in an offline attack scenario is more akin to a post it note with "please, don't look inside" on it...

Good point. ISTM, pwscore should have an option to specify the required password strength in bits of entropy. I can open an RFE, if you agree.

The 0 to 100 scoring doesn't seem to have any relation to bits of entropy.
Can you suggest a better scoring method?
(Another RFE?)
Comment 9 Hubert Kario 2013-09-03 10:01:28 EDT
(In reply to Steve Tyler from comment #8)
> > Considering current GPGPU market and cloud computing, password with 32 bits
> > of entropy for disk encryption in an offline attack scenario is more akin
> > to a post it note with "please, don't look inside" on it...
> 
> Good point. ISTM, pwscore should have an option to specify the required
> password strength in bits of entropy. I can open an RFE, if you agree.
> 
> The 0 to 100 scoring doesn't seem to have any relation to bits of entropy.
> Can you suggest a better scoring method?
> (Another RFE?)

I did open a RFE for configuration in line with the NIST document, that requires the ability to measure password quality in bits, see bug 983187. The RFEs you talk about seem to me as prerequisites to the one I submitted. If you still think that they are useful, please mark them as blocking 983187.
Comment 10 Steve Tyler 2013-09-03 10:18:58 EDT
(In reply to Hubert Kario from comment #9)
...
> I did open a RFE for configuration in line with the NIST document, that
> requires the ability to measure password quality in bits, see bug 983187.
> The RFEs you talk about seem to me as prerequisites to the one I submitted.
> If you still think that they are useful, please mark them as blocking 983187.

So you did:
Bug 983187 - [RFE][usability] Allow for easy configuration in line with NIST SP 800-63-1 

Tomas changed the component of this bug to cracklib, so I was looking at the cracklib bugs instead of the libpwquality bugs ...
Comment 11 Fedora End Of Life 2013-09-16 10:35:17 EDT
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 12 Fedora End Of Life 2015-05-29 05:11:25 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.