Fedora and "strong" passwords [LWN.net]

We're bad at marketing
We can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.

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
Security	Distribution security
Security	Passwords

to post comments

Fedora and "strong" passwords

Posted Feb 5, 2015 3:19 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

> While stronger passwords do provide a measurable increase in the security of the system

measurable is a nice ambiguous term. It may only be 0.0001% more secure, and still be measurable.

but I would be really interested in learning what the measurement criteria is for determining how secure a system is that's used for this measurement.

There are a good number of security people who are saying that all passwords are poor, and once you get outside the most common dozen or so passwords, the password strength doesn't really matter much.

in any case, how many systems are breached due to understrength passwords as opposed? Especially when you compare that number to default passwords, or exploits that let people bypass passwords entirely.

In my logs, I see a lot of guessing of what the attacker thinks are common passwords for various accounts, but brute force guesses of every possible password? nope (and if this was to happen, my alerting system would light up from the huge increase in the number of failed logins)

Apologies if this comes off as harsh, I may have just hit my quota of security "everyone knows" statements. The bottom line is that the changes to the password strength rules may or may not make any meaningful difference in the security of the system.

Fedora and "strong" passwords

Posted Feb 5, 2015 4:42 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> Apologies if this comes off as harsh, I may have just hit my quota of security "everyone knows" statements. The bottom line is that the changes to the password strength rules may or may not make any meaningful difference in the security of the system.

A while back, I bought a lot of 10 Model M keyboards that apparently came from a large law office. On the bottom of two of those keyboards were post-it notes with username/passwords.

Strong password policies usually just result in passwords that are harder to remember, yet easier for a computer to break.. and in the case of that particular law office, resulted in my getting access to a couple of email accounts.

Fedora and "strong" passwords

Posted Feb 5, 2015 23:02 UTC (Thu) by Jandar (subscriber, #85683) [Link]

> To others, however, it is paternalistic and doesn't take into account users' knowledge of the risks the system will be exposed to.

That is exactly my reaction. If someone gets access to the LAN segment the new test-machine is connected to, I have a much larger problem than a compromise of its root account. Paternalistic is a euphemistic description of this behavior. It's hostile to its users.

Fedora and "strong" passwords

Posted Feb 9, 2015 8:51 UTC (Mon) by mjthayer (guest, #39183) [Link]

> A while back, I bought a lot of 10 Model M keyboards that apparently came from a large law office. On the bottom of two of those keyboards were post-it notes with username/passwords.

Shame on them - they should have kept the notes in their wallets[1].

[1] https://www.schneier.com/crypto-gram/archives/2005/0715.h...

Fedora and "strong" passwords

Posted Feb 5, 2015 8:31 UTC (Thu) by rsidd (guest, #2582) [Link]

> There are a good number of security people who are saying that all passwords are poor, and once you get outside the most common dozen or so passwords, the password strength doesn't really matter much.

I'm not sure who these security people are. Any English-language word is a bad password, ie well more than a dozen. Adding 123 at the end is equally bad. Back in the 1990s the admins at the place where I was studying did pre-emptive dictionary attacks on all user passwords, and locked the ones they cracked including mine (it was "Toccata"). I learned my lesson at that time.

Granted, that was a local attack (and being admins, they directly tried the hashes in the passwd file) and remote dictionary attacks are much slower. But far from impossible, and many people don't monitor their sshd logs. Try a word every five seconds (default ssh configuration lets you do that) and you can get through a lot of words in a day or two.

Fedora and "strong" passwords

Posted Feb 5, 2015 6:29 UTC (Thu) by rodgerd (guest, #58896) [Link] (2 responses)

> 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 :)

Attitudes like this is why Linux is basically irrelevant, and will remain irrelevant, outside of the server world.

Fedora and "strong" passwords

Posted Feb 5, 2015 17:09 UTC (Thu) by pr1268 (guest, #24648) [Link] (1 responses)

I don't think it's fair to malign Linux in this fashion; after all, the whole mess of 90-day password expiration was a Microsoft invention, right?

The irony here is that even MS's top engineering research seems to refute this philosophy (PDF link). Go figure...

Fedora and "strong" passwords

Posted Feb 17, 2015 18:45 UTC (Tue) by ScottMinster (subscriber, #67541) [Link]

I don't think the 90 day password policy is a Microsoft invention. This post by Gene Spafford relates what I had heard about the policy's origins:

So where did the "change passwords once a month" dictum come from? Back in the days when people were using mainframes without networking, the biggest uncontrolled authentication concern was cracking. Resources, however, were limited. As best as I can find, some DoD contractors did some back-of-the-envelope calculation about how long it would take to run through all the possible passwords using their mainframe, and the result was several months. So, they (somewhat reasonably) set a password change period of 1 month as a means to defeat systematic cracking attempts. This was then enshrined in policy, which got published, and largely accepted by others over the years. As time went on, auditors began to look for this and ended up building it into their "best practice" that they expected. It also got written into several lists of security recommendations.

This is DESPITE the fact that any reasonable analysis shows that a monthly password change has little or no end impact on improving security! It is a "best practice" based on experience 30 years ago with non-networked mainframes in a DoD environment—hardly a match for today’s systems, especially in academia!

Fedora and "strong" passwords

Posted Feb 5, 2015 7:59 UTC (Thu) by marcel.oliver (subscriber, #5441) [Link] (1 responses)

Just some more problems that come to mind:

Mathematically speaking, reducing the number of available passwords (of any given length) reduces the search space, so it does make things less secure for all of those installations planning to use a strong password anyway. This effect is probably very small, but the statement that the change makes things measurably more secure is at least questionable in this light.

More importantly, rejecting certain passwords by algorithm has another big problem: I, and probably many others, devised a personal scheme to create an individual password for each site based on various site-specific pieces of information. If this works, I only have to remember the scheme, not each password. Typically, these passwords are rated very strong by the usual measurements. Very annoyingly, there are various sites (all of them web accounts) which reject passwords from the scheme. Most of the time it's for really stupid reasons (certain special characters are excluded, password too long), but I got passwords rejected otherwise, too (e.g. three same characters in a row, that's just how the scheme worked out for a particular site, the password was long enough otherwise). If this happens, the entire security scheme breaks. I have no idea how libpasswdquality works, but if there is any chance that it rejects single reasonable passwords, it can break individual security schemes for someone badly.

Fedora and "strong" passwords

Posted Feb 7, 2015 20:11 UTC (Sat) by dashesy (guest, #74652) [Link]

And some aging business models (want to say Yahoo!) have problems if the password is too strong, but only on mobile platform! The `pattern` approach is all good until you realize you end up having multiple `patterns` to deal with dumb sites, some even bank accounts. And yes, ironically combination of `baby sitting force` and `laziness` means password guessing will have actually fewer tries to attempt, like `1@#$%^` will become the next most used password. Strong passwords, is a policy, and forcing one particular policy is best be avoided by engineers.

Fedora and "strong" passwords

Posted Feb 5, 2015 9:12 UTC (Thu) by jezuch (subscriber, #52988) [Link] (19 responses)

Disallowing remote root login is even a question in the age of sudo?

Fedora and "strong" passwords

Posted Feb 5, 2015 9:37 UTC (Thu) by jengelh (subscriber, #33263) [Link] (16 responses)

An attacker gaining login by having guessed your password easily gains root through a sudo configured for NOPASSWD or invokerpw. At which point you might just as well enable root logins directly, then.

Fedora and "strong" passwords

Posted Feb 5, 2015 10:40 UTC (Thu) by NAR (subscriber, #1313) [Link]

For a non-root account the attacker has to guess username too.

Fedora and "strong" passwords

Posted Feb 6, 2015 13:22 UTC (Fri) by jezuch (subscriber, #52988) [Link] (13 responses)

> An attacker gaining login by having guessed your password

I have password authentication in SSH disabled on all systems I control :)

> sudo configured for NOPASSWD

Don't Do It Then.

Fedora and "strong" passwords

Posted Feb 7, 2015 20:20 UTC (Sat) by dashesy (guest, #74652) [Link]

And Fedora now has Workstation and server, having `PermitRootLogin` makes absolutely no sense on servers, what is horrible is that the default on Fedora is "Yes", i.e. if that line is commented, it is permitted! I recently tried the Fedora server edition (to learn a little about OpenStack), and I was amazed looking at login attempt logs, bots try root login as soon as any machine gets public, it seem even faster than a physically present can hit enter! Who would want root login on servers, but one may also ask who wants a cutting edge distribution for internet-facing servers.

Fedora and "strong" passwords

Posted Feb 9, 2015 23:28 UTC (Mon) by Tet (subscriber, #5433) [Link] (11 responses)

I have password authentication in SSH disabled on all systems I control :)

Ahh, so you don't like security then? Seriously, this is the single most annoying piece of misinformation I encounter regarding security. It does not make you more secure. Indeed, you can argue it makes you less secure. Think about the attack vectors. If someone sniffing an encrypted connection and managing to extract a password being sent over that connection is one of them you're doing it wrong.

Fedora and "strong" passwords

Posted Feb 10, 2015 0:20 UTC (Tue) by JGR (subscriber, #93631) [Link] (10 responses)

It's not the authentication/password transfer over the wire that's the problem. It's user management/storage of the password the rest of the time. Pubkeys are not some panacea, but they avoid some of the pitfalls associated with passwords (written on post-it attached to monitor, re-used elsewhere, set to 123456, etc.).

Fedora and "strong" passwords

Posted Feb 10, 2015 7:59 UTC (Tue) by jezuch (subscriber, #52988) [Link]

> Pubkeys are not some panacea, but they avoid some of the pitfalls associated with passwords

Exactly. Basically, a pubkey is a very complex (very "secure") password - with some automation around it.

Fedora and "strong" passwords

Posted Feb 10, 2015 10:37 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

It may have escaped your attention, but a pubkey is a password that is so complex you have no choice but to let your computer write it down, in the same computer you wish to connect out from.

Fedora and "strong" passwords

Posted Feb 10, 2015 16:39 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I don't think that's a detail which was missed, that's integral to the security trade-off being made, using pubkey helps protect you from online password guessing attacks and from re-using passwords which have been compromised on unrelated services, it identifies the host you are coming from as having access to the private key pretty strongly. Additional protection is to password protect the key at rest, using ssh-agent to enforce some local policy and if you want to enforce some idea of the user being present then 2FA token after pubkey auth will get you very far, even in the presence of a keylogger or actively compromised client host.

You personally might not have 123456 as your password but that doesn't mean someone in your organization doesn't have a bad password, the more people the more the chance approaches 1.

Fedora and "strong" passwords

Posted Feb 10, 2015 18:16 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (6 responses)

A pubkey is much more than just an extremely long password. With password-based authentication there is a shared secret: both the client and the server need to know the password. Because of that, you have to make up and remember new passwords for every system you log into, or else accept that the compromise of one system implies the compromise of all the others. With a pubkey you can have a single key which stays on the client—which can itself be password-protected, or even kept on a secure smartcard—and if any other system is compromised the attacker only discovers how to validate the key, not how to log in to other systems.

(Yes, there are zero-knowledge proofs available for password authentication, but unlike pubkeys they aren't easily integrated into a standard SSH configuration, and you'd still have the problem of weak passwords to deal with.)

Fedora and "strong" passwords

Posted Feb 10, 2015 18:27 UTC (Tue) by paulj (subscriber, #341) [Link]

Yes, technically the secret is no longer shared. This allows a user to use the same key for multiple servers, even where the servers are in different trust domains.

In the context of the grand-parent's concerns, about the end-user writing down passwords, SSH keys are not really better. Indeed, as the key might be stored unencrypted on the client computer, the access implications are different, and the security may even be worse in some cases. Post-it note password security may actually be more secure, depending on the client's physical situation.

Fedora and "strong" passwords

Posted Feb 10, 2015 18:44 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

> With password-based authentication there is a shared secret: both the client and the server need to know the password.

No, this hasn't been true for a couple of decades.

with password based authentication you have something that the user knows that is used to calculate something that the server can compare to.

With public keys you have something that is used to calculate something that the server can compare to.

The calculation used for public keys is much more complex, and since the problem space is so much larger, it's believed that it's not practical to beat this (by brute force, rainbow tables, etc).

But if you were to use a password manager that had purely random 128 character keys, you would have the same thing, a simple password/passphrase to unlock a complex 'thing' that you use to negotiate with the server to gain access.

The difference between the two is that the password is reusable over the network, so if someone can sniff the communication between the client and server, they can get the reusable portion and pretend to be you. But if you have encrypted communications to the server, the only place that this can happen is on the client or the server.

If it happens on the client, keys are no better than passwords, the attacker can get the passphrase and the key. There have been a lot of systems compromised as a result of one person's laptop being 'owned' and then the credentials stolen from that used to hopscotch through the system.

If it happens on the server. passwords are worse. The attacker would have to replace the binaries of the software that's processing the encrypted connection to grab the password after it's decrypted (or troll through the memory used by the process), so it requires an ongoing, active attack, not just grabbing data and getting out (remember, the 'password' is a long, crack resistant string)

Unfortunately, client machines tend to be much more vulnerable than servers (although servers are nice, static targets). What you really need is to have something that keeps the secret data out of reach of the client OS. This is where hardware tokens come in. There are devices out there that are very easy to use and can be integrated with many different system (unfortunately it still requires that the thing being authenticated to support the particular type of device)

Fedora and "strong" passwords

Posted Feb 10, 2015 20:29 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (3 responses)

> with password based authentication you have something that the user knows that is used to calculate something that the server can compare to.

nybble41 wrote:
>> (Yes, there are zero-knowledge proofs available for password authentication, but unlike pubkeys they aren't easily integrated into a standard SSH configuration, and you'd still have the problem of weak passwords to deal with.)

The way password authentication works in SSH in practice is that the actual password is sent from the client to the server over the encrypted link, after checking the server's host key against known_hosts. To avoid sending the password the client would need to know how to deal with whatever authentication system the server is using (Unix password database, Active Directory, some custom database); if the server has the password it can abstract away those details. There are other ways to do it (HTTP Digest has existed for ages, for example—and just look at how many sites use it!) but there is no single, *standard* way to do challenge/response password logins with SSH, whereas pubkeys are built in and supported almost everywhere.

> with password based authentication you have something that the user knows that is used to calculate something that the server can compare to. ... With public keys you have something that is used to calculate something that the server can compare to.

If you want to add "something that the user knows" then have the user encrypt their pubkey with a password. Client security is a problem, but anyone who could grab a decrypted pubkey off the client could just as easily grab a password. Of course, a smartcard, U2F key, or similar device would be even better.

Fedora and "strong" passwords

Posted Feb 10, 2015 20:42 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

> if the server has the password it can abstract away those details.

one point that I was trying to make (but probably got lost in the details) is that the server doesn't actually have the password (other than momentarily as it's processing the login), it has a hash of the password, and other than brute-force (including rainbow tables), you can't get the password from the hash.

Now, the fact that almost everyone uses something they can remember and easily type makes it so that the set of passwords that people use is a tiny subset of the set of passwords that are possible, and makes brute-force much more likely to work.

But if you were to have a password manager that worked similarly to certs (passphrase to unlock) that then put in a long, completely random password, the resulting security would be _very_ close to what you have with certs. The only significant difference is that tiny window where the server software has the password before it hashes it.

Fedora and "strong" passwords

Posted Feb 11, 2015 12:56 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

But if you were to have a password manager that worked similarly to certs (passphrase to unlock) that then put in a long, completely random password, the resulting security would be _very_ close to what you have with certs. The only significant difference is that tiny window where the server software has the password before it hashes it.

You would still have to trust that the passwords on the server are secure – that the administrators of the server will never do anything stupid (like store user passwords unencrypted after all), the passwords are never stolen by an attacker, there will never be a developer who builds in a backdoor that lets them look at passwords in the clear, and so on. It is difficult to establish and uphold that trust because (a) server operators generally do not like divulging the details of their authentication system to random users, and (b) even if things look OK today who knows what sort of terrible gaffe somebody there is going to commit tomorrow, or the day after. Your approach is fine when the server operator guarantees you 100% perfection in their dealing not just with your password in particular, but all their security-relevant operations in general – but in the Real World such a guarantee is usually unavailable.

The nice thing about public-key authentication is that the only thing the server needs to store from you is something that is public in the first place, and your secret key never actually needs to leave your computer (or smart card). This doesn't render you immune against every conceivable security problem, but it does significantly reduce your exposure to random server-side security issues.

Fedora and "strong" passwords

Posted Feb 11, 2015 13:51 UTC (Wed) by dlang (guest, #313) [Link]

the context of the conversation was ssh logins, so I was assuming standard system password hashing in the above.

How many apps other than ssh manage certificate based authentication of their clients? It's possible to do with web based services (although unless they've fixed it in the last couple of years, Apache doesn't let you have some part of the site open and other parts protected by client certs without patching the source)

Fedora and "strong" passwords

Posted Feb 6, 2015 17:57 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> sudo configured for NOPASSWD

Homeowner: The hole in my wall is getting a bit drafty.
Carpenter: Why did you drive your car throught it then?
Homeowner: So I didn't have to walk so far to the couch.

Fedora and "strong" passwords

Posted Feb 11, 2015 16:09 UTC (Wed) by etienne (guest, #25256) [Link] (1 responses)

> Disallowing remote root login is even a question in the age of sudo?

sudo is not that bad once you learn "sudo -s", but is it really a good solution:
$ sudo cp /etc/fstab /etc/fstab-sav
$ sudo cat /etc/fstab > /etc/fstab-sav
The second line do not work as expected, sudo has lower priority than the redirection (or than a semicolon).
sudo also silently flushes input, so that you cannot cut&paste multiple sudo commands from a file to the command line.
And is sudo safer than a suid script: ask the user to type a safe sudo command, he will enter the password, ask him to execute a script in his name, the script contains sudo commands without the user knowing?

Fedora and "strong" passwords

Posted Feb 11, 2015 18:51 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> sudo is not that bad once you learn "sudo -s", but is it really a good solution:
> $ sudo cp /etc/fstab /etc/fstab-sav
> $ sudo cat /etc/fstab > /etc/fstab-sav
> The second line do not work as expected, ...

So log in as a normal user, then run "sudo -i" to get a root shell. At least that way the system can log which user requested access to the root account.

> And is sudo safer than a suid script: ...

The problem with SUID scripts is that they're meant to be run by users who wouldn't normally be able to run arbitrary commands as root. It's difficult to do that safely with a script, due in part to all the implicit dependencies on external commands. That isn't a concern if you're granting full root access via sudo, though you do need to be careful if you're trying to provide limited access to specific commands. Not all commands can be safely confined. SUID scripts are also exposed to the original user's unsanitized environment; sudo helps a bit here by allowing you to control the environment the command runs in (e.g. whitelisting environment variables).

Non-savvy Fedora users?

Posted Feb 5, 2015 9:14 UTC (Thu) by NAR (subscriber, #1313) [Link]

Providing better default security for new and/or non-savvy users is certainly a good thing.

I always thought Fedora (being bleeding edge) is for those who know what they are doing...

Fedora and "strong" passwords

Posted Feb 5, 2015 15:20 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

One factual issue with the article: "The underlying problem is that the SSH daemon (sshd) is enabled after the Anaconda installer runs." That's probably true for Server, but it is not true for Workstation. It would be pretty crazy to allow remote access by default, so we don't. There's really no benefit to using a stronger password. Expect this password policy to change, or at least come up for another round of heated discussion.

Fedora and "strong" passwords

Posted Feb 5, 2015 21:00 UTC (Thu) by dskoll (subscriber, #1630) [Link] (2 responses)

Instead of measuring a strong password, why not have the installer generate a longish one (16 characters or more) from a cryptographically-secure source like /dev/random.

The installer screen could say: "OK, I'm about to tell you your root password. Please ensure no-one else is around and press Enter when you're ready to see it. Then write the password down and keep it in a secure location."

There are problems if you're installing in a VM since I suppose someone might be able to snoop in via the network, but it seems to me it's a mostly-reasonable solution.

Or the installer could pick the first 8 characters and you'd have to pick the next 8 for a combined 16-char password that you write down.

Fedora and "strong" passwords

Posted Feb 5, 2015 21:21 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

that seems even worse from a usability point of view than the current proposal to require a 8 character password that people are complaining about.

Fedora and "strong" passwords

Posted Feb 6, 2015 1:50 UTC (Fri) by dskoll (subscriber, #1630) [Link]

Strong passwords or usability... pick one.

But "measuring" the strength of a human-generated password pretty much guarantees that you end up picking neither.

Fedora and "strong" passwords

Posted Feb 5, 2015 23:36 UTC (Thu) by dag- (guest, #30207) [Link]

I was told by a security professional that "9D3c$fYa?XbF<Ro2oTF/7es8oE6d" is a very strong password, so I recommend we all use this one instead ?

Case closed.

Fedora and "strong" passwords

Posted Feb 6, 2015 7:01 UTC (Fri) by jem (subscriber, #24231) [Link] (10 responses)

Why should the root user have a password at all? What's wrong with sudo? The point with passwords is to authenticate a human using a password that ideally only exists in the head of that person. The root "user" is not a person.

The situation is even worse if the root password is shared between several people, legitimately or not. If the password leaks, you have a difficult task finding who leaked it. If someone abuses the root account, it's hard to tell who it was. If the password needs changing, you have a password distribution problem.

I'd say you are more likely to guard a personal password than a shared password. "Oh, everybody knows the root password, so I don't see why you shouldn't too."

Fedora and "strong" passwords

Posted Feb 6, 2015 7:33 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

depending on how your system is setup, there are failure modes that can prevent someone from being able to login or sudo from running but still let root login

For example, I have some systems where all the users authenticate against AD, there are a lot of failures that can prevent the normal users from logging in. I could create a non-root user that's hardcoded, but what's the advantage of that compared to root?

Fedora and "strong" passwords

Posted Feb 6, 2015 19:12 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

You could also disconnect the device from the network, you should be able to authenticate using AD credentials cached on the device, the same as mobile laptops do.

Fedora and "strong" passwords

Posted Feb 6, 2015 20:30 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

does winbind on linux cache credentials across boots? what if the admin who's available to troubleshoot the machine hasn't had to login to that particular box since it was created (with things like Chef/Puppet/etc)?

Fedora and "strong" passwords

Posted Feb 6, 2015 21:53 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Yes I believe winbind or sssd cache credentials, you'd have to test to verify of course, and if you are using config management like Puppet/Chef you have different constraints, so one plan might be to have two instances, one for configuring the host that changes often and a failsafe one which configures Puppet/Chef itself. I'm sure with a sufficiently clever bit of idiocy one can manage to cut their legs off and brick a host but you don't really need root passwords to manage machines, there are better ways to do things.

Fedora and "strong" passwords

Posted Feb 10, 2015 9:58 UTC (Tue) by oldtomas (guest, #72579) [Link] (5 responses)

> Why should the root user have a password at all? What's wrong with sudo?

Debian and derivatives went this path a while ago, and I must admit I was enthusiastic at that time.

Until the file system to be mounted as root failed and I was asked for a root password I didn't have to do fsck manually...

Yes, I recovered (boot from other media, fsck the thng, etc). But it was one of those "Duh!" moments :-)

Since then my systems get a root password to be kept in some safe place (it's typically a pwgen -n 16).

So that's why -- for me at least.

> The situation is even worse if the root password is shared between several people [...]

Yes, that's a big no-no in my book. That's what authorized_keys is for. At least for "regular use". If it's just in the armory waiting to be used in an emergency (see above), I think it's OK.

Fedora and "strong" passwords

Posted Feb 10, 2015 10:38 UTC (Tue) by micka (subscriber, #38720) [Link] (4 responses)

> Debian and derivatives went this path a while ago

Some derivatives, yes (but I only know of one for sure).
Debian... I don't remind of it. Every installation of it I ever did asked me a root password.

Fedora and "strong" passwords

Posted Feb 10, 2015 12:59 UTC (Tue) by oldtomas (guest, #72579) [Link]

> Debian... I don't remind of it.

Perhaps you're right and it's a brain fart on my side. As for this derivative... it seems to be the one I had said "duh" moment. I found it very instructive in the "unintended consequences" department.

Fedora and "strong" passwords

Posted Feb 10, 2015 13:15 UTC (Tue) by oldtomas (guest, #72579) [Link] (1 responses)

> Debian... I don't remind of it.

You're right. I just checked (Debian testing).

Fedora and "strong" passwords

Posted Feb 10, 2015 13:21 UTC (Tue) by rleigh (guest, #14622) [Link]

Really? With systemd or sysvinit/initscripts? The latter will drop you to a root shell if the root account is locked due to being sudo-only.

Fedora and "strong" passwords

Posted Feb 12, 2015 13:47 UTC (Thu) by nye (guest, #51576) [Link]

>Debian... I don't remind of it. Every installation of it I ever did asked me a root password.

As is usual with Debian, it's optional: the installer lets you either enter a root password, or leave it blank and it configures sudo for you.

Fedora and "strong" passwords

Posted Feb 6, 2015 12:43 UTC (Fri) by ssam (guest, #46587) [Link] (3 responses)

Having sshd enabled on a default install is silly. I use ssh daily, but I don't need sshd running on my laptop, because I only use that as a client. I suspect that there are a large fraction of fedora users who have never or rarely use ssh (they also probably don't participate on mailing lists). Running services that you don't need will always increase your attack surface.

If you must have sshd running by default, you should also have fail2ban (or similar) enabled by default. (Maybe sshd should depend on fail2ban).

Fedora and "strong" passwords

Posted Feb 7, 2015 0:30 UTC (Sat) by gerdesj (subscriber, #5446) [Link] (2 responses)

Fail2Ban is next to useless nowadays (that's a bit harsh but close) thanks to distributed botnets.

Spin up a honeypot with a fake sshd and watch it for a while. After a week or so you will see several 100K efforts at it, from a huge number of IPs. Each one will generally only try 1 or 2 goes before the next one kicks in and only return after a few hours. F2B wont notice.

However, you will also see the really stupid ones keep trying repeatedly - then F2B works.

On the bright side, you will have a huge list of usernames and passwords to avoid. You'll soon see patterns to avoid. Don't bother using the IPs in an IPSET on your firewall unless you are a serious honeypotter type.

Remember that the username is also a form of "something you know". Service accounts? Don't name them say sql - try sa-sql or ServAcct_SQL. Give them an MD5/SHA1 hash of a random file as a password - you'll only have to copy/paste it a couple of times (including into your password manager)

Oh dear, drifted a bit. Anyway the Fedora 8 char minimum is a bit daft for me. Anyone who is installing a Linux server distro either knows enough about security to fix up things later as required or will make far more errors later when spinning up Apache + MySQL on 0.0.0.0 + PHP + say WordPress and port forwards 3306/tcp inbound for a convenience of some sort.

Yes I have seen that (root at % had a 4 char, numeric, monotonically rising password) ...

Fedora and "strong" passwords

Posted Feb 12, 2015 14:00 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

>Fail2Ban is next to useless nowadays (that's a bit harsh but close) thanks to distributed botnets

Hmm, interesting. I've definitely found fail2ban to be catching a lot of guessing attempts, though I don't run many ssh servers on port 22 any more.

To be honest I've mostly used fail2bn as a tool for reducing the number of log messages that I get sent, because a few auth fails and a block message is far less annoying than ten thousand auth fails.

And actually, the most effective strategy turns out to be running on a port other than 22 - even something as obvious as port 2222. Every machine I've had running ssh on port 2222, some of them for something like seven years, has seen precisely *zero* break-in attempts.

Fedora and "strong" passwords

Posted Feb 23, 2015 19:02 UTC (Mon) by redden0t8 (guest, #72783) [Link]

I've seen some brute force attempts on high numbered ports, nothing compared to when I was running ssh on 22 though.

About 2 years I switched my ssh to run on the registered low-number port for another popular service. Haven't seen a single attempt since :)

Fedora and "strong" passwords

Posted Feb 6, 2015 13:10 UTC (Fri) by ssam (guest, #46587) [Link]

Is there an algorithmic way to really measure how strong a password is?

I'd like so see an something that can figure out that my 12 character (mixed case + numbers from pwgen) password is the same one that I use on numerous webforums that store it in plain text and email it to me regularly as a reminder.

Fedora and "strong" passwords

Posted Feb 6, 2015 23:00 UTC (Fri) by speedster1 (guest, #8143) [Link]

Am I missing something? Is it really a big deal to use a throwaway "strong" password during the install, and then set it to something silly immediately afterwards if the install is for a completely internal test machine? Seems to me, those users who intentionally use silly passwords after a considered evaluation of security needs are also likely to be capable of editing a PAM file (and even automating it) in order to disable strict password checking.

Fedora and "strong" passwords

Posted Feb 12, 2015 9:44 UTC (Thu) by callegar (guest, #16148) [Link] (1 responses)

For those who understand Italian, this is an almost indispensable link http://www.gattosilvestro.net/creare%20password.html.

Personally, I see a problem with these password policies. In places where passwords must contain symbols and numbers I see users convinced that this is enough to make passwords safe and where passwords need to be renewed periodically, I see users alternating the same two or three passwords or adding a numbering prefix/postfix that they increment each time. Unfortunately, there is nothing like education. Otherwise, shouldn't the system also switch on the front camera to check that there are no sticky notes with the password written on it on the desk and ask the user a few questions to verify he/she is not easy victim of social engineering?

Fedora and "strong" passwords

Posted Feb 12, 2015 22:33 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

What I want sites where registering is closer to a drive-by thing (i.e., used once or twice) is to get a one-time login link emailed to me. I'd even be okay with it for things like banking so I don't even *have* a password to steal and I can lock down my email much better and easier than dozens of sites. Of course, this assumes people are decent about locking down their email account (ideally without a perpetual login on mobile devices as well, but that's quite a pie-in-the-sky at this point).

Fedora and "strong" passwords

Posted Feb 15, 2015 10:42 UTC (Sun) by toyotabedzrock (guest, #88005) [Link]

Get some I from the maker community to make a pass a button to enter the password for the testers. Allow a config file to preset a shorter password.
Maybe add an ssh configuration with simple intended use questions.

Do you wish to run ssh
Do you need ssh root access
Do you need to access ssh from a non private IP address