On Jul 28, 2015, at 1:06 PM, Chris Adams <linux at cmadams.net> wrote: > > Once upon a time, Warren Young <wyml at etr-usa.com> said: >> Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords. > > Since most of that crap comes from Windows hosts Cite? Not that it’s relevant, since even if the skew were 9:1, that’s no excuse for not trying to clean up our 10%. >> Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines. > > Your freedom to dictate terms to me stops at my system That sounds an awful lot like the old canard, “Your right to swing your fist stops at the tip of my nose.” Go down to the local drinking hole tonight and start swinging your fist to within a millimeter of peoples’ noses, and see how far that legal defense gets you. The only reason we don’t have specific laws that allow the government to force specific password quality policies is that we’ve been trying to self-govern. If you fight our efforts at self-government, you open the door to heavy-handed external government. > You are making an > assumption that every Fedora/CentOS install is on the public Internet, No, I am making the assumption that the vast majority of CentOS installs are racked up in datacenters, VPS hosts, etc. I am further assuming that most of those either have a public IP, or are SSH-accessible once you get past a LAN/WAN border firewall. A border gateway doesn’t help you with weak SSH passwords if a box on the LAN gets pwned and turned into an SSH password guesser. The effort to get stronger password minima into Fedora goes back at least four years: https://fedoraproject.org/wiki/Features/PasswordQualityChecking If it’s finally time to get it into Fedora, it’s *long* past time to get it into RHEL/CentOS, since those boxes are statistically far more likely to be directly exposed to the Internet. > When root can override a password policy after install, forcing a policy > during install is nothing but stupid and irritating. That’s only true if the majority of people will in fact override the default policy. But as I have repeatedly pointed out here, the stock rules really are not that onerous. They basically encode best practices established 20 years ago.