Fedora and "strong" passwords [LWN.net]

Fedora and "strong" passwords

Posted Feb 5, 2015 9:12 UTC (Thu) by jezuch (subscriber, #52988)
Parent article: Fedora and "strong" passwords

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

to post comments

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