Summary of password strength discussion

Chris Murphy lists at colorremedies.com
Thu Jul 23 20:37:09 UTC 2015


On Thu, Jul 23, 2015 at 12:34 PM, Michael Catanzaro
<mcatanzaro at gnome.org> wrote:
> On Thu, 2015-07-23 at 13:45 -0400, Matthew Miller wrote:
>> How would this work when there are multiple users on the system?
>> Would
>> they all need to pick new passwords at this point?
>
> Hadn't considered this. Does the sharing panel enables remote access
> for all user accounts? That would not be very intuitive....
>
>> For that matter, how do you know that the original passwords weren't
>> already strong enough?
>
> g-i-s and g-c-c could save the password strength when the password is
> set. But if you set your original password some other way, then the
> only way would be to force the user to enter his current password.
> Which has to be done anyway to set the new one, so we probably just
> assume the current password is not strong enough?

Which means the user will have to change the password for turning on
ssh in the GUI? If so that's appalling. What about turning ssh off and
then on again? Another change in password is required? No, thanks.

There is no way to properly assume the use case, or assess the risk on
behalf of the user. Therefore assumption and policy enforcement of
this level is inappropriate. It's OK to inform or warn the user and
give them every incentive to use something stronger, but to make it
compulsory (it's still compulsory if they have to learn about a work
around to make the interface comply) is untenable.

This was written with Internet protocols in mind, but the argument
regarding prioritization of stakeholder rights and the consequences
for violating them is relevant.
https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt

What is the cost of a bad password? Either none, or a breach. Who is
most injured by a breach? The user. Since the other stakeholders have
essentially zero cost by a breach, and in no possible way is their
cost higher than the user, the user weighting is paramount.

I acknowledge for organizations, the "user" stakeholder is split
between organization and individual in a less simple way – so enabling
sysadmins to change to strong enforcement is a good feature; but by
default is seriously problematic. For most Fedora users as
individuals, who do they appeal to? It's a faceless appeal. In an
organization, it's their sysadmin who is also a user with whom they
have direct appellate access to balance things out. There is no way to
balance this out after Fedora ships except to ship another Fedora.

"...when their rights are not respected, leading to a failed effort."

-- 
Chris Murphy


More information about the desktop mailing list