Administrator’s Guide, Part 3: What Makes Passwordless, Dare We Say It, Phish-Proof?
Part of our Administrator's Guide to Passwordless blog series
In some ways, the term “passwordless” is a misnomer. Yes, it’s a password-less authentication method, greatly streamlining the login experience, and while that’s a great incentive to use passwordless for logging in, it’s not an improvement in authentication security in and of itself.
Passwordless uses multiple factors in one step. Unlocking authenticator devices locally removes the threats of credential reuse and shared secrets. But on top of all of that, passwordless authentication should also raise the bar by substantially reducing or even eliminating the risk of phishing attacks. Any “passwordless” solution that cannot meet this bar is simply inferior.
That isn’t to say that every password-less solution needs to be phish-proof. There may be other properties of an authentication solution you’re considering that make it a better fit for your environment, and you may be able to mitigate the risk of phishing using additional authentication factors. While not every solution will use the same mechanisms to prevent phishing, there are some properties that will be common to every solution that is truly phish-proof.
To prevent phishing, there are a few general properties that your authentication solution needs:
No Shared Secrets is the property that secrets are never shared and are always kept local to the authenticator device. The authenticator will use these secrets to sign messages, which can be verified by the other party to only have been able to come from the authenticator device. Unlike passwords or other shared secret-based approaches, the solution should guarantee that the secret used for one website is distinct and separate from any secrets used for other websites.
Origin Binding is the property that the site you (as a user) are attempting to log in to must match the domain, or origin, of the site you’re actually on. The history of active phishing has taught us that this is not something that the user can be relied upon to do, so any solution must avoid being dependent on the user checking the domain before authenticating.
Secrets, or credentials, should be linked to the domain upon which they were registered, and should not be unlockable without an automated check that the user is actually on that page. From our first No Shared Secrets property, we should be guaranteed to have different credentials for different sites, and so while a phishing site should be able to gain access to credentials for its own domain, it must never be able to access credentials for another site.
Channel Binding is the property that the communication channel from the authenticator to the website must be strongly tied to the browser session attempting to authenticate. Put another way, an attacker attempting to log in as the victim should be unable to reach the user’s authenticator to prompt the user to log in. Doing anything else would make push phishing attacks viable. There must be a guarantee that only the user’s browser (or other legitimate software) can activate the authenticator device. The channel between the browser and authenticator must be bound. This is the most nebulous of the three properties, and the one that authentication solutions most often fail.
Let’s dive into how WebAuthn and FIDO2 implement these properties and provide a very robust resistance to phishing. To start, compliant authenticator devices exhibit the No Shared Secrets property by design. The authenticator generates a new keypair, or credential, for every website, and then registers the public key with the website so its signed messages can be verified during later logins.
In a WebAuthn login, the browser itself (not the website) passes the origin of the page to the authenticator device to be included in the signed assertion response. Because of this, the signed assertion is only usable by the page matching the origin. No other site will accept it. This eliminates the ability for passive phishing, such as a site with UI elements that mirror a victim site. Because the origin also includes the https:// scheme (and WebAuthn requires TLS), this also prevents active phishing attacks, even those using a TLS-stripping attack.
The WebAuthn protocol supports only a few mechanisms for invoking authenticators. One such method is looking for a platform authenticator built into the access device, such as Windows Hello, Touch ID/Face ID, or Fingerprint/Face Unlock on Windows, Apple, and Android devices, respectively. Because this authenticator is built into the access device itself, the channel binding between the authenticator and browser session is straightforward. An attacker cannot, without already having substantial privileges on the victim’s device, invoke the victim’s platform authenticator to push phish the victim.
The other category of WebAuthn-compliant authenticators are roaming authenticators. These authenticators are not attached to the access device itself, and can be used across many different devices. They may plug in via a USB port, like a Yubikey, or connect via Bluetooth or Near-field communication (NFC). In each case, it is critical that an attacker cannot invoke the authenticator.
For USB-attached authenticators, the act of plugging the authenticator into the access device typically gives the access device exclusive access and control over the authenticator, very similar to platform authenticators. Bluetooth authenticators require an explicit pairing step by which the user links the access device and the Bluetooth authenticator. An attacker should not be able to invoke the Bluetooth authenticator remotely, unless they can somehow trick the victim into pairing the Bluetooth authenticator to the attacker’s device.
NFC is only usable over short distances of a few inches. This should give similar properties to those of a USB-attached authenticator, under the assumption that an attacker would have to bring a physical device in very close proximity to the victim’s authenticator. Proximity-based controls, such as those for NFC, are vulnerable to relay attacks that can break the important channel binding property. In practice, however, relay attacks are typically targeted and affect individual victims. They are more similar to biometric spoofing attacks in complexity and specificity than the more widespread phishing techniques used against passwords and 2FA today.
Because WebAuthn and FIDO2 achieve these security properties, products based on them tend to be some of the most secure, phishing-resistant authentication methods. However, let’s also talk about some common anti-patterns among password-less solutions, where they violate these properties, and what vulnerabilities they introduce.
Push 2FA
Push notification-based methods are great for mitigating the risks of password-based authentication, but they’re often phishable. Whether the notification comes from an SMS message or an app, or whether the push requires biometric verification (making it multi-factor), push-based solutions typically have weak or nonexistent channel binding properties. An attacker who is able to enter a victim’s username into a login prompt configured to initiate a push becomes capable of initiating pushes to the victim’s phone on demand. This is because normal operation lacks a channel binding the user’s browser session to the user’s phone, so it’s difficult to differentiate (and block) an attacker’s browser sending a push to the victim’s phone.
When push is used as a second factor in conjunction with a primary factor, such as a password, this risk is reduced because an attacker must additionally know the victim’s password. However, if push-based authentication is used as a primary factor, push phishing becomes a much greater threat.
Tip: In evaluating any Push-based passwordless solution, look for documentation on how the solution binds the access device’s browser session to the push device in such a way that anonymous actors cannot push phish your users.
QR Code Scanning
Some authentication solutions rely on QR codes to bootstrap or transfer trust from one device (often a mobile phone) to another (often a PC). Take the following example: A user attempts to log in to a website on their PC. The website displays a QR code for the user to scan with their phone. The user scans the QR code and their phone initiates an authentication, such as a Face ID scan. When they complete the Face ID scan, the phone informs the website of the user’s identity and the website allows the PC to log in as that user.
Unfortunately, this authentication model breaks the channel binding property we need as well. To illustrate, a victim can be phished and end up on a page that looks identical to the site they’re where they’re attempting to log in. However, the QR code displayed to them could come from an attacker, which when scanned, ultimately allows the attacker’s browser session to log in as the victim. This general category of attacks is known as QRLJacking.
The victim doesn’t even need to land on a phishing site for QRLJacking attacks to be effective. QR codes are indecipherable to humans, but can contain virtually any text, including various URI schemes. App Links or Universal Links are links designed to automatically open and invoke some mobile application. Imagine someone scanning a QR code on a digital billboard, only for their authenticator app to be invoked, use Face Unlock and WebAuthn to authenticate them, and position them only one confirmation click away from returning a response that will log an attacker into their account. Authentication methods that use QR codes to proxy authentication between devices are scary.
It’s also important to note that the risk of QR code scanning is reduced depending on the context in which it is performed. There are many solutions that use QR codes to initially set up an account or an authenticator for the first time, such as during the creation of an initial OTP seed. Since these QR codes are typically scanned just one time to set up the account and the user is typically already engaged with the specific enrollment session, the risk of an attacker breaking the channel binding by man-in-the-middling the QR code is greatly reduced compared to solutions that use QR codes for every login.
Tip: There is no guarantee that just because an authentication product uses FIDO2 or WebAuthn for part of its solution that it will achieve the same phishing resistance properties as the base protocol. Each solution must be evaluated as a whole.
Fallback Authentication Methods
Wait, hang on. Non-passwordless authentication methods are a passwordless anti-pattern?
Well, no. But also yes.
When rolling out passwordless authentication to your organization (more on this in Part 4 of this series), your users are only as secure as their weakest authentication method. Passwordless authentication may be quicker and easier to use, but if an attacker can phish your users’ passwords and push-phish their second factors, your organization is still susceptible to those attacks.
Recovery flows are also important. Even if you have entirely removed passwords from your environment, if a user gets locked out of their account but can recover access using an automated email recovery flow, the email recovery flow is part of the attack surface. An emailed link the user clicks on to initiate a recovery flow is less susceptible to phishing than a temporary access code they must copy and paste into the correct field. Emailed recovery links are not typically subject to the same sorts of push-phishing attacks as described above because the recovery link will create a new browser session on the user’s device, rather than authenticate an existing browser session that may have been initiated on an attacker’s device.
Despite early work on new recovery flows for passwordless authentication, it is likely that fallback authentication methods and current recovery methods will be used to some extent for the foreseeable future. When evaluating your passwordless rollout, make sure to consider not just the highest bar you can reach, but the lowest bar you’ll support as well.
Duo’s Passwordless Authentication Resources
Explore more of our Administrator's Guide to Passwordless blog series
Learn more about our passwordless authentication solution
Read our white paper, Passwordless: The Future of Authentication
Watch our webinar, How Duo is Making Passwordless Progress Easier
Watch a Threatwise TV video that discusses and demos Duo passwordless authentication
Read a Cisco blog by Product Marketing Manager Ted Kietzman explaining why passwordless is just one part of a holistic security strategy
Try Duo for Free
Want to test it out before you buy? Try Duo for free using our 30-day trial and get used to being secure from anywhere at any time.