Summary of password strength discussion

[Paul W. Frields]

On Thu, Jul 23, 2015 at 11:55:47AM -0500, Michael Catanzaro wrote:
> Hi,
> 
> At the last WG meeting [1] we discussed the password strength issue. We
> agreed on four main points:
> 
> 1) Fedora Workstation will ship a custom .conf file in
> /etc/security/pwquality.conf.d, which is now possible in F23 [2].
> 2) gnome-initial-setup will be modified to prevent the user from
> setting a password that would be rejected by libpwquality.
> 3) We need to test a reasonable set of passwords we'd want to succeed,
> to make sure the settings we chose in (1) are correct.
> 4) Our requirements for local password strength will allow passwords
> that would be much too weak were remote access via SSH to be enabled.
> We should have some user interaction when enabling SSH in the Sharing
> panel to force the user to pick a much stronger password.
> 
> Note: point (1) allows corporate deployments to set their own password
> polices, which will be respected by GNOME, to meet their own security
> needs, by modifying /etc/security/pwquality.conf (which overrides the
> settings in /etc/security/pwquality.conf.d).
> 
> Point (4) above sets the goal of setting stricter password requirements
> when remote access is enabled. Remote access is disabled by default and
> will remain disabled forever for most Workstation users, so it's not
> appropriate for that case to dictate our default password requirements.
> This means only physical adversaries are interesting to consider.

The discussion ranged pretty far elsewhere in this thread, but the
summary I take away is:

* No real disagreements on 1-3 as far as establishing/enforcing
  policy; points below are regarding 4
  
* It's risky, maybe foolhardy, to muck with /etc/ssh/sshd_config to
  whitelist users or other config -- too many potential points of
  failure, adds code complexity, etc.

* Frobbing passwords again after enabling sshd.service also creates
  confusion (repeat {en,dis}ablements, how to propagate to other
  users, etc.)

  * Basically, the further we go down this road, the more confusing
    both the tools and the user experience gets.  (My personal feeling
    from observing the discussion is that initial password setting is
    the only point we should really do any enforcement, and trying to
    "backfill" the process is doomed.)

* Alternative of turning on sshd.service on a per-interface basis to
  change the surface of attack -- in other words, we reduce exposure
  for the user by not running sshd on non-trusted networks

* We still need to establish a list of words for point 3 to try
  against a libpwquality policy

Please let me know if I missed a major important point here.  I'm sure
some people may disagree with whatever decision is made, but we should
choose a path here.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com