VOOZH about

URL: https://lwn.net/Articles/631522/

⇱ Fedora and "strong" passwords [LWN.net]


👁 LWN.net Logo
LWN
.net
News from the source 👁 LWN
| |
Log in / Subscribe / Register

Fedora and "strong" passwords

Ignore previous instructions; subscribe to LWN today

Every article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.

By Jake Edge
February 4, 2015

Passwords are an ever-present annoyance when dealing with computers. Because they may need to be typed frequently, there is a tendency toward making them simple, but that has a large impact on the security provided by the password. Forcing users to provide "strong" passwords at install time, both for root and normal users, makes sense to some from a security perspective. To others, however, it is paternalistic and doesn't take into account users' knowledge of the risks the system will be exposed to. That debate is currently playing out in the Fedora community.

The debate flared up most recently on the fedora-test mailing list, but its roots go back further than that. The underlying problem is that the SSH daemon (sshd) is enabled after the Anaconda installer runs. It is configured such that root logins are permitted using a password, so any internet-accessible system could have its root password guessed in a brute force attack. One way to reduce the chances of that are to enforce setting a stronger root password.

Currently, Anaconda complains if a "weak" password is entered, but the installing user can click twice to confirm and use such a password. However, Anaconda developer Brian C. Lane notified testers on January 28 that Anaconda would no longer accept weak passwords and those less than eight characters long.

I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.

And on the bright side, you don't have to click done twice anymore :)

That change was driven by a suggestion to turn off root login over SSH by Prasad J. Pandit (aka P J P) back in November on the fedora-devel mailing list. In that discussion, the idea was largely met with approval, though some were not convinced that doing so really provided much in the way of added security. There was also talk of ways to get a user's SSH key added to the install, so that instead of blocking all root logins, it would only block password-based logins.

But there were also complaints that root is not the only user affected by brute force password-guessing attacks. Other accounts may not be as obvious, but if they have weak passwords, they can easily fall prey as well. Forcing installing users to create a user account that could be used for SSH purposes if root access were disabled was also seen as suboptimal. There are plenty of use cases where local user accounts are not needed or wanted.

Pandit created a Fedora feature page for the change, which was originally targeted for Fedora 22. When Fedora program manager Jaroslav Reznik brought up the change on fedora-devel in early January, though, there was considerably more dissension. As Stephen Gallagher pointed out, disabling root login over ssh may make sense for workstations, but doesn't for (typically headless) servers. Others, of course, disagreed.

A summary of the arguments for and against was posted by Pandit, but seemingly didn't change any minds. Part of the problem is that the proposal has a larger scope than simply changing the default value for the "PermitRootLogin" sshd configuration parameter. In fact, it looks at two different ways to solve the problem and makes assumptions about changes that will be made in Anaconda to support the feature, but doesn't really make them explicit. That is not really the right way to get changes into Fedora, as Adam Williamson explained:

Still, you can't just invoke features into existence by describing them on a Change page. There needs to be a credible plan for actually *doing* that work, yet so far as I can tell, none of the anaconda developers is involved the Change proposal, nor has anyone said "I will write the code to make this work".

In a project like Fedora, it doesn't always work out well to do things the way this Change seems to be going: think of one change you want to do, write up a Change for it, realize that lots of other things would have to be done to make the change viable, and just write those things into the Change as bullet points, and assume that somehow they'll be made to happen if the change is approved.

So, Pandit took the issue to the Anaconda mailing list. The discussion there quickly turned to the password-strength requirement in the installer. The idea of turning off password-based SSH logins is popular, but there is no mechanism to provide a key to Anaconda as part of the installation process. So Lane suggested the change to require longer and stronger (as measured by libpwquality) passwords.

Some were willing to live with the change, even though they may do many installs for testing purposes, but others were not so sure. Williamson, who is part of Fedora Quality Assurance (QA), complained that it would make his job harder:

It will also make QA people hate our lives. srsly, sounds like a small thing, but typing 'correcthorse' 25,674 times during a release cycle will drive me freaking batty. if we go to onerous root pw requirements, we're really gonna need a sekrit cmdline switch to disable it or something.

Chris Murphy piled on: "I dislike this feature so much I'd rather read of some small corner of the Internet [burning] because one of our users had too much gin one night while configuring Fedora, used 12345 as their root password, and the computer was made part of a giant botnet overnight." Murphy suggested that "baby sitting" users who choose not to set a strong password is not appropriate.

In what seems like a unilateral decision, though, Lane described the change, shortly before notifying the testers that Anaconda would be changing. He also had a suggestion for those who would be affected:

Users who are concerned with security already know how to setup their systems, use strong passwords, switch to key only logins, etc. They aren't the ones who need help.

Instead I propose that we increase our minimum password length to 8 characters, and disallow weak passwords. The initial pain of creating a throw-away password for your vm can be mitigated by running pwgen and writing down a nice looking one on a sticky note :)

Lane's suggestion, which runs counter to password best practices, only solves part of the problem, though. Even if someone generates a throwaway password to put on their sticky note, they may have to type it in many, many times. As Williamson put it:

'Secure' passwords are nothing but a major pain in the ass when testing disposable installations in isolated environments, which is what we do, over and over and over and over again, for weeks.

So far at least, though, the Anaconda change seems to be here to stay. The notification mail set off some howls of discontent (which Williamson worked hard to tamp down) in the fedora-test mailing list. It seems possible that the whole issue will end up on Fedora Engineering Steering Committee's (FESCo's) plate at some point in the near future.

Pandit has pushed the SSH configuration change back to Fedora 23 because the user interface (UI) changes in Anaconda can't be done in the time frame needed for Fedora 22. There has been discussion of providing a way for installing users to enable root SSH logins from the Anaconda UI, but that is still a ways off. The feature also still needs to pass FESCo muster.

Providing better default security for new and/or non-savvy users is certainly a good thing. But not allowing more technical users to knowingly bypass those measures is sure to irritate them. Erecting barriers (or speed bumps) in the way of more testing seems a bit short-sighted as well. While stronger passwords do provide a measurable increase in the security of the system, it would seem that some accommodation for those who want to avoid those requirements could be made.


Index entries for this article
SecurityDistribution security
SecurityPasswords


The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.