Web Authentication, or WebAuthn is a standard for strong user authentication and is a core part of the FIDO2 specification. I’m not going to go into too much technical detail about the spec in this blog because there already exists a plethora of awesome documents and demonstrations which explain WebAuthn better than I ever could; I’ll include those in the Additional Reading section below.
What is WebAuthn?
Phishing is still one of the (if not the) most common entry point into organisations today. The reason it’s the most common attack vector is because it’s fairly simple to carry out; even by low-skilled criminals.
WebAuthn is a modern authentication standard designed to mitigate against this threat. It also helps mitigate against man in the middle (MiTM) attacks where the attacker is able to manipulate network traffic.
In the WebAuthn world, you have two types of authenticator. A roaming authenticator and a platform authenticator. Roaming authenticators are cross-platform authenticators; they usually come in the form of FIDO2 capable USB security keys like YubiKeys. Platform authenticators are those that are built into the platform, or device. For example, TouchID on a modern Mac, FaceID on a modern iPhone or Windows Hello on a modern Windows laptop.
What makes WebAuthn special is that a tightly scoped set of credentials (public and private key) are created for each and every relying party, or website you register your WebAuthn factor with. Each credential contains metadata; one of the most important is the relying party identifier, or domain name. What makes this so special is that each credential is effectively locked to a domain. This means that if you are tricked into visiting a fake website, the credentials on your roaming or platform authenticator won’t match up with the fake website and thus won’t give up any secrets; keeping you and your identity safe.
How does it compare to existing authentication mechanisms?
I’m going to refer to a table I created to compare WebAuthn against the most common user-authentication mechanisms available today.
From weakest to strongest:
| Strength | Authentication Mechanism (when used as part of MFA) | Description |
|---|---|---|
| Why would you do this to yourself? | None | Hopefully it should be obvious why not having any secondary authentication factor is a bad idea. Unfortunately, users of a system are often not given a choice. |
| Weak | SMS | SMS is not ideal but is better than nothing at all. It will deter almost all drive-by, untargeted attacks. The security isn’t great and there are many articles which demonstrate real attack paths where criminals are able to grab the SMS OTP codes. The user experience is just as bad; you require a network signal and on occasion, text messages can take several minutes to go through, assuming they don’t get blocked by your network provider for looking like spam. |
| Strong | Push based authentication | Push based authentication is offered by the likes of Duo, Okta Push, OneLogin Protect and many others. It provides a good user experience but arguably (well, I think so anyway) poorer security experience. Many organisations which implement push based authentication do it poorly which means an attacker could frustrate a victim by bombarding them with push prompts. In these situations, it is inevitable the victim will begrudgingly accept one of the prompts; out of pure frustration or by accident. It is also susceptible to MiTM attacks which could end in successful compromise of the account. |
| Stronger | Time Based OTP (TOTP) | This is the most popular form of secondary authentication – the most common apps which enable use of TOTP are Google Authenticator and Authy. TOTP-based authentication is great; it provides a good user experience (you don’t have to wait several minutes for a text to arrive!) and good security. The secret or seed is stored locally on your device (or encrypted on a remote server in the case of Authy) and it is not trivial for someone with ill intentions to obtain your codes remotely. However it is also susceptible to MiTM attacks which could end in successful compromise of the account. |
| Strongest | Web Authentication | WebAuthn hits the ball out of the park when it comes to user experience and security. It is able to provide the fastest-time-to-authenticate but more importantly, is able to resist phishing attacks. |
Hold on. What do you mean it’s able to resist phishing? I thought TOTP-factors were able to do this already?!
Don’t get me wrong, Time based OTP authentication is/was great and served us well. It certainly does resist phishing attacks if and only if an attacker isn’t able to socially engineer or phish the victim’s OTP (usually valid for 30 to 60 seconds) in near real time.
That last sentence is crucial here. If an attacker is able to phish a victim in real time, they are able to steal and abuse the OTP or simply steal the session cookie/token returned by the application after a successful login.
You might be thinking to yourself that such an attack is farfetched and would never happen. I’ll say that I have personally seen such an attack successfully take place and that there are plenty of frameworks available that make it incredibly easy for low-skilled criminals to carry out.
So what makes WebAuthn phish-resistant? To cut a long story short, the credentials generated on the authenticator (this can be a USB security key like a YubiKey or it can be the fingerprint sensor on your phone or laptop) are scoped to the domain they were generated for.
What this means is that even if you are duped into entering your username and password into a very convincing phishing page (say evil.example.com), the browser would relay the domain name of the phishing site to the authenticator at which point the authenticator will reply with “Sorry old chap, I don’t have any credentials for evil.example.com”
Should I care?
In short and to the point: if you value the security, privacy and safety of your employees, infrastructure and customers then I would strongly encourage you to make plans to upgrade to WebAuthn backed factors as soon as you are able to.
If you already use a modern Identity Provider then a lot of the hard work is already done for you.
I’ll create a follow-up post to this one detailing my experience deploying WebAuthn, some things I did to ensure a smooth rollout and other things I would do better next time.
Leave a comment if there’s anything else you’d like to know about and I’ll either edit this post or include it in the next.