Hide Forgot
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
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. 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).
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
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.
reproducible with libpwquality-1.3.0-4.fc24.x86_64
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