Bug 1005313 - Dictionary words with common misspellings or txtspk are accepted as secure
Dictionary words with common misspellings or txtspk are accepted as secure
Status: NEW
Product: Fedora
Classification: Fedora
Component: libpwquality (Show other bugs)
rawhide
All Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-06 12:00 EDT by Hubert Kario
Modified: 2016-07-20 05:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 15:27:05 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-09-06 12:00:52 EDT
Description of problem:
If a dictionary word is misspelled or has some txtspk changes applied to it, pwscore accepts it as secure password.

Version-Release number of selected component (if applicable):
libpwquality-1.2.2-4.fc20.x86_64
cracklib-2.9.0-5.fc21.x86_64

How reproducible:
Always

Steps to Reproduce:
cat > wordlist  <<_EOF_
NQZwmFqiaoEKJskJ
TDGlHmirsfMduVYp
SLLWqadcaRWQRxZm
DzUHkSakMcxhAqOG
WxSqOLewvONQCbuy
LXlqojnoyOMGtnCa
mknqvgvujYiMEAEF
uWENgkwfCttfpeug
ezePAothenakOBuL
tlfoJApWsWIVFxWs
RXEyPyHZbsRKGway
IczROkAHzccEwcks
IvPaObUyTtlOVEnx
SkXpMjiHMwfWncBy
_EOF_
create-cracklib-dict wordlist

use pwscore to test following passwords:
NQZwmFquaoEKJskJ
TDGlHmilsfMduVYp
SLLWqadkaRWQRxZm
DzUHkSacMcxhAqOG
WxSqOLewvONQCbuee
LXlqojnuyOMGtnCa
mknqvgvoojYiMEAEF
uWENgkwphCttfpeug
ezePAotehnakOBuL
tlfoJApWsWIVFxWzz
RXEyPyHZbsRKGwei
IczROkAHzccEwxx
IvPaObUyTtlOVEnks
SkXpMjiHMwfWncBi

Actual results:
All accepted as secure (95-100 score)

Expected results:
All rejected as based on dictionary words

Additional info:
Applied substitutions are:
 girl → gurl
 r → l
 c → k
 k → c
 -y → -ee
 o → u
 u → oo
 f → ph
 the → teh (this should be generalized to any pair being swapped)
 -s → -zz
 -ay → -ei
 -cks → -xx
 -x → -ks
 -y → -i
Comment 1 Tomas Mraz 2013-09-06 12:12:32 EDT
I am really eagerly awaiting patches that implement this functionality in cracklib. :)
Comment 2 Tomas Mraz 2013-09-06 12:13:01 EDT
Perhaps it would be also good to work with cracklib upstream on this.
Comment 3 Hubert Kario 2013-09-06 12:40:18 EDT
(In reply to Tomas Mraz from comment #1)
> I am really eagerly awaiting patches that implement this functionality in
> cracklib. :)

I won't say it isn't tempting, but I have other a bit more interesting project on the back burner ;)

So, not this year.

(In reply to Tomas Mraz from comment #2)
> Perhaps it would be also good to work with cracklib upstream on this.

I agree, I'll try to contact them next week or the week after.

How does:
 * new API that would allow to set the required entropy in password in a runtime manner
 * ability to set the required password complexity in old API to (at least) NIST SP 800-63-1 Level 1, Level 2 or some specified entropy + the size of lee-way between the required and guessed entropy where it's still ok to accept or reject password[1].

sound for the initial requirements?

or would you rather see them agree that they don't want to let through Level 1 passwords, still no configuration and implementing the higher entropy req. in libpwquality?


 1: I think we can all agree that rejecting a password with higher (real) entropy than the minimum isn't really, really wrong, but if a password with 30 bits of entropy is rejected in a 14 bit limit, then I'd say it's a bug. I'd like us to agree on the acceptable difference between real and estimated where it's not yet a bug (like rejecting a 16bit password with 14bit limit).
Comment 4 Jaroslav Reznik 2015-03-03 10:02:41 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 5 Fedora End Of Life 2016-07-19 15:27:05 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 6 Hubert Kario 2016-07-20 04:13:12 EDT
reproducible with libpwquality-1.3.0-4.fc24.x86_64

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