Is an SSH key with a passphrase a 2FA?

Question

This is a really theoretical question, but if I use an SSH key with a passphrase to login on a server, could this be considered as a two-factor authentication (2FA)?

Indeed, I need the SSH (private) key, which could be considered as the first factor, and the passphrase which could be the second one.

If we compare to a single password for login, I see two 'elements' with a passphrased SSH key.

Is it the key that is encrypted with a passphrase, or is it the remote server that requires both a key and a passphrase? — ig-dev, Oct 29 '19 at 23:13
If you put a sticky note with your password on it in a combination locked safe, is that 2FA? — mm201, Oct 30 '19 at 19:41
Great question for sparking some insightful commentary. I really expected the answer to be "Yes, it's 2FA," but I think I've been convinced otherwise. — Michael, Oct 30 '19 at 21:11
"use an SSH key with a Passphrase" is unclear, and as such, the answers are all over the place. @ig-dev's comment needs to be addressed, as it literally makes the difference between yes or no — Richie Frame, Oct 30 '19 at 23:14
@RichieFrame, yes sorry, I confirme that the question focuses on an encrypted SSH key using a passphrase — Antonin M., Oct 31 '19 at 08:20

score 69 · Accepted Answer · 2019-10-31T13:27:38.723

69

A second factor is defined as independent of the first factor. That means your system should stay secure, even if one of the factors is compromised (and you are aware of the compromise).

For example, a door badge and a fingerprint are independent of each other, and just having the door badge or the fingerprint is not enough to gain access. This is often called "multi-step authentication" instead of "multi-factor authentication".

Now imagine your scenario: You have a private key, encrypted with a strong passphrase. Are those two factors? No, because the private key can also exist without passphrase. An attacker that compromises the private key can thus log into your system, even without knowing that passphrase. In fact, the server is completely unaware if your private key is protected by a passphrase or not.

If you want true multi-factor authentication, there are SSH modules that do exactly that. That being said, a private key encrypted with a strong password is often enough.

Note: The original question talks about "an SSH key with a Passphrase to login on a server", which I interpreted as a private key, encrypted with a passphrase.

edited Oct 31 '19 at 13:27

answered Oct 29 '19 at 14:23

Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/100586/discussion-on-answer-by-mechmk1-is-an-ssh-key-with-a-passphrase-a-2fa). – schroeder Nov 01 '19 at 16:02
"That means your system should stay secure, even if one of the factors is compromised" By that very definition it is 2FA. Password compromised but not key? System secure. Key compromised but not password? System secure. (If you have an unencrypted key, yes the system is compromised, but the only way you get that is by having both factors.) – Paul Draper May 13 '20 at 18:23
@PaulDraper No, you conflate "the private key" with "a file containing the private key". If I get the private key, I can log in, regardless of how else the private key is secured. – May 13 '20 at 20:13
@MechMK1 "If I get the private key." And getting the private key requires the compromise of both factors. Without getting too far into it in comments, I'd suggest taking a look at other systems, like [an password-encrypted hard drive encryption key](https://security.stackexchange.com/a/231547/44419). – Paul Draper May 14 '20 at 21:59
@PaulDraper No, it does not, and the chat link above explains in gruesome detail exactly why it's not the case. – May 15 '20 at 08:07

Paul Draper · Answer 2 · 2020-05-17T20:22:15.577

15

Yes

2FA requires two different factors or categories of authentication. (They must be different categories; a password and a PIN would not be considered 2FA.)

Wikipedia provides a great list of factors:

Knowledge factors: Password, PIN, secret questions
Possession factors:
- Disconnected tokens (human-readable): Google Authenticator
- Connected tokens (machine-readable): YubiKey
- Software tokens: X.509 certificate, SSH private key
Inherent factors:
- Biometrics: fingerprint, voice, iris
- Behavior: keystrokes, signature
Location: physically secured networks

Your password is a knowledge factor; your SSH key is a possession factor.

Note that ease of duplication does not preclude an SSH key from being a possession factor. Physical keys can be copied with a camera, a printer, and a soda can; they are still a possession factor.

The purpose of multi-factor authentication is to leverage the advantages of multiple types of authentication, decreasing the risk of compromise.

Your password is short enough that it is never written and therefore difficult to obtain. Your SSH key is long and therefore hard to guess.

Together, they make a successful attack less likely.

EDIT: Several people have opined that because the key could be used unencrypted, it is no longer 2FA.

That is simply absurd.

If you can bring an unencrypted SSH key into existence without compromising two factors, and then use that information to claim that is all that is needed, why not save yourself some work and bring copies of server's files into existence?

Stating

All you need to access the server's files is an unencrypted SSH key

is no different than stating

All you need to access the server's files is a ZIP of the server's files.

But how did you get that key/ZIP? You had to compromise multiple factors. (Or there is some backdoor you are adding, like access to the server room.)

It's true that it's not a server-enforceable use of 2FA. In an organizational setting, it's often a requirement for the 2FA to be centrally enforceable. But

That's not the question.
Server-enforcement is never the final word of a security system anyway.
1. If a door requires a physical key and keypad PIN, that door is "enforcing" 2FA as much as anyone can. But when you print the PIN on all the keys, you have a 1FA system.
2. Likewise you can increase the factors. A password-protected laptop behind a door with a physical key is 2FA, despite the fact that there isn't a single component enforcing both factors. You could remove the laptop from the room and reduce security to 1FA, though until actually you do that, there is a 2FA system.

EDIT2: This answer also explains why the common practice of a separate password-protected encryption key -- which is what an SSH key is -- is two factors: the key (something you have) and the password (something you know). Someone must obtain both to produce a bare encryption key needed for data access.

edited May 17 '20 at 20:22

answered Oct 29 '19 at 23:40

Paul Draper

958
8
18

2

If your passphrase is short, it's likely brute-forceable by anyone who obtains your encrypted `.ssh/id_rsa` file, and brute-forcing is an **offline operation** in this context. – R.. GitHub STOP HELPING ICE Oct 30 '19 at 02:30
@R.. yes cracking password encryption is an offline operation. But I wouldn't call LUKS full-disk encryption useless either. (Your encryption password ought to be complex and secret, but it also has to be memorable; in case you made a mistake, requiring possession of an SSH key/hard drive is an extra layer of protection.) – Paul Draper Oct 30 '19 at 09:54
4

"If you can will an unencrypted SSH key into existence" -- Nobody is saying that we can magically create a valid key just by wishing for it. SSH key pairs can be created without any passphrase encryption, or after being generated, can be decrypted and saved in that unencrypted state. – Ghedipunk Oct 30 '19 at 21:58
2

Maybe you could add that this answer is true if the server requires both a key and a password, opposed to the key itself being encrypted with a password. That seems to be where a lot of confusion is coming from – ig-dev Oct 30 '19 at 23:59
@Ghedipunk so can ZIP archives of your server files. ZIP archives are regularly saved and transmitted. The question is: are you saving/transmitting ZIP files with less protection? Are you saving/transmitting SSH keys with less protection? If the answer is no to both, then they are irrelevant when considering security factors. – Paul Draper Oct 31 '19 at 01:01
5

@PaulDraper your addition of a "defence" is completely unnecessary. An unencrypted key has no password and is then outside the scope of the question. – schroeder Oct 31 '19 at 13:46
@schroeder IDK what "defence". But yes, a unencrypted key is outside the scope of the question. There is no unencrypted key. – Paul Draper Oct 31 '19 at 15:19
3

@PaulDraper Bascially, everything under the line ... – schroeder Oct 31 '19 at 15:20
1

As an example against this, I have google authenticator on my phone, and I have a PIN screen lock on my phone. Does just an OTP now count as 2 factors, because I need to enter a PIN to get to the OTP? – Michelle Oct 31 '19 at 17:36
@Michelle Q: "Does just an OTP count?". No just an OTP does not count. **But as I understand your question, you don't have "just an OTP".** In addition to the device with the OTP (something you have), you also need a PIN (something you know). Neither compromise of possession of your possession factor, nor compromise of your PIN, compromises the security of the system. (Now, if this is in the context of $CORP I doubt this 2FA will fit administrative requirements if it can't be centrally verified that your OTP device has a PIN. Nonetheless you have TFA.) – Paul Draper Oct 31 '19 at 20:53
@PaulDraper but if an attacker scans the QR code to read the OTP seed, my OTP is compromised and my account is compromised because my phone PIN has _nothing to do_ with my account. All the PIN does is limit opportunities to compromise my one factor, which is great, but not an independant second factor. – Michelle Nov 01 '19 at 13:08
1

@PaulDraper likewise putting a fingerprint lock on my password manager doesn't suddenly make all of my password-only accounts 2FA. Passwords can still be compromised at some point while they exist outside of the password manager. – Michelle Nov 01 '19 at 13:11
@Michelle to be honest I don't how your OTP setup is happening. My assumption was that it could be only be read/received by your phone. – Paul Draper Nov 01 '19 at 15:00
@PaulDraper Google Authenticator TOTP codes (one of your examples) are set up by scanning a QR code with your phone camera. The QR code contains a seed, which is used to generate the OTPs. Anyone with line of sight to the screen can also snap a picture of the QR code and decode it to get the seed. – Michelle Nov 01 '19 at 15:38
@Michelle it depends if you consider that a plausible attack vector. Like I pointed out earlier, a door could require biometric voice auth and memorized keypad entry, but anyone in line of sight could snap a video and replicate it. Is that 2FA? It depends on the plausibility of that attack. – Paul Draper Nov 01 '19 at 19:02

Matija Nalis · Answer 3 · 2019-10-31T23:02:54.080

15

No. Other answers are pretty close, but miss important factor.

I won't repeat in detail what other say, just summarize that for SSH key+password to be multi-factor in your case, it would have to be "something you know" + "something you possess".

What I would argue is if you need only knowledge to effectively replicate "something you have" (so nobody can tell which is original and which is copy), then it is not "something you have" but "something you know" instead.

For example, if I can't remember my password and have written it on a piece of paper, it doesn't stop being "something I know" and become "something I have". It is still just password (even if hard-to-remember), and once someone learns it, they can impersonate me any time they want without me knowing. It is the same with SSH private key. It is just data, and data is by definition "something you (could) know (and effortlessly make an exact and indistinguishable copy of)".

The main feature for something to be "something I have" is how hard it is to copy by unathorized third party, as the main feature of effective "something I have" is that the only realistic way the attacker can have it is if I don't have it anymore (as I'm bound to notice I'm missing it).

Of course, there are many many grey areas, as mentioned in some posts. CHIP bank cards would be "something I have" today, as it is not possible (without a lot of effort, people and money) to make a authentic working duplicate. However Bank card authorized only by magstripe, which any cashier can make a copy of with $25 equipment and $1 of materials is no longer effective "something I have".

Also, as technology progresses, definitions change. Once upon a time, MD4 was cryptohash. Nowadays it is most definitely NOT - it is just a hash, no better at being a cryptohash than simple Checksum.

So, "SSH private key + passphrase" actually fails at being two-factor authentication method on two fronts:

SSH private key is just information and not physical object, so it is by definition "something you know" and not "something you have".
if some authentication factor is totally ineffective at making it harder for attacker to succeed in authentication, can it still be called an authentication factor? If your server enforces 1-character-maximum password length and no limit on number of tries, is it still authentication factor? In strict theory, it might be, but in practice it is just security theater.

Note that this does not mean that ssh private key + passphrase is bad: it is much better than plain password, or unprotected private key. But it is not 2-factor.

But if you want extra security provided by two-factor authentication in ssh, you can setup 2-factor authentication in ssh, preferably in addition to having it's private key protected with passphrase.

edited Oct 31 '19 at 23:02

answered Oct 30 '19 at 11:14

Matija Nalis

2,115
12
18

2

A yubikey is a physical object that "just" contains information, so why does it count as a 2FA and a private key doesn't? – Conor Mancone Oct 30 '19 at 17:00
3

@ConorMancone I don't want to put words in OP's mouth, but the information contained in the Yubikey cannot be extracted. I think OP is suggesting that information that can be _duplicated_ is always "something you know," in the same way that a physical door key is (for you) a thing that you have, but is practically speaking _information_ encoded in ridges and troughs for any locksmith. – Michael Oct 30 '19 at 21:00
1

@ConorMancone as Michael says, it is all about availability of that information to attacker. You (nor I, nor Joe Random Hacker) **can not** get to that private key information stored in yubikey in order to duplicate it. On the other hand, ssh private key stored on USB memory card is **trivial** for anybody to read and duplicate (just copy&paste!), so is no different than plain old password written in text file on your USB memory card (or on piece of paper) -- so not really "something you have". But if/when someone finds a exploitable bug in yubikey, it too will stop being useful 2nd factor. – Matija Nalis Oct 30 '19 at 23:22
1

I agree with the benefits of the "something you have" as something that can't be copied, but is that a fundamental definition for the factor? Is that what makes it a discrete factor? – schroeder Oct 31 '19 at 13:49
@schroeder Yes. The same as biometrics can only be an separate factor if you can only be authenticated by being scanned physically. If you can easily fool biometric retina scanner by wearing fake contact lenses printed on your 3d printer for $1, it stops being "something you are". Definitions change over time. – Matija Nalis Oct 31 '19 at 14:53
3

This answer does a good job of laying out why SSH key+password is not 2-factor. But an uncareful reading of it might lead someone to think there's no point to encrypting your SSH key. Using multi-factor auth and encrypting your SSH key address different types of attacks, and thus both are valuable. – kbolino Oct 31 '19 at 20:12
2

@kbolino good point; I've updated the answer to mention that point (and link to a way to have 2-factor auth implemented in ssh) – Matija Nalis Oct 31 '19 at 23:04
@MatijaNalis, the ease of duplicating it is relevant for it's strength as a factor, not its existance as a factor. E.g. bubble gum or a camera phone can copy a mechanical key's info in seconds. That weakens the security of mechanical keys as factors, but that doesn't make them "not a factor." – Paul Draper May 14 '20 at 22:04
@PaulDraper I politely disagree. Attacking computer **cannot** automatically take a picture of your physical key, make another physical copy of key, teleport it to its keyhole and turn it. But attacking computer **can** copy and later use your `~/.ssh/id_rsa` as easy as it can copy and later use your password. They're both a same thing - just a stream of bits. Hence, they are "something you know". Whether such stream of bits is written in disk file (or on a piece of paper) is irrelevant - it does not become "something you have" because of the fact. – Matija Nalis May 15 '20 at 23:27
@MatijaNalis everything is information ("bits" if you put it in base-2). A physical key is information. It just depends on whether that information is possessed mentally or physically. That's why [Wikipedia](https://en.wikipedia.org/wiki/Multi-factor_authentication#Software_tokens) list software tokens -- x509 cert, SSH key -- to be "something you have." (In theory it would be possible for a person to know a physical key or SSH key or x509 cert and then transcribe that, but that's stretching the definition.) – Paul Draper May 17 '20 at 20:13
@PaulDraper all information used in computer security can be encoded in bits; in fact it **must be** before it is sent for processing. Be it password, hardware token, or your retina scan. It does not mean everything can be at most 1FA. The difference is that password and ssh key is **only** used (and abused) in exactly the same way - directly as pure information. As you note, one **can** remember 64 byte ECDSA key, and one can make complicated 100-byte password and store it in text file. The attacking compter will use **exactly** the same technique to abuse them - so they're IMHO just 1FA. – Matija Nalis May 18 '20 at 21:36
1

@PaulDraper in reality, the terminology is moot (and wikipedia is often not the best source for computer security issuses). I would argue people **should be focused on the amount of security some measure gives them**, and not the names (oft. abused for profit). For example, having smartphone with few years out-of-date software (and thus probably trojan on it) and using 3FA (password, PIN-protected software token, and fingerprint scan) -- all on that same phone that attacker controls, leaves you very probably *much less* protected than just using 1FA HW OTP and up-to-date GNU/Linux laptop. – Matija Nalis May 18 '20 at 21:47
@MatijaNalis I very much agree with the fact that "2FA" =/= "great security" – Paul Draper May 19 '20 at 01:30

Ghedipunk · Answer 4 · 2019-10-30T16:43:23.860

From the point of view of the service: No, a passphrase protected SSH private key is not multifactor authentication.

The SSH server has no way to know whether the private key is encrypted or not, and has no way to know what that current passphrase may be in any case. The closest that the server can get is, if the key pair is generated on the server, it can capture the passphrase at that time. (This would be very unusual, and I'd question the security of any system that does this.) Once the private key has left the server, though, the only thing it can assert is that, at one point someone used the passphrase to decrypt the key. The server does not know if it was decrypted seconds ago as part of authenticating or if they private key is currently sitting on the client machine's disk completely unencrypted.

So, while it is a good practice to encrypt the private key with a passphrase, the authentication handshake between the client and server do not use that passphrase, thus the passphrase is not part of authentication.

As to whether or not the private key is something you have or something you know, I argue that it is something you have, because you are not passing the private key directly to the server, you are proving that you have the private key:

The authentication handshake goes like this:

The client selects a key to use and sends the key's ID to the server.
The server gets the public key from ~/.ssh/authorized_keys, generates a nonce, and encrypts it with that public key.
The client decrypts the nonce with its private key, then MD5 hashes it with the shared session as salt.
If the server gets the expected hash back, the user is authenticated.

This is a different process than passing a password; you are proving more than just knowledge, you are proving that you have a system capable of performing decryption on a message encrypted with a specific public key.

In physical security, something you know would be implemented with a challenge-response: The guard calls out a word, and you respond. (This also authenticates the guard. Don't give the password of the day to someone just because they're wearing a uniform.)

Similarly in physical security, something you have is a key. Yes, the key contains information that is easy to copy and could even be memorized, but unless that data is cut into a physical object, the data does no good. With a key, you are proving more than just knowledge, you are proving that you have an object capable of lifting the tumbler's pins to the correct height. And just as the passphrase on a private key is not part of the authentication, whether the tool used to turn the tumbler is the intended key, a copy, or a set of lock picks is also not part of the authentication.

I don't think the fact ssh is proving in challenge-response it has a private key instead of passing it directly classifies it as second factor. You can use plain password it that way too (like for example [APOP](http://www.rfc-editor.org/rfc/rfc1939.html#page-15) or [CHAP](http://www.rfc-editor.org/rfc/rfc1994.html#section-2)) - it's just implementation detail. Otherwise, one could *claim to have 2FA with only a password*: by sending half a password directly, and half via APOP/CHAP-alike protocol (implemented in javascript for example). — Matija Nalis, Jun 02 '20 at 09:01

score 2 · Answer 5 · answered Oct 31 '19 at 22:28

Well, there's a couple of answers that are correct but where the subsequent arguments raging in the comments show that they are not clear enough, so I think there's still space to stress the following key point:

Multi-factor authentication is an authentication policy where the verifier demands multiple (and ideally independent) authentication factors from the claimant.

The setting here is some sort of authentication protocol with two parties:

A claimant that claims a specific identity and must prove it;
A verifier trying to confirm the claimed identity and reject impersonators.

In SSH, the claimant is the client and the verifier is the server. In the most common configuration the server doesn't demand that the client's private key be encrypted with the password, which means it's not MFA. It's just the client's discretionary choice to encrypt their private key.

Stuart Sloan · Answer 6 · 2022-02-09T21:46:52.220

0

Yes, this is MFA and let me explain. The passphrase is the "something you know," The SSH key is the "something you have." You need both to log in.

If you knew the passphrase but didn't have the ssh key, you would not be able to log in because you only have one factor (something you know). If you had the encrypted SSH key but didn't know the passphrase to decrypt it, you still won't be able to log in because you only have one factor (something you have). You need both factors to log in hence MFA.

Where it gets tricky is enforcement. The server has no guarantee that the key wasn't decrypted then stolen. The attacker could log in with only a single factor in this scenario, but the original question wasn't about enforcement. The original question asked if a passphrase encrypted SSH key was MFA, and to answer that question with those specific restraints, you would have to say yes.

edited Feb 09 '22 at 21:46

answered Feb 09 '22 at 21:33

Stuart Sloan

103
4

@schroeder better place? – Stuart Sloan Feb 09 '22 at 21:34
Yes, but this is also a much better constructed answer. It's still wrong, but you've avoided all the other problems. – schroeder Feb 09 '22 at 21:57
The act of joining the factors on the client side negates it from being a multi factor. Just like if you need 3 people with a password part to get access, isn’t a multi factor authentication. (It’s still only the 1 thing you know factor). – LvB Feb 10 '22 at 09:33
Right that’s not MFA because three people with a password is only one factor (something you know) used three times. You need two or more different factors for MFA. The passphrase protected SSH key is two different factors. The password (something you know) AND a key (something you have). – Stuart Sloan Feb 10 '22 at 15:53

leopold.talirz · Answer 7 · 2022-08-21T18:49:56.197

Given that the basic definition of multi-factor authentication leaves some room for interpretation (for example: Is an SSH key "something you have" or "something you know"?), it seems to me that the answer to this question requires a more detailed definition from an authoritative source.

I came across the Digital Identity Guidelines by the National Institute of Standards and Technology (NIST). Section 5.1.8 deals with "Multi-factor Cryptographic Software" and defines:

A multi-factor software cryptographic authenticator is a cryptographic key stored on disk or some other "soft" media that requires activation through a second factor of authentication. Authentication is accomplished by proving possession and control of the key. The authenticator output is highly dependent on the specific cryptographic protocol, but it is generally some type of signed message. The multi-factor software cryptographic authenticator is something you have, and it SHALL be activated by either something you know or something you are.

Section 5.1.8.1 makes a couple of recommendations for such software:

Multi-factor software cryptographic authenticators encapsulate one or more secret keys unique to the authenticator and accessible only through the input of an additional factor, either a memorized secret or a biometric. The key SHOULD be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access. Multi-factor cryptographic software authenticators SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.
Each authentication operation using the authenticator SHALL require the input of both factors.
Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen numeric value at least 6 decimal digits in length or other memorized secret meeting the requirements of Section 5.1.1.2 and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.
The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place

My takeaway from this document is that, according to NIST:

A cryptographic key stored on disk (such as an SSH key) is "something you have".
A cryptographic software authenticator should follow the recommendations listed in section 5.1.8.1, such as
- key stored in suitably secure storage with limited access
- discourage cloning of the key onto multiple devices
- each authentication requires input of both factors
- rate limits on activation
- key zeroized immediately after authentication

I believe some of the recommendations listed above are not in place when simply using a password-protected SSH key (rate limit?). That said, it certainly seems possible in principle to build a compliant multi-factor cryptographic software authenticator that uses a SSH cryptographic key and a password you know.

score -2 · Answer 8 · answered Oct 29 '19 at 19:46

-2

Adding on to @MechMK1 's answer, The 'Factor' in Authentication mechanisms fall into 3 categories-

Something you know - Passwords, PIN
Something you have - Credit cards, USB drives
Something about you - Bio-metrics, Facial recognition

If you now want 2FA, You need to pick one from each category. Eg. Fingerprint plus Password, Credit card plus PIN etc etc. Having two factors from the same category is as good as having only one. Eg. Two passwords don't count as 2FA.

Coming back to your question, SSH Key and Passphrase also belong to 'Something you know' and hence, don't count as 2FA.

answered Oct 29 '19 at 19:46

Ayush Ambastha

73
6

8

Unless you're memorized your SSH Key (which seems very unlikely), you could argue that the key is "something you have", and the password is "something you know". As a result, why doesn't it count as 2FA given your outline? – Conor Mancone Oct 29 '19 at 19:55
8

I agree with Conor: The SSH key is something you have. It's only because the passphrase is tied directly to that SSH key that I would argue that they're not separate factors. If the passphrase and key were unrelated, then they would be separate factors. – Ghedipunk Oct 29 '19 at 20:00
8

That is, the passphrase protects the private key, not the authentication. I can decrypt the private key whenever I choose, and the service I'm authenticating with would be none the wiser. – Ghedipunk Oct 29 '19 at 20:07
1

@Ghedipunk: Can you post that as an answer? That's the key piece of reasoning that justifies my intuitive sense that it's not 2FA. I was having a hard time formulating it (server doesn't *independently* check both things) until reading your comment. – Peter Cordes Oct 30 '19 at 13:29
@PeterCordes That is actually exactly the content of my answer. – Oct 30 '19 at 14:23
1

@MechMK1: Your phrasing didn't put it as succinctly or even as clearly (at least for me), unfortunately. That's probably why commenters on your answer (especially @R.) felt the need to rephrase and highlight key points in other words. – Peter Cordes Oct 30 '19 at 14:32
@PeterCordes I edited the answer to clarify it more. It was a good point to raise, though – Oct 30 '19 at 14:33
1

@ConorMancone following that to conclusion, one could also argue that in classical username/password authentication only (usually known as single factor auth) your username is "something you know" and the password you have written down on paper (as it is too bothersome to remember) is "something you have", so it is actually two factor authentication. I'd argue instead that if you can use simple `cp(1)` to make exact duplicate of some authentication factor, then it is "something you know", not "something you have". – Matija Nalis Oct 30 '19 at 23:32
@ConorMancone I think you're right. I missed out on that. Thanks for pointing it out! – Ayush Ambastha Oct 31 '19 at 03:50
1

@MatijaNalis No, because a usernames or e-mail addresses are not confidential information. Therefore they are not factors to consider when authenticating. – Oct 31 '19 at 12:44
@MechMK1 feel free to replace that with half a password (or a few letters) remembered, and rest of password written down on paper. Is that 2-factor authentication then? – Matija Nalis Oct 31 '19 at 14:39
1

@MatijaNalis No, because the server does not care how you store your password. The server sees one factor: the password. – Oct 31 '19 at 14:41
@MechMK1 And if server asks for two passwords (like common "password" and "security question" mechanisms in use today), and you keep password written down on paper, and remember your security question, is that a 2-factor authentication then? The server asks for and gets two separate inputs. But two separate inputs does not imply two factor IMO. Nor do different channels means different factor - for example, if the server required that you send one password via web form, and another via email, it would not count as two-factor (even if it might improve security somewhat) – Matija Nalis Oct 31 '19 at 14:59
@MatijaNalis Two passwords would be 2FA in theory, but given that they would likely be stored in the same way (e.g. the same keepass database), it is also very likely that they would be compromised at the same time (thus rending the benefit of 2FA moot). But for instance a password and a one-time key sent via e-Mail would be a viable approach. – Oct 31 '19 at 15:04

score -3 · Answer 9 · answered Oct 29 '19 at 23:23

-3

No. They are not different factors. An encrypted ssh key is not "something you have", since it is not an object you need to physically control (it is still much better than a plain password, though).

On the other hand, a ssh key that was stored on a usb authentication device (a Yubikey, U2F...) would qualify as a second factor.

answered Oct 29 '19 at 23:23

Ángel

17,578
3
25
60

2

A private key isn't something that you know or something that you are, though. (Out of the world's population, perhaps a thousand can recite over 30 digits of pi from memory.) As for me, every private key I have is physically stored somewhere (electrons/magnetic fields arranged in some digital memory... graphite/ink on paper, etc), it isn't something I know. – Ghedipunk Oct 29 '19 at 23:32
2

It doesn't need to be something you know by heart, Ghedipunk. It is sometimes expressed as "a knowledge you have". It doesn't matter if you have memorized it or it is stored on a hard disk or notebook. See for instance that a password will be a "knowledge you have", even if it is an extremely long password on a .txt file, it's not a "something you have". Note that the key is that you need to have possession of the object in order to use it. You do not need to have a notebook or usb drive in order to use their contents. – Ángel Oct 29 '19 at 23:42
4

@Ángel EVERY authentication factor can be expressed as "something you know" when authenticating with a remote service. It's all converted to data for transit. (Hence I don't think your argument is much good, since it produces this degenerate "2FA can't exist online" result.) – Brilliand Oct 29 '19 at 23:49
1

@Ángel if you have data about a physical key (a photograph), you effectively have the key. But a key is "something you have", not "something you know". – Paul Draper Oct 29 '19 at 23:51
2

@Brilliand, you company/bank provides you with a [SecurID](https://en.wikipedia.org/wiki/RSA_SecurID). The data in transit is not usable for further authentications. Thus by showing showing something that can only be a "something you have", I probe that the 2FA may exist. QED. – Ángel Oct 29 '19 at 23:58
@Ángel The secret key used in generating the code, and the generated code itself, are both data that would defeat the security if known by an attacker. The secret key is kept in a hard-to-crack physical box, yes, but it's still information - and the generated key is a pure password if an attacker can react quickly enough. – Brilliand Oct 30 '19 at 00:06
The OTP is not the second factor, only a way to probe that you physically have the device. Copying your code doesn't break that. A better case for a "something you have" that briefly lived as a "something you know" would be the setup of a new code in a TOTP app living in a smartphone. It is usually accepted as a "something you have", but it would not be completely pure such as a SecurID or, even better, a yubikey would be. – Ángel Oct 30 '19 at 00:13

Is an SSH key with a passphrase a 2FA?

9 Answers9

Yes

Linked