Anaconda 22.17+ enforces "good" passwords

[Chris Murphy]

On Mon, Feb 16, 2015 at 10:22 AM, Hubert Kario <hkario at redhat.com> 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