0

Correct me if I am wrong, please.

I understand that 2FA (MFA) increases account security in case an attacker obtains a password which might be possible via various ways, e.g. phishing, database breach, brute-force, etc..

However, if the host where one uses the 2FA device is compromised (full system control) then 2FA is broken. It's not the same as haven the password being compromised but conceptually this is similar.

Do hardware security keys protect against compromised hosts? I read that the private key cannot be extracted from those security devices. I think about protecting my ssh logins with a FIDO2 key. Taking ssh as an example, I would imagine that on a compromised host the ssh handshake and key exchange can be intercepted and this way an inserted Fido2 key can be used for malicious things.

Additionally: Fido2 protects against phishing by storing the website it is setup to authenticate with. Does FIDO2 and openssh also additionally implement host key verification or doesn't it matter because FIDO2 with openssh is already asymmetric encryption and thus not vulnerable to MitM attacks?

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
Big X
  • 3
  • 1
  • 1
    I read this multiple times and still can't parse the first two paragraphs. I suggest you get rid of them. You're also asking two separate questions: one about FIDO in general, and another about FIDO use for SSH. These should be split into separate QA posts. – Steve Sep 10 '20 at 20:57
  • I don't understand what you mean with *"if the 2FA device is compromised"* together with *"Do hardware security keys protect against compromised devices"*. Since the hardware security key itself is the 2FA device your are talking about in the first phrase your second phrase means no sense for me. Also, a compromised hardware key means that the attacker owns the key (stolen or cloned) or can somehow run its own software on it (how?). The latter case is unlikely but in this case the security would depend on the protection offered by the specific key hardware and firmware - which is unknown. – Steffen Ullrich Sep 10 '20 at 22:20
  • @Steve I agree but Ángel already gave a quite exhausting answer also referring to those paragraphs. I am not sure about removing them but if you can, feel free – Big X Sep 11 '20 at 16:21
  • @Steffen I also agree that this was quite unclear, but again Ángel basically eliminated this ambiguity by answering to any possible interpretation. Again I am not sure how to improve the question. What I initially meant was whether hardware security keys increase security even if the computer to which such a device is connected (e.g. via USB) is compromised. – Big X Sep 11 '20 at 16:21
  • @BigX: I've tried to rework your question so that it gets more clear what you consider compromised - the host system and not the security device. Please check if this matches what you wanted to ask. – Steffen Ullrich Sep 11 '20 at 17:29

1 Answers1

1

I understand that 2FA (MFA) increases account security in case an attacker obtains a password which might be possible via various ways, e.g. phishing, database breach, brute-force, etc..

Right. With 2FA you need a second factor to authenticate. For example, not only you give the passcode to the guard (something you know) but he also looks closely at your face to ensure that you are "Big X", and not "Spy Z".

However, if the 2FA device

I guess you refer to the common practice of using "something you have" as second factor.

is compromised (full system control)

Depending on the device, this could be quite hard, consider for instance a hardware token: SecurID hardware token

How would you go about compromising it?

which can also be the very same device then 2FA is broken. It's not as likely as opposed to only using a password but conceptually this is true.

If you compromised the second factor (e.g. the 2FA is in a smartphone app, and the smartphone is compromised) then the second factor is compromised. You still need to also compromise the first factor (phishing the credentials, compromising the computer from which the system is accessed...).

Or you may be referring to compromising a smartphone which has an app generating the OTP tokens and is used to access the remote system. Then yes, you didn't truly have a second factor, as it only needed compromising a single device.

Do hardware security keys protect against compromised devices? I read that the private key cannot be extracted from those devices.

Generally yes. The key is guarded by the hardware device. So if you use a compromised computer to do online banking, with a hardware security key as second factor, an attack wouldn't be able to log in as you later, since he would need the second password: to have the hardware device on his possession.

Please note that it wouldn't preclude the attacker to getting access to your bank page when you log in there. Also, there are multiple types of second factor hardware devices. While all of them require possessing the device itself (this may not completely hold if it's based on a software implementation, though), there are multiple ways of interaction:

  • Some of them require the user to take an action, such as providing the code showed on a
  • Some just need to be connected, and they get activated by the computer (sometimes after providing a password). In this case, a compromised computer might be able to get more codes than the user expected.
  • Others are commanded by the computer, yet they need physical interaction from the user for authorization, such as pressing a button or disconnecting and reconnecting the device. Some even have its own keyboard, so they can be feed a password without the (potentially compromised) computer learning about it

Do take into account the limitations of each approach. A compromised computer could ask you to confirm (via the hardware token) the action "Pay $50 bill to the utility company", yet what it is actually having you sign is "Transfer all the available money to the attacker's overseas account".

The hardware device confirms that the person holding the device the approved the action. However, it doesn't protect the integrity of the message the owner wanted to sign.

In some cases, where the device is not directly connected to the computer, it would even be possible to bypass the through a phishing page. The user provided the second factor bank token to log into the bank account, it just was not the bank web page (the extra effort is that they would need to perform the log in / actions exactly at that moment, as otherwise they would not have the temporary code).

I think about protecting my ssh logins with a FIDO2 key. Taking ssh as an example, I would imagine that on a compromised device the ssh handshake and key exchange can be intercepted and the Fido2 key can be used for malicious things.

The key can be used to sign messages. Just that. If your use f the key is to log in by ssh, it could be used to log in through ssh (which may require hardware confirmation, per above).

Additionally: Fido2 protects against phishing by storing the website it is setup to authenticate with.

More or less.

Does FIDO2 and openssh also additionally implement host key verification

I'm not aware of a specific security key using WebAuthnfor openssh, although I guess that could be done.

Also note that often keys support multiple standards. So you could have a key that supported FIDO 2 and also allowed ssh logins, but the later could be though an interface quite different than the one for FIDO.

or doesn't it matter because FIDO2 with openssh is already asymmetric encryption and thus not vulnerable to MitM attacks?

A ssh login through private key is not vulnerable to a MiTM sniffing the login credentials, since they are never sent on the wire. The user only shows possession of the private key. Which can be in a local file, or in a hardware device, it doesn't matter. It's out of reach of a network attack

However, if you don't do any host key verification, then the attacker could replace the machine you connect to, allow you access to their machine, and then get advantage of the actions you do on that one (like inputting passwords on that remote machine which is not the one you thought it was).

Ángel
  • 17,578
  • 3
  • 25
  • 60