Anaconda 22.17+ enforces "good" passwords

Hubert Kario hkario at redhat.com
Fri Feb 13 11:00:03 UTC 2015


On Thursday 12 February 2015 17:09:56 Chris Murphy wrote:
> I don't have an easy way to prove this, but in a millions+ attempt
> brute force attack, I find it difficult to believe that
> correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted.
> I had recently read that up to 100 character dictionary only word
> based passwords were routinely attempted in brute force attacks.

yes, it's rather well known that there are... deficiencies in the way 
libpwquality scores passwords:
https://bugzilla.redhat.com/show_bug.cgi?id=983187
https://bugzilla.redhat.com/show_bug.cgi?id=985463
https://bugzilla.redhat.com/show_bug.cgi?id=970222
https://bugzilla.redhat.com/show_bug.cgi?id=985411
https://bugzilla.redhat.com/show_bug.cgi?id=1005313
https://bugzilla.redhat.com/show_bug.cgi?id=985356
https://bugzilla.redhat.com/show_bug.cgi?id=985364
https://bugzilla.redhat.com/show_bug.cgi?id=1005276

and then cracklib (which is used for the dictionary part of check) has few 
bugs still:
https://bugzilla.redhat.com/show_bug.cgi?id=963769
https://bugzilla.redhat.com/show_bug.cgi?id=986400
https://bugzilla.redhat.com/show_bug.cgi?id=985378
https://bugzilla.redhat.com/show_bug.cgi?id=1146814

I'm all for the change in question (no bad passwords accepted by Anaconda), 
but for that we *first* need:
 - libpwquality that has at least a 0.1% rate of false positives, if not lower
 - generator for good passwords that will pass the above checks and are easy 
   to remember (something that generates "horse battery"-like passwords) and 
   presents them to the user if he or she has problem entering the password


What many people forget is that NIST SP 800-63-1 *doesn't* specify that 
passwords have to be 6 or 8 character long with such-and-such character 
classes. It says that passwords have to have 10 or 14 bits of *entropy*. It 
also *requires* rate limiting for the logons. Current password checkers can't 
even approximate that, let alone check properly.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/security/attachments/20150213/a9858370/attachment.sig>


More information about the security mailing list