On Thu, Jul 23, 2015 at 12:34 PM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> 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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
