On Fri, Feb 13, 2015 at 4:00 AM, Hubert Kario <hkario@xxxxxxxxxx> wrote: > 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 Aside from the ethical problem of using coercion instead of innovative persuasion, is the consequence of a premature attempt to close this perceived weakness. Trust is hugely important in this area. I think implementing this change further damages trust by the user in Fedora decision making, and there's a recent incident of password policy change happening in the installer: https://bugzilla.redhat.com/show_bug.cgi?id=958608 https://lists.fedoraproject.org/pipermail/devel/2013-May/thread.html#182196 While I agree the minimum barrier is for the software to not behave capriciously, and for actual guidelines to appear in the UI so the user can set a minimally compliant password in a single attempt, I still don't agree it can be made compulsory without very negative consequences. The context isn't a service, it's the user's own device. Upon what line of reasoning is this power usurped from the user to the Fedora installer? Thus far it sounds like an ends justifies the means argument. Seemingly a more reasonable stick and carrot approach, is a UI that ties services to passworth strength. For example, the UI conveys sshd is disabled by default, and cannot be enabled (in the installer) until a minimum strength password is supplied. This suggests a lesser quality password is acceptable when services that raise vulnerability are disabled. But before such services can be enabled (in the installer), a stronger password is needed. Right now there is only stick. That's trust damaging, not enhancing. > > > 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. There's more than one paper floating around challenging the usefulness password entropy concept in NIST SP800-63. Actually this one uses stronger wording: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxyZXVzYWJsZXNlY3xneDozNDcwNDhmMmE2MmJiMDkw -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
