Bug 985378

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

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

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

> 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?

I used bug 1003169 for the other case.

These are different causes.

(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

(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...

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?)

(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.

(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 ...

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.