On Mon, Feb 16, 2015 at 10:22 AM, Hubert Kario <hkario@xxxxxxxxxx> wrote: > On Friday 13 February 2015 14:42:09 Chris Murphy wrote: >> Do you not see how your password policy defend hinges on grandiose >> assumptions? I have many devices lying around without any information >> on them, they're used strictly for testing, so there isn't anything >> but an OS and some cache files for ycombinator and cnn, BFD. Oh but I >> need to use strong passwords because someone ELSE might be an idiot >> and have sensitive information on their laptop. So you are drawing me >> into becoming responsible for other people's behavior too. Everyone is >> baby sitting users who don't give a crap. > > you should take a look at traffic laws, they all are about "someone ELSE might > be an idiot" No there are numerous logical fallacies here. There are threats of fines and jail time, there is no active "pre-crime" coercion that somehow compels incompetents to alter decision making. Idiots still break the law, they run red lights, there are still traffic accidents. Traffic laws are about normalization, in effect they're a spec so that users have expectations and trust in a transit system that would otherwise be chaotic. You should take a look at collective punishment. > If you know you will be using the device for testing then just change the > password post-install to something simple > > The vast majority of people won't be using the installations just for testing. Your work around belies the change itself and results in equivocation. This is what I hear: inconveniencing testers is unfortunate but ultimately it's OK because it's a small group. One small set of helpful and responsible users will in effect be collectively punished, over and over again (some testers do dozens of new installs per week, even per day) in order to coddle the emotional state of a handful of control minded types who are completely out of ideas (or time) to convince a 3rd group of users to stop using weak passwords voluntarily, therefore have decided coerce them into capitulation along with the ensuing collateral affects. But it's OK because better security is always better. Pissing people off is not the goal, but it's an acceptable trade off in this case. It's more likely I'll stop testing the installer, so far I haven't since the change appeared in the 22.17 build. The burden is too high, and philosophically I'm diametrically opposed. I think the change is unethical. My password policy is mine. It is not yours, it is not Fedora's. The device is mine, it's not yours or Fedora's. The change is a misplaced appropriation to the point I consider it misfeasance. >> First, sshd is not a security feature, it's a remote connection >> service and increases the attack surface. Disable that. It has a lower >> burden on more people, and it's also an expected burden for anyone >> come from other enterprise cultures. The idea a Windows Server would >> have remote services enabled by default? I think most any hard core >> Windows sysadmin who also doesn't make bad excuses for Microsoft would >> admit this could be a liability lawsuit waiting to happen if they were >> to do that. That's how bad an idea it is. > > but they do > > you can certainly run commands remotely on a Windows Server system as soon as > you connect it to a domain, just because the remote GUI login is disabled > doesn't make remote services and administration disabled Powershell might be enabled by default in more recent versions but then there's also execution policies in place. The scope of the risk is still apparently low enough that not even Microsoft, with its history of security issues, bothers to insist on an installer mandating long or complex passwords. -- Chris Murphy -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
