FESCO request to revert password confirmation change in F22

[Miloslav Trmač]

Hello,
> On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote:
> > * The workstation folks think this change could drive away some of
> >   their potential users for not much gain. In their case, sshd is not
> >   enabled/running and additional security for a device that sits in
> >   your home isn't worth the additional complexity.
> 
> Regarding Workstation: I don't think it provides any additional safety,
> TBH. I see two cases:
> 
> * Case 1: The attacker has physical access to your computer.
> 
> * Case 2: The attacker doesn't have physical access to your computer.
> The user account password is irrelevant.

> My argument in Case 2 does fall down if the user enables SSH in the
> Sharing panel of System Settings. That's indeed disabled by default,
> though. It also falls down if the user enables VNC in the Sharing panel,
> but that is an orthogonal issue as that's not your user account
> password, and it's limited to eight characters regardless.

There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization.  Just looking at a local machine does not necessarily tell you what the needed password strength is.

This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration.  If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions.  Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up.


> I mention it
> because I hesitate to add a password strength check when enabling SSH
> unless we do so for VNC as well, which would be impossible.

Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic.  At the very least we have the option of giving up on VNC instead.  And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway).  What am I missing?
    Mirek