Confusion: Why isn't a passhrase encrypted SSH key two factor auth?

Question

I'm trying to figure out the best practices for accessing my dev box from a public terminal.

Most sources I've found recommend protecting the box with some kind of two factor authentication, such as adding a command= prefix to the authorized_keys that forces entering some sort of one-time-password.

My question is, why is this necessary? Say I've got a pass-phrase encrypted SSH key sitting on the thumb drive. I insert the drive, enter my paraphrase and connect: in order to get into my system you've got to have the key file and the pass-phrase.

Say there's a keylogger on the public box. Now an intruder has my passphrase, but my key was never copied to the local system.

Of course once my USB drive is connected, it's possible for the key to be copied off, but is this really likely? How many keyloggers also slurp SSH keys off USB drives? How many malicious-types are watching their honeypots 24/7 waiting for activity that looks like an SSH connection?

To me it seems like a pass-phrase encrypted key is two factor. Can someone explain how it isn't?

Answer 1

A passphrase-encrypted key provides two-factor authentication, but only if used correctly. It is easy for the user to misuse the key, providing only a single factor, and the server cannot detect incorrect usage. Hence a passphrase-encrypted key cannot be considered two-factor without additional assumptions. From the point of view of the system as a whole, the passphrase-encrypted key provides two factors, but from the point of view of the server, there is only one factor, which is the private key.

The password is what-you-know. However, the password is not visible to the server. The server does not know if you used a weak password or no password at all. In any case, typing a password on a machine which may be running a keylogger is not valid use of a password for authentication.

The key file is what-you-have, but only if you do not copy it willy-nilly. Strictly speaking, it's the USB stick where the key file is stored that is a something-you-have authentication factor. The key file itself stops being an authentication factor once you allow for it to be copied off the stick.

In the scenario that you describe, where you copy the key on a machine that you do not control, is not valid usage. It transforms what you have into what the attacker also has. If the attacker can install a keylogger on that machine, he can also install a program that makes an copy of the content of every removable media that's inserted into it. What you have must be tied to an actual physical object that is not accessible to the attacker. A key stored on your own laptop or smartphone is fine. A smartcard inserted into a smartcard slot is fine (for normal smartcard usage, where the secrets do not leave the card). A USB stick inserted into a public machine does not provide an authentication factor.

And yes, there is off-the-shelf malware that grabs the content of removable media. Depending on where you plug in, it may be more or less common than keyloggers (though I'd expect the two to often go together). The attacker who installs a removable disk imager may be after authentication data, or possibly after other confidential documents. There is a resale market for corporate secrets (confidential documents, contact lists, etc.) which fosters this kind of malware, and grabbing authentication data is an easy side benefit.

With a user who may insert his USB stick into a public machine and type his password there, the passphrase-encrypted key provides zero authentication factor.

Answer 2

The General Assumption of Security(*) is:

The attacker is smarter than you, he has a bigger computer, he knows your own software better than you, and he is after you, specifically.

So one has to assume that the keylogger will also monitor SSH session and slurp keys from thumb drives. Or, more appropriately, you cannot know how much secure you are if the root of the security is a statement like "the attacker will never think of that", because such statements are inherently unquantifiable.

The extra security provided by the one-time password lies, precisely, in the one-time attribute. Note that security relies here on the idea that the attacker may slurp and spy all of your data but will not turn that into an active attack right on the spot (i.e. hijacking the one SSH connection that you are doing, as opposed to merely grab enough data to reconnect later on). A true follower of the GAS would refuse to use a public system, period.

^{(*) Don't search for it under that name, I have just made it up. The general concept of paranoia, however, is the baseline for security.}

Answer 3

Say there's a keylogger on the public box. Now an intruder has my passphrase, but my key was never copied to the local system.

If you assume an attacker has compromised a system to install a key logger, you must also assume they could do anything else on the system. Keyfiles are still considered "knowledge factors" like passwords, because they can be copied infinitely.

To be multi-factor, authentication mechanisms must use factors from two different categories:

• Knowledge factors - passwords, keyfiles, other secret data or information
• Possession factors - physical tokens, smart cards
• Inherence factors - biometrics

Answer 4

The first question you asked is: what are the best practices? The best practices are, log in via SSH using private-key authentication. Put a passphrase on your private key. Don't copy it to machines you don't trust. Configure the SSHD on your server to only allow login via private-key authentication (not via password authentication). You're good. You don't need anything fancier.

The second question you asked is: is an encrypted passphrase with private-key authentication two-factor authentication? Well, others have answered that question well. The only thing I would add is: I would caution you about ascribing magical properties to two-factor authentication. There's nothing magical about two-factor authentication that makes two-factor authentication guaranteed to be secure and one-factor authentication guaranteed to be insecure. So, asking whether something counts as two-factor authentication is probably not the right question to ask. The right question is, is my approach secure enough for my requirements? (You could also ask: why is two-factor authentication generally considered more secure, what problems does it solve, and do those apply to my particular situation?)

The answer to these questions is: in most cases, SSH private-key authentication with a passphrase-encrypted private key is good enough. Whether it counts as two-factor or one-factor is in some sense irrelevant.

Answer 5

There's some terminological confusion here I think and it's common.

Most strong multi-factor systems are considered strong because they require more than one kind of proof of identity (factor) whereas the passphrase and key in your example can both be categorized as "something you know" and are the same kind.

Common multi-factor systems use something you know (passphrase or PIN) and something you have (keyfob or device) and there are other categories used such 'something you are' (used in biometrics) and 'somewhere you are' (geo-location) in even more complex systems.

A bank may require a username/password and a PIN for online access but this is not usually considered two factor in terms of attack resistance.

Ref: https://en.wikipedia.org/wiki/Two-factor_authentication#Regulatory_definition