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