Distributions

Fedora revisits password policies

The Fedora project is revising its stance on forcing users to select strong passwords, mere months after implementing a change that blocked weak-password creation in the Anaconda installer. Testers found the new approach more aggravating than helpful, so the old password-selection criteria will be put back in place for the upcoming Fedora 22 release, and the project will take a hard look at defining a more comprehensive password-security approach for Fedora 23.

As we covered in February, the root of the issue is the concern that, if left to their own devices, users will choose weak passwords that can easily be guessed or cracked. Some coaching about password strength, it was hoped, would push users toward stronger selections. The password chosen while setting up an account with Anaconda, after all, is not used just for desktop logins. A weak choice could expose the system to attack over SSH, and it goes without saying that a weak root password poses an even greater security risk than a weak password for a normal user account.

Thus, setting a higher bar for password strength in Anaconda would have additional benefits down the line. The actual change was made in January by Brian C. Lane. Rather than asking the user to verify their password choice with an additional click (as it used to), the installer would check the password provided and tell the user to choose a stronger one if it failed to meet the minimum length (eight characters) and complexity (assessed by libpwquality).

Even at the time that the Anaconda change was made, though, there were critics who argued that focusing on password strength was a mistake. The real goal is securing the Fedora machine against attack, the critics said, and that ought to involve—and perhaps start with—other steps (disallowing root logins over SSH, allowing only key-based SSH login, and so on). But the change went through nonetheless—it was, at least, quick to implement, whereas rethinking broader security policies would be quite time consuming.

By March, however, Fedora testers had gotten some time to work with the new Anaconda, and a number of them were not pleased with the change. A ticket was opened shortly after Lane's change asking the Fedora Engineering Steering Committee (FESCo) to "review it and advise the package developers". The ticket pointed to a forum thread where a number of users complained about ill effects of the change—such as making it more complicated to spin up a new virtual machine, difficulty in using the new password-checker with international keyboard layouts, and the general principle of not forcing behavior on the user.

Furthermore, Adam Williamson from the Fedora QA team commented that users found the libpwquality assessment of their passwords unusually stringent, which may not have been what the Anaconda team had intended. There were also several bugs filed about the new behavior and several mailing-list debates took place. FESCo initially deferred to the Anaconda team's decision, but after continued debate in the ticket comments, it agreed to discuss the matter in its March 4 meeting.

As the log from that meeting notes, FESCo concluded that it "would like Anaconda to turn back on the 'double-done' option for Fedora 22. Better solutions should be investigated for Fedora 23." Speaking on behalf of FESCo, Adam Jackson said that the committee "is prepared to work with Anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future."

Reverting the Anaconda change was then designated a Fedora 22 beta blocker. Although the discussion continued, Anaconda's password checker was reverted back to its Fedora 21 behavior on April 4.

Jackson elaborated a bit on the decision in a follow-up email. He would have preferred, he said, for the various teams involved to have found a password-strength level that Anaconda and libpwquality could provide without exasperating users, but that did not happen. As a result, the decision facing FESCo was whether or not the change amounted to a regression from Fedora 21. Kevin Fenzi cited some other, more specific reasons for the decision, such as the fact that Anaconda would tell the user that their chosen password was bad, but would not explain why it was considered bad—nor how to fix it.

Ultimately, though, most participants in the discussion seemed to feel that the ideal solution would be to decide on a real, well-thought-out policy on password strength and security. What such a policy would look like has yet to be decided. Fenzi said that the best outcome would be a policy that encompassed not just Anaconda, but sshd, passwd, sudo, PolicyKit, and perhaps even device mapper and GNOME Keyring as well. Miloslav Trmač agreed, noting in particular that disk encryption warrants serious thought:

A policy encompassing so many factors may take some time to devise. For example, Michael Catanzaro felt that Anaconda should stop doing account creation altogether, and leave that task up to a "first-run" tool. Such a separation of tasks might make the security-policy decision easier to handle, since it would allow the Fedora Server, Cloud, and Workstation product groups to each implement their own policy. Part of the problem with February's Anaconda password-creation change, after all, stemmed from the fact that cloud and desktop systems have a significantly different use case for user accounts.

While the debate on a project-wide password policy may take quite some time to reach a conclusion, work has progressed on changes to allow the different product teams to tune Anaconda's behavior. In March, Lane committed a change that will allow different Fedora products to specify different password-checking behavior in the Kickstart file. That will at least allow some different defaults settings to be deployed for different use cases.

Fenzi has started a draft policy page on the Fedora wiki, although it is largely blank at the moment. The last real attempt at devising any sort project-wide password-security policy was done for Fedora 17, so considerable differences should be expected. As for when the new policy will take shape, it is probably too early to say—the interest is there, but right now the focus is on getting Fedora 22 out the door. Expect to a more concerted effort once that is complete and everyone's attention turns to Fedora 23.

Comments (14 posted)

Distribution quote of the week

Comments (none posted)

Distribution newsletters

• DistroWatch Weekly, Issue 604 (April 6)
• 5 things in Fedora this week (April 3)
• Ubuntu Weekly Newsletter, Issue 411 (April 5)

Comments (none posted)

Parsix 7 Morphs GNOME Into a Better Desktop (LinuxInsider)

Comments (none posted)