When I first started getting involved in FIDO authentication technologies circa 2018, I frequently encountered news articles and marketing literature claiming FIDO as a "phishing-resistant" authentication technology. To a security professional this is attractive, particularly given the real-time phishability of most MFA technologies such as one-time passwords, QR Codes and mobile-push based transaction confirmation.
Curious to learn more I went searching for a technical answer, and found remarkably little (i.e. nothing) answering this specific question - why is FIDO authentication considered phishing-resistant?
In this article I'm going to explain my interpretation of the real-world characteristics of deployed FIDO authentication scenarios that make them resistant to traditional credential phishing attacks.
What is credential phishing?
For the purposes of this discussion, I define credential phishing as the process whereby an attacker gains access to a victims account by tricking the victim into supplying login credentials to the attacker instead of the legitimate site. This is typically achieved via a man-in-the-middle (MITM) vector:
- the attacker presents the user with an experience that looks just like the legitimate experience - often real-time scraped from the legitimate site
- the victim supplies their credentials to the attacker, thinking they are supplying them to the legitimate site
- the attacker uses these credentials to login to the legitimate site as the victim
This type of attack is effective both in gathering passwords, and defeating most other forms of multi-factor authentication. It even works for mobile-push based out of band transaction confirmation solutions in circumstances where the attackers MITM technology is simultaneously interacting with the legitimate site just as the victims browser typically would.
The weak link that makes this style of attack effective is encapsulated in these words from the description: "tricking the victim
". There is an implicit assumption by the legitimate site that a potential human victim can recognise a fake site from the legitimate site
Unfortunately this is not always the case. For example can you tell the difference between these two URLs (this is just representative):
The latter string contains a cyrillic е
(UTF8 encoding 0xD0 0xB5) rather than the expected ascii e
(UTF8 encoding 0x65). The takeaway here is that it can often be tricky for even security-aware individuals to recognise credential phishing in action.
What's different with FIDO?
FIDO authentication in practice has two key characteristics that work in concert to mitigate phishing attacks.
Credentials are scoped
A FIDO credential is a public/private keypair, with additional properties associated with that keypair. One of these additional properties is called the relying-party identifier (rpId). Think of the rpId as a namespace - it indirectly identifies the location(s) where the credential is intended/allowed to be used. We say "intended" here, because the authenticator that is responsible for protecting the private key doesn't itself have visibility into the site the user is interacting with. That brings us to part 2 of the phishing-resistant secret sauce.
Authenticity of the target site is the responsibility of the FIDO Client
The FIDO Client, a computer program, is responsible for ensuring that the site to which it is connected and sending signed FIDO authentication payloads is authoritative for the rpId being used.
work. A more detailed description including examples of permitted rpId values in WebAuthn with respect to the site the browser is connected to can be found in the rpId definition in the WebAuthn Specification
Suffice to say that the browser plays a pivotal role
in deciding whether a FIDO credential may be exercised in WebAuthn calls originating from a particular website, and the browser can reliably determine the site it is connected to via established https server authentication. In the following screenshot you can see where I have attempted to exercise WebAuthn using an rpId of google.com
from a page originating from fidointerop.securitypoc.com
. The browser makes the decision to deny this - not the authenticator, or the human.
So where does human trust fit in?
In a typical FIDO authentication scheme the responsibility of the human is to ensure they are using trusted FIDO Client software. In the case of WebAuthn this means using a browser they trust installed with a set of trusted root certificate authorities. Trust in the browser is an established universal pre-requisite for humans using web applications. Commonly the browser and its trust roots are pre-installed as part of the operating system, which the user is implicitly trusting anyway.
In the case of other types of native/thick client applications acting as the FIDO client, the same principals apply. The human needs to ensure they are running the real client app (not a trojan) that they trust, installed from a trusted source. This is a much more reasonable expectation than requiring the human to visually recognize the real site and user experience vs an attacker-controlled environment.
FIDO authentication is considered phishing resistant because the decision about whether a particular scoped credential
may be used and the results shared with a server endpoint is delegated to security mechanisms within a trusted computer program
such as the browser rather than the human having to visually recognise a phishing attempt themselves.
I hope that this helps you understand and explain this very important characteristic of FIDO authentication. Phishing-resistance is one of the key differentiating features of FIDO and why both website providers and end users should embrace FIDO-based authentication technology.