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