|
|
|
|
|
|
by donmcronald
2100 days ago
|
|
|
How does a YubiKey prevent that kind of relay attack? If those keys blindly sign whatever's given to them, there's got to be a way to trick a user into signing something malicious. This [1] says that U2F avoids phishing by having the browser tell the 2FA device the domain, but that seems a bit weak to me. The same site even has an app where the info is relayed via a browser plugin, so literally relaying the data that's supposed to be trusted. The only way I can see that actually working is if the security key knew to only sign challenges for a specific domain. 1. https://krypt.co/blog/posts/prevent-phishing-on-the-web-with... |
|
|
The WebAuthn spec says: "Direct communication between client and authenticator means the client can enforce the scope restrictions for credentials. By contrast, if the communication between client and authenticator is mediated by some third party, then the client has to trust the third party to enforce the scope restrictions and control access to the authenticator. Failure to do either could result in a malicious Relying Party receiving authentication assertions valid for other Relying Parties, or in a malicious user gaining access to authentication assertions for other users."
(https://w3c.github.io/webauthn/#sctn-client-authenticator-pr...)
If you click further into the older FIDO spec, they cover this more explicitly: "Malicious software on the FIDO user device is able to read, tamper with, or spoof the endpoint of inter-process communication channels between the FIDO Client and browser or Relying Party application. Consequences: Adversary is able to subvert [SA-2].
Mitigations: On platforms where [SA-2] is not strong the security of the system may depend on preventing malicious applications from being loaded onto the FIDO user device. Such protections, e.g. app store policing, are outside the scope of FIDO."
(https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-se...)