Summary of password strength discussion

[Chris Murphy]

On Thu, Jul 30, 2015 at 9:41 AM, Paul W. Frields <stickster at gmail.com> wrote:
> 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.

This is my understanding also with two exceptions:

- user will have informed consent rather than a minimum quality
enforced as "do not pass Go"

- the informed consent may have slightly different UI in the
installer, g-i-s, and GNOME Users but ultimately will assess quality
and state in basic terms why the password isn't a good choice
consistently

https://fedorahosted.org/fesco/ticket/1455#comment:30



-- 
Chris Murphy