Red Hat Bugzilla – Bug 1005313
Dictionary words with common misspellings or txtspk are accepted as secure
Last modified: 2016-07-20 05:08:15 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):
Steps to Reproduce:
cat > wordlist <<_EOF_
use pwscore to test following passwords:
All accepted as secure (95-100 score)
All rejected as based on dictionary words
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
I am really eagerly awaiting patches that implement this functionality in cracklib. :)
Perhaps it would be also good to work with cracklib upstream on this.
(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.
* 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.
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).
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:
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
Thank you for reporting this bug and we are sorry it could not be fixed.
reproducible with libpwquality-1.3.0-4.fc24.x86_64