On Jul 29, 2015, at 3:16 PM, Chris Murphy <[email protected]> wrote: > > On Wed, Jul 29, 2015 at 2:15 PM, Warren Young <[email protected]> wrote: >> Just because one particular method of prophylaxis fails to protect against >> all threats doesn’t mean we should stop using it, or increase its strength. > > Actually it does.There is no more obvious head butting than with > strong passwords vs usability. Strong login passwords and usability > are diametrically opposed.
Security is *always* opposed to convenience. The question is not “security or no security,” it’s “how much security?” The correct answer must balance the threats and risks. Given that the threats and risks here are nontrivial, the password quality restrictions should also be nontrivial. > The rate of brute force attack success is exceeding that of human > ability (and interest) to remember ever longer more complex passwords. You must consider offline and online attack scenarios separately. Online we have already dealt with: 50 guesses max/sec, allowing a 9-character random password to survive a million years of constant attack. Offline is an entirely separate matter, and is already addressed by /etc/shadow salting and hashing in CentOS. We know how to make it even stronger if the threat requires it: move to OTP keys, use a better KDF than SHA512, etc. > I just fired my ISP because of the asininity of setting a 180 > compulsory expiration on passwords. Good for you. Password expiration is silly. A good strong password should last years under any reasonable threat. But we’ve not been talking about password expiration here. > The highest risk, by a lot, is from a family member. Of course. It’s why Bruce Schneier wrote only one book on cryptography, but several on human factors. That does not tell us that we should be sloppy with our crypto and authentication methods, though. > it doesn't scale I’m still not seeing how it’s difficult to remember, securely record, type, or transcribe a password that will pass the new restrictions. They’re on the mild side, as these things go. If you wanted to use the GRC password haystack calculator results to argue for a slight reduction in the defaults, I could get behind that. Six random characters pulled only from the unambiguous subset of the alphanumeric set, no uppercase, and one symbol gets you a password that should withstand constant pounding for the life of the machine. I could live with that minimum. I have no strong feelings on the new libpwquality rules, exactly. What I do feel strongly about is that there should be *some* reasonable minima that can’t easily be bypassed. Where that level is set is not only a sensible subject for debate, it is one that’s easy to separate from emotion; it’s basically a question of arithmetic. > Making policies > opt out let alone compulsory is unacceptable. I don’t see why we can’t take some responsibility for this mess and try to build up some herd immunity. > Even as the policies > get stronger people's trust in password efficacy relating to security > continues to diminish. Passwords are what we have today. Strengthening them to a level that will suffice until something better comes along is reasonable. _______________________________________________ CentOS mailing list [email protected] http://lists.centos.org/mailman/listinfo/centos
