Dealing with automated SSH password-guessing

Posted Oct 27, 2016 17:41 UTC (Thu) by drag (guest, #31333)
In reply to: Dealing with automated SSH password-guessing by mstone_
Parent article: Dealing with automated SSH password-guessing

> An ssh key pair is not two factors--it's something you have, and something you can brute force if you have the thing.

Because somebody can brute force 1FA like http-auth does that make it 0FA?

If you just have the password to the private key it's worthless without the key. If all you have is the encrypted private key and not the password it's useless. You need to have both for it to be any good. That's two factors. :)

Sure it's not a perfect solution, but there are no perfect solutions.

> It's incredibly common for people to just point to ssh keys and shrug off everything else because they're magical security voodoo,

If you think that you must have a really low opinion of everybody else. There are lots of good reasons why you would want to use ssh keys even when you have something like kerberos available.

The real problem with ssh keys isn't that they are insecure, but that it's difficult to revoke keys that have become compromised or are out dated. If you use defaults that ship with distributions then you get stuck having to use something like ansible to go and look for rouge authorized_key files, which sucks.

There are ways to mitigate this problem, however. For example you can configure your sshd servers to have public keys in a central location on each server and use puppet/ansible to manage those keys. If you are using something like FreeIPA you can manage ssh public keys via LDAP.

For many situations were you are dealing with administrators or personal systems then ssh keys can be extremely robust and continue to function correctly despite having huge portions of infrastructure broken or missing.

Having something that works when everything else doesn't is very advantageous. Being resistant to 'denial of service' is itself a important security consideration. So adding central management of auth has it's own downsides.

> but the end result in most environments is that you're entirely dependent on users to protect their keys well,

Name me ONE authentication system that doesn't depend on clients being secure. Kerberos isn't going to do it. OpenLDAP auth isn't going to do it. OTP isn't going to accomplish that either.

If you can solve this problem you will be responsible for a revolution in computer security.

> If you could trust users to always do all the right things, passwords wouldn't be such a problem...

The problem with passwords isn't that end users are stupid. There are is nothing you can do to fix that.

The problem with passwords is that they make VERY difficult for end users to do the right thing. Doing pure password approach is just bad design, pure and simple. To manage passwords correctly you need to have unique passwords for everything and you need to enter them every time. That never happens. Even you don't do it right and you know it.

And doing kerberos or otp poorly makes this worse. There is no such thing as a magic bullet here.

Dealing with automated SSH password-guessing

Posted Oct 27, 2016 18:07 UTC (Thu) by mstone_ (subscriber, #66309) [Link] (3 responses)

> If you just have the password to the private key it's worthless without the key. If all you have is the encrypted private key and not the password it's useless.

The password to unlock the secret key is in the secret key--it's offline crackable. There's also no way for you to enforce that your users even have a password. This isn't a word game, it's intrinsic to the understanding of authentication factors.

> The real problem with ssh keys isn't that they are insecure, but that it's difficult to revoke keys that have become compromised or are out dated.

Key revocation is a specific case of the general problem of ssh key management, and that's exactly the problem I'm talking about.

> Name me ONE authentication system that doesn't depend on clients being secure

You're engaging in hyperbole. A very real problem of ssh key security is that users quite often copy their keys around. You're not only relying on their client to be secure, you're also relying on every shared system that they have ever left a copy of the key on to be secure. Many places have found out the hard way that's a lot of trust.

The only one talking about magic bullets is you. Real security comes from understanding the trade offs that come with any implementation, and in my experience too many people toss around "ssh keys" as though there are no trade offs--which means that they certainly aren't doing anything to mitigate the risks.

Dealing with automated SSH password-guessing

Posted Oct 27, 2016 22:13 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (2 responses)

One solution to all of this is to use a hardware token for your SSH keys. I have a Yubikey 4 which serves this purpose, for example, though it does require some configuration on the client (PKCS11Provider in ssh_config or ~/.ssh/config) to enable integration with the OpenSC library. I believe one can accomplish a similar result by configuring GPG to act as an SSH agent.

The problem with password + key as 2FA is that the password and the key are both "something you know"; even if you only "know" the key in the sense that your computer remembers it for you, it's still just data which you have access to. 2FA requires two _dissimilar_ factors. Moving the SSH keys into a secure hardware token changes them from "something you know" (the key) to "something you have" (the hardware); combine this with a password or PIN to unlock the token and you have effective 2FA.

Administrators can enforce that only hardware token keys are acceptable for public-key authentication by configuring the tokens themselves and using a centrally-controlled authorized_keys database consisting exclusively of hardware token public keys.

Dealing with automated SSH password-guessing

Posted Oct 29, 2016 8:01 UTC (Sat) by madhatter (subscriber, #4665) [Link] (1 responses)

I agree with most of the comments above, particularly those around the impossibility of verifying that your remote users have not stripped their passwords from their stored keys. But nybble41, above, really puts his finger on my objections to drag's suggestion, with his mention of hardware tokens.

When used in the context of 2FA, something you have doesn't refer to knowledge; it refers to physical objects, because although digital knowledge can be easily copied, copying physical objects with all their internal state is still comparitively difficult, and the difference in these difficulties is what makes a physical object secure in a completely different way to something you know.

Using two physical objects wouldn't be true 2FA either, because although they are difficult to copy, they are comparitively easy to steal, when compared to the other two classes of authentication token (something you know, something you are). It is important that the two things in 2FA be from different classes of token.

I also use a yubikey to generate my HOTPs (and TOTPs, with the assistance of NFC and an Android phone to provide a timestamp for sealing). Some more details can be found here.

Dealing with automated SSH password-guessing

Posted Nov 5, 2016 17:34 UTC (Sat) by Wol (subscriber, #4433) [Link]

Dunno whether they have this elsewhere, but a lot of banks in the UK use 2FA. For example, I have a card-reader for my Barclays account (I gather the same reader will work for any bank - I know it's interchangeable with NatWest).

When I want to log in to my bank, I put my bank card into the reader, type in my PIN, and then use the resultant OTP to log in to the bank.

Likewise, whenever I want to make a payment or stuff like that to someone the bank doesn't already know about, I have to use a *different* OTP to authorise that payment. Quite often I have to sign the payment.

Cheers,
Wol