The Administrator's Guide to Passwordless

00. Introduction

It’s 2030, and passwords are a thing of the past. Okay, there are a few lingering cases we haven’t been able to eradicate yet, such as old WiFi systems and some legacy software nobody knows how to work with anymore. It’s been an interesting decade. Do you remember how we used to be afraid of biometrics because a few early implementations stored users’ personal information in a central database? Good thing we stopped doing that pretty early on. Oh, and enrolling each of our devices individually with our accounts took a little bit of getting used to.

But wow, it’s hard to think back to pre-2020 when we had to remember a mnemonic or series of semi-random words every time we wanted to do something online. And doing that for each site? Forget about it. And then even if we did our due diligence, sometimes a database would get popped and we’d have to go reset our passwords anyway! (If we were lucky enough to notice we got hacked). Anyway, things are much better now in 2030.

Now, back to reality. It’s 2021 and you’re an administrator or security engineer trying to figure out what this whole “passwordless” thing is about. Maybe trying to figure out your strategy for rolling it out in your own organization. We’ve been using passwords for decades. What does it mean to go without them now? It seems like a half step forward and a full step back. After all, we leave our fingerprints and faces sitting out in the open all the time.

It’s much harder to steal something kept secret in your brain, right? People trying to sell us something keep telling us that just getting rid of the password is more secure, but that seems risky. Even with one of those fancy security keys, that’s still just something you have. Now someone can just steal your security key and they’re in. Where is the something you know?

In this research, we’ll cover everything you need to know to determine for yourself why “passwordless” can be both more secure, and more usable than today’s leading authentication systems. But you’re also right to worry. Not every passwordless product or system meets this high bar. Some products conform to the “passwordless” moniker by removing the password and making login simple and easy, but not necessarily phishing-resistant or more secure. Some products require special software, or special hardware. Some don’t.

This isn’t a step-by-step guide to picking a product. It’s a discussion of the important aspects of passwordless authentication so that when you’re evaluating whether a solution is right for you, you know what to look for.

What the Heck Is a Passwordless?

Let’s start by breaking down what passwordless is and isn’t. Obviously, the big promise is that it gets rid of the password, and all the baggage that comes along with it: weak passwords, credential reuse, phishing etc. If you weren’t already familiar with the problems with passwords and looking to get away from them, you probably wouldn’t be here. But if not passwords, then what do we use to secure access to our accounts?

In security-critical environments, you may find client certificate-based or smart card authentication solutions, often in addition to passwords, although sometimes used as a sole factor. Both of these approaches use asymmetric keys to uniquely identify employees or their devices and make it much harder for adversaries to gain unauthorized account access.

However, these solutions typically create a large administrative burden and necessitate securely distributing keys or physical hardware devices to each employee or each managed device. Smart cards often require special software and may also only be compatible with a limited set of applications. The overhead and limitations of these solutions makes them unpalatable for many organizations.

Today’s leading passwordless model is built on the open community standards of Web Authentication (WebAuthn) and the Client To Authenticator Protocol 2 (CTAP2), collectively branded as FIDO2 under the FIDO Alliance. In contrast to older approaches, these protocols are designed to both authenticate and enroll users natively in a web browser, without the need for a managed service to distribute keys. WebAuthn defines a browser API that websites can access to invoke registration and login procedures, while CTAP2 defines a protocol that browsers can use to access authenticator devices attached to the local machine.

At its heart, FIDO2 is merely a convenient way of generating, registering, managing, and using standard public and private keys to assert identities. However, it is an open, community vetted, and widely adopted standard for achieving the following two authentication properties on every passwordless authentication:

1. The authentication verifies something you have, the cryptographic private key stored on your authenticator device, and something you know or are, either a PIN or a biometric. By verifying both of these things, WebAuthn and CTAP2 meet the multi-factor standard necessary for safe and secure passwordless authentication.

2. The authentication is strongly phishing resistant, enforcing origin and channel binding on every authentication. Origin binding ensures the WebAuthn private key will be unusable unless you are on the intended website, blocking both passive and active phishing attacks. Channel binding is a bit more subtle. It requires that the device accessing the resource and the device authenticating to the service are strongly bound. They may be the same device, or two different devices, but binding the channel between them ensures an adversary cannot make authentication requests from an anonymous device. This prevents active man-in-the-middle or push-phish attacks and avoids relying on the user to make a determination of whether a given authentication attempt is valid or not. WebAuthn has origin binding baked in, and inherits channel binding for authenticators built into or attached to the access device, such as Touch ID and security keys. For other passwordless solutions, especially those that delegate authentication to another device like a mobile phone, care must be taken to ensure proper channel binding.

WebAuthn and CTAP2 are the current state of the art, and any passwordless solution that diverges from the straightforward and intended use of these protocols should have clear technical documentation on how it maintains these same security properties.

Context of Passwordless Authentication Solutions

When evaluating an authentication solution, the authentication framework itself may be the starting point, but it certainly isn’t the only thing to consider. While this series focuses specifically on concerns around passwordless authentication, it’s also important to consider how well your authentication stack supports your applications, interfaces with policy enforcement, manages device health and trust, adapts to dynamic user behaviors, and interfaces with other compatible frameworks through standard protocols.

Passwordless has the potential to greatly simplify the user-facing aspects of the authentication stack and raise the baseline of user security across your organization, but it’s just one part of a balanced breakfast robust authentication stack.

01. Part 1: Passwordless is Not Multi-Factorless

If you go by just the name, “Passwordless” could refer to any login experience that doesn’t require a password. An absurd example would be one that simply logs you in using a username, and nothing else. In considering a passwordless solution, we want to raise the security bar, not lower it. Part of ensuring that passwordless is just as secure as multi-factor is ensuring that it is multi-factor.

In the WebAuthn protocol, there are three primary actors:

• The website, also known as the Relying Party or RP
• The browser, also known as the Client
• The Authenticator, of which some popular varieties include Windows Hello, Touch ID, and security keys like the Yubikey.

An authenticator is a device that can generate and securely hold a cryptographic key that serves to identify an end-user. During account registration, the authenticator generates a credential and passes the corresponding public key to the website for association with the user account. Later, during login, the authenticator uses the private key associated with that credential to sign a message known as an assertion, and passes it to the website. The website uses the credential public key, from the registration step, to verify the signature on the assertion. This verification proves control over the credential, which, if properly protected, strongly identifies the authenticator device (and, by extension, the user).

But how do we know that it’s really our user that holds the credential and not an imposter? For instance, someone who stole the authenticator device. For that, WebAuthn and CTAP2 support a User Verification (UV) flag, wherein the authenticator device must first locally verify the identity of the user before it can unlock the credential to sign messages. This often takes the form of a biometric check, such as a fingerprint or face scan. Alternatively, users can unlock the credential using a local PIN. Notably, the biometric or PIN never gets sent to a server or otherwise leaves the device.

Since User Verification generally can only be performed locally, attacks against this user verification process become very labor-intensive and must be targeted at specific users, greatly increasing the difficulty of attacks.

In the WebAuthn protocol, the two factors are:

1. Possession of a private key, ideally stored on a piece of secure hardware
2. A biometric or PIN the authenticator uses to locally verify the user’s identity

The specific bits of the messages that state that the authenticator performed User Verification aren’t important for this conversation. What is important is that the website can trust that the user was locally verified before authenticating them. Due to the UV flag being signed over in the message, it is straightforward for the website to trust that the authenticator says that user verification was performed. What’s harder is to ensure that the authenticator isn’t capable of lying about having performed user authentication.

The WebAuthn protocol is community-developed and publicly shared, which means that anyone can implement a CTAP2-compliant authenticator in software at any time, with relatively little effort. There is no inherent requirement in the WebAuthn protocol that authenticators must identify themselves.

In fact the WebAuthn protocol goes to great lengths to ensure that websites cannot use authenticators to de-anonymize users on the Internet, unless they are specifically attempting to identify themselves by logging in. However, what the WebAuthn protocol does provide is a mechanism by which websites can refuse to allow an authenticator to be used unless it strongly identifies itself. Note that we’re not talking about the user’s identity, but the authenticator device’s identity.

The process of determining the provenance of the authenticator is called attestation and it occurs at the same time as user registration. The same way that modern websites may need a certificate issued by a certificate authority in order for browsers to trust them, so too does the authenticator need a certificate issued by a certificate authority for the website to trust it. The certificate authority for authenticators is often simply the manufacturer or vendor that produces the authenticator.

The attestation process works as follows:

1. When the authenticator is manufactured or produced, the manufacturer issues it a certificate signed by the manufacturer’s certificate authority. The manufacturer’s certificate authority public key is published so it can be used by the website later to verify the legitimacy of the authenticator’s certificate.
2. When the authenticator generates a new credential for the user during registration, it signs the registration message it sends to the website using its certificate. The registration message is called an attestation object and the signature and public part of the certificate is known as the attestation statement.
3. During registration, the website receives the attestation object and examines the attestation statement in it. It verifies that the registration message is signed using the private key associated with the certificate the authenticator presented. It then also verifies that the certificate the authenticator presented is properly signed by the manufacturer’s certificate authority.
4. If the certificates are all signed properly and the verification procedure succeeds, then the website can be assured that the authenticator must have been issued by the manufacturer that published the certificate authority in Step 1. If the website trusts that manufacturer, then it can trust the authenticator to behave according to its manufactured specifications, which may include only setting the UV flag to true if a particular user verification procedure is performed. The details of which manufacturers or even which device models a given website trusts are left up to that website to determine for itself.

This attestation process gives websites a powerful tool to ensure only approved authenticator devices can be used to identify users, but is attestation necessary to realize the security benefits of passwordless?

The answer is mixed. In high-consequence environments, requiring attestation may be prudent. Ensuring that only authenticators with hardware-backed secure storage or a specific local user verification method can be used could be a necessary precaution to address known threats or conform to regulations. But in many cases, the website operator may not need to have such stringent oversight.

Each user gets to decide which authenticator(s) they use to register a credential to their user account. And with strong authenticators like Touch ID and Windows Hello now regularly present on the same device from which users are accessing their accounts, it may be entirely acceptable not to require attestation and simply trust users to safely store their own credentials. That’s what we do, for the most part, with passwords today. But with WebAuthn credentials, even the most simplistic authenticator, without any secure key storage properties, still needs to be attacked on a local, per-user basis.

02. Part 2: Passwords Are Safer Than Biometrics, PINs Are Just Passwords, and Other Tall Tales

Tall Tale #1: PINs Are Just Passwords

In Part 1, we talked about how passwordless authentication is still multi-factor:

1. Possession of a private key, ideally stored on a piece of secure hardware
2. A biometric or PIN the authenticator uses to locally verify the user’s identity

Reasoning about a PIN being used as a factor is simpler than a biometric. A PIN is simply a password, with a few key differences. The most critical difference is the context in which it is used for authentication in WebAuthn. Unlike a password, which is transmitted to the website and checked against the website’s record (hopefully, a salted hash, and not a copy of the password itself), a PIN is used only to unlock the credential stored on the local authenticator device. There is no central repository of user PINs for an attacker to breach and steal, no remote access to the authenticator for an attacker to brute-force over the network. The only way to unlock the credential is for the user to locally, often physically, interact with the authenticator device and enter the PIN.

By way of analogy, let’s consider the teleporting burglar problem. Why a teleporting burglar? Because remote attacks on the internet are similar in nature — an attacker can instantly “travel” to any “door” in order to attempt a theft. To reduce the risk of a burglar who can teleport, we can (a) make our keys harder to forge and our locks harder to pick, or (b) stop the burglar from being able to teleport.

Burglars who have to walk from house to house are much less of a threat. By enforcing local authentication via PIN, we effectively force remote attackers to “walk” to each account they want to hack. Even weak local authentication stops most remote attacks cold. Switching to local evaluation of a user’s identity eliminates several entire categories of attacks that impact organizations and individuals today.

Because a user must be able to locally access the authenticator to enter the PIN, and authenticators often lock after a small number of incorrect attempts, the complexity requirements we associate with “good” passwords may not be necessary. Using numbers, symbols, capital and lowercase letters, with a minimum character count, all aim to deter attackers who can brute-force guess trillions of passwords per second. When an attacker gets 10 guesses total and has to enter them all by hand, a random six-digit numerical PIN (search space of one million) becomes sufficient to block bad actors, and is substantially more practical to enter on some devices than a complex password.

Nevertheless, it can be hard to shake off a vague sense of uneasiness around using such a weak “password” as an authentication factor. Is this because we’re worried about remote attacks? Hopefully not. But what about local attacks? Shoulder surfing? Someone recording us unlocking our devices? Fingerprints on the glass that reveal which digits were pressed? Hollywood and its abundance of spy movies give us some great ideas for how a local PIN might be attacked. So if local attacks are part of your threat model, let’s consider biometrics.

Tall Tale #2: Passwords Are Safer Than Biometrics

Biometrics get a bad rap. They’re basically magic. And by magic, we mean difficult to reason about. There are many different kinds of biometric sensors, and even two sensors that measure the same biometric feature, such as a fingerprint, may do so in completely different ways, and be subject to completely different attacks.

At the lower end of the spectrum, biometric sensors like optical fingerprint sensors and single-lens cameras for facial recognition can be spoofed with photos printed by a $50 inkjet printer. On the higher end of the spectrum, facial recognition sensors like Apple’s Face ID and Google’s Face Unlock use multiple cameras and near-infrared dot emitters to capture a 3D facial map. Combined with 2D color imagery, and sometimes liveness detection, the bar is raised quite high. While headlines like to broadcast doom and gloom for biometrics, such as the 2019 BlackHat USA demonstration against Face ID, the truth is these biometrics are really quite secure.

"The attack comes with obvious drawbacks — the victim must be unconscious, for one, and can’t wake up when the glasses are placed on their face." —Lindsey O'Donnell, ThreatPost

In 2020, Talos did an investigation of fingerprint sensors and their practical spoofability on a reasonable budget. Despite achieving great success rates spoofing most of the devices they tested, they ultimately felt it was a difficult process.

When evaluating the security of biometrics in the context of passwordless authentication, the bar we have to beat is to be stronger than a local (often 6-digit) PIN. A biometric, measured and analyzed locally, inherits the same game-changing properties as the PIN does. It unlocks the unguessable, private credential stored on the authenticator device itself, and avoids sharing a cloneable secret with the web server — so even if it becomes compromised someday, it cannot compromise credentials used on other sites. The biometric can only be attacked locally in analog space, eliminating much of the risk of remote attacks entirely (more on the topic of remote attack mitigation in Part 3).

"We defined the threat models starting from the collection methods. The creation process is time-consuming and complex. We had to create more than 50 molds and test it manually. It took months. Once we created an accurate mold, the fake fingerprint creation was easy. Today, by using our methodology and our budget it is not possible to create a fingerprint copy on-demand and quickly." —Paul Rascagneres, Security Researcher, Talos Security and Vitor Ventura, Technical Lead/Security Researcher, Talos Security

Tall Tale #3: Biometrics Are Secrets

Another point that bears mentioning: Biometrics are also used in an entirely different context than we discuss here. That is, while biometrics can be used for authentication, they can also be used for surveillance. Luckily, there’s a fairly easy way to differentiate between these: whether your biometric information is stored in a centralized database with biometric information of many other people, or kept local to the one device that you used to generate your credential. For instance, biometrics used at border crossings, despite being used to identify users, are checked against a central database rather than a device you carry locally with you, and so fall under the surveillance category.

This distinction is significant for several reasons, both technical and non-technical. Surveillance itself is a thorny topic with both legitimate and illegitimate uses, and the ethical boundaries of surveillance and privacy are an area of significant public debate. This clouds the discussion around the use of biometrics for authentication, which is highly privacy-preserving.

Additionally, the use of central databases risks large-scale biometric leaks, as occurred in the CBP biometric leak (2019), Biostar Leak (2019), OPM Hack (2015), SenseNet (2019), and was feared during ClearView AI’s account breach (2020). Biometric data is often considered sensitive or personal information under laws and regulations such as HIPAA, CPRA, and BIPA, with harsh penalties for data leakage, creating even further risk for storing it centrally.

However, the single most significant distinction between authentication and surveillance is that surveillance relies upon a remote representation of a user’s biometric. To fool a remote biometric check, I must simply submit a digital equivalent to the remote verification engine. A digital representation of a biometric is trivial to replicate and distribute, and is therefore an incredibly weak proof of identity. The original, physical, biometric is very difficult to replicate with sufficient fidelity to pass as the original. By verifying a biometric locally, you gain a high level of assurance in the user’s identity. By verifying a biometric remotely, you verify that the user is in possession of a shared secret that is the user’s digital biometric.

Biometrics may be sensitive and personally identifiable, but they aren’t secrets. Evaluating a biometric digitally, remotely, turns the biometric into a password that can never be changed and that you wear around on your face all day. In short, remote biometric matching should be considered distinct, separate, and vastly inferior to local biometric authentication.

Today, there are really good, easy to use, biometric-based authenticators that achieve the right security properties — and best of all, you may already have many of these in your environment:

• Windows Hello
• Apple Face ID and Touch ID
• Google Face and Fingerprint Unlock
• Yubico Yubikey 5 Bio (coming soon)

This isn’t meant to be an all-inclusive list, or to advertise or advocate for any particular product or vendor. Instead, it’s meant to illustrate that your users probably already have a FIDO2-capable and secure authenticator in their pocket, and even if they don’t have one today, your organization’s equipment refresh cycle may supply your users with one or even multiple secure authenticators, simply as a side effect.

03. Part 3: What Makes Passwordless, Dare We Say It, Phish-Proof?

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 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 our research), 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.

04. Part 4: Phases of a Passwordless Rollout

If you’re considering passwordless authentication for your organization today, you’ve probably been thinking for a while about a holistic authentication strategy. Passwordless is a leap forward on the path to a strong and usable authentication system, consisting of many individual steps that you must navigate.

Let’s start by reviewing the high-level phases of the passwordless journey:

Phase 1: Establish Multi-Factor and Identify Passwordless Use Cases

Multi-factor authentication has been a critical component of strong authentication systems for more than a decade. Hopefully, you’ve already got this one — but if not, there are countless products that can help you mitigate the threats of password-based single-factor authentication.

Phase 2: Consolidate Authentication Workflows

A typical company runs hundreds of applications. Managing each application’s authentication methods and security policies quickly becomes untenable for administrators at this scale. Rather than attempt to augment the security of each application individually, Phase 2 focuses on consolidating authentication workflows into a place where the majority of the authentication events can be centrally managed.

This may take the form of single sign-on (SSO) or federated portals through standard protocols like Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). Even applications that aren’t web-based, such as SSH clients or remote desktop software, may be able to go passwordless by using a reverse proxy and client software that opens a passwordless web prompt. There are numerous products and services that will offer different experiences and features, and both the features you need and the protocols your applications support may dictate which products and services are suitable for your organization.

Phase 3: Increase Trust in Authentication

Next, focus on building a more comprehensive user authentication system and mitigating additional threats in your environment. Ensure user authentication is occurring from known and trusted devices with up-to-date software and operating systems. Detect anomalous user behavior and flag it for remediation. Identify safe conditions and risky behaviors and configure flexible policies that can reduce user friction without reducing security. Support for all of these things builds upon your work in Phase 2 and the selection of a vendor that supports the features you need.

Phase 4: Adopt Passwordless (We are here!)

Passwordless requires support from both your users’ access devices and your SSO portal or federation system. Microsoft, Apple, Google, and other system manufacturers have done an excellent job in rolling out access device support for passwordless, and security key manufacturers like Yubico, Feitian, and SoloKeys can help enable support for passwordless on devices that don’t support it natively. SSO and federation providers are beginning to bring passwordless solutions online. If you’ve done the hard work in Phase 2 to consolidate your authentication workflows into a centralized authentication experience, you may be able to enable passwordless across the majority of your organization by simply switching it on. Your existing authentication and authorization policies, device trust, and configured settings should ideally transfer over and take effect right away.

Phase 5: Optimize Passwordless

Unless you’ve managed to consolidate every one of your applications into using the same federation solution, it’s likely you won’t be able to completely eliminate the use of passwords overnight. This is where having a layered security model with MFA, configurable policy, device trust, and adaptive authentication pays dividends. Your organization is only as safe as your weakest authentication method, so ensuring every authentication method is strong reduces your risk as you transition towards Pure Passwordless. The goal here is to aggressively continue consolidating authentication workflows into centralized auth solutions where passwordless support exists and begin the process of disabling password-based authentication.

This will be a protracted phase, as disabling passwords will highlight all sorts of corner cases where passwords may be used in your organization, such as new user onboarding, account recovery, and that one server in the basement that you don’t want to touch in case something goes terribly, terribly wrong. Certain applications and protocols will most likely not be able to adopt passwordless initially, so some of your users may need to keep a password around to use with these systems for a while.

Passwordless is exciting and promises both security and usability benefits. We mostly get the usability benefits in Phase 4 and the security benefits in Phase 5, but like anything, there’s a spectrum. So long as passwords remain an option, adversaries can apply the same attacks they use today to password-based auth methods. Adding passwordless auth as an option starts by making authentication easier. Removing passwords as an option makes authentication safer.

For frequent use, adding additional factors behind a password may have been deemed too much friction, but it may be more acceptable as an infrequent fallback when passwordless is the primary authentication method. Security benefits can also come simply from user habit migration. For example, users who become conditioned to passwordless authentication will find an unexpected push or a password entry field conspicuous, even if they’re still allowed as options. This is one of the few exciting breakthroughs in authentication technology where a more usable option is more secure as well!

However, it would be remiss to say everything will be roses. Let’s dig in to Phases 4 and 5 and discuss some of the challenges you are likely to face as part of passwordless adoption and how to manage them.

Your First Few Weeks of Passwordless

When you flip the switch and enable your first passwordless login, it’s probably going to feel unfamiliar. If you’ve read this guide and have a general understanding of how authenticator devices store and use credentials, you’ll probably be able to infer how things operate. Your users, on the other hand, may have no idea what they’re supposed to do. Passwordless login is supposed to be quicker and easier than using a password, but most people have years or even decades of experience using passwords. We know what to do when we see a password input form.

Your users will be old hats at passwordless in no time, but the first time seeing an unfamiliar prompt to scan a fingerprint or face can be unsettling. If a user thinks they’re entering their system password into a web form, being prompted to enter a PIN or local system password can be confusing or even suspicious. You’ll most likely want to evaluate the passwordless login flow yourself and work out a strategy for assisting your users through their first passwordless logins.

But before we even get to passwordless login, your users will need to enroll a credential or add an authenticator device to their account or profile. This can be just as confusing as a first login, if not more so. However, depending on your MFA configuration, your second-factor authentication method may be suitable, or nearly-suitable, for passwordless auth already.

If your users have adopted a WebAuthn-capable 2FA method such as Windows Hello, Touch ID, Face ID, Fingerprint/Face Unlock, or a FIDO2-certified security key and regularly use it as a second factor, your authentication provider may be able to use the same credentials for passwordless authentication if they support user verification. If not, then the simplest way to enroll a new passwordless device is to piggyback on top of a normal password-based auth and ask your users to enroll a device as part of their normal login process. This will probably feel pretty similar to how your users first enrolled their MFA devices after entering a password the first time. On next login, they’ll be able to use passwordless!

Now, imagine you’re a few weeks into your passwordless rollout and one of your users loses their first device. Even though their credential on the device should still be protected by a user verifying PIN or biometric step, we want to invalidate that credential as soon as possible because it’s now lost the something you have property. Your authentication provider should offer a control panel or other administrative console where you can view your users and see what devices they have enrolled. You should have a quick and easy way to invalidate the lost device and credentials through this interface. (In case you’re curious, each device is supposed to only have one credential per user account.) If you haven’t disabled passwords yet, your user should be able to use their password to enroll a replacement authenticator device the next time they try to log in.

Removing Passwords: Applications vs. Users

Throughout Phase 4, passwords remain a viable fallback option. Although these challenges in Phase 4 are likely to require lots of time, they’re more about helping your users acclimate to a new process than technical complications per se. You may wish to progressively roll out passwordless to smaller groups within your organization at first, to smooth the influx of help tickets and allow early adopters to share knowledge of passwordless with their peers.

Things get trickier as we move toward Phase 5 and start to remove passwords as an option. Any user who hasn’t acclimated to passwordless login will be stuck if they no longer have a password-based fallback. The goal of Phase 5 is to remove passwords from the environment to improve security, while minimizing new complications. Let’s explore a few complications that may come up as we remove passwords.

To start, not every application will be able to use passwordless. Take connecting to a wireless network for example. Unless you’ve rolled out client certificates to your fleet, the main WPA2 Personal and Enterprise authentication protocols expect either a pre-shared key, or a username and password. Not every protocol is web-based or can be proxied through a web-based gateway. Applications released years ago may never get updates that support SAML, OIDC, or other federation protocols. It’s likely that one or more additional applications or use cases in your environment may not be passwordless-capable, now or in the future. That’s okay. Each application from which you can remove passwords gains the security benefits.

Every user from which you can remove passwords is one fewer user who can be phished or introduce credential reuse into your organization. However, it’s much harder to completely remove passwords from users than to completely remove them from applications. If a user no longer has passwords, then they can’t fall back to a password if they lose their authenticator device. It becomes important that each user have two or more authenticator devices enrolled, so that they do not get locked out of their account. Once passwords are eliminated, your users will probably need to use passwordless authentication to enroll new devices.

Authenticator Management Considerations

Platform authenticators like Touch ID and Windows Hello are conveniently present on the access device but are also limited to being used on the specific platform they’re a part of. Let’s say you need to enroll a new device with a platform authenticator but no longer have a password. How do you bootstrap trust in your new device to get to where you can enroll its platform authenticator?

Roaming authenticators like security keys or mobile authenticators have the advantage that they can be used to authenticate across multiple machines. You can use a platform authenticator to enroll a roaming authenticator on one computer, then move the roaming authenticator to another computer and use it to enroll that computer’s platform authenticator.

It’s clear that the passwordless future involves lots of devices and a mix of both platform and roaming authenticators. However, increasing the number of authenticators introduces even further complications, as each authenticator must generate its own per-site credentials. Enrolling multiple devices with each of multiple websites will likely grow tiresome. You can partially alleviate this via federated login, centralizing login to a handful of sites or fewer. On the plus side, enrolling multiple devices gives your users the ability to self-remediate individual lost or stolen devices without losing access to their account.

Inevitably, some users will find themselves with one or more lost authenticator devices and no way into their account. You will need a recovery flow. There are many different recovery flows, including temporary passwords, recovery links, backup codes, and more. Your recovery flow may delegate the authentication decision to another provider, such as an email host, wherein if your user still has access to their email account, they may be able to self-remediate. If not, they may need to contact your help desk for an override. Recovery flows are also a potentially-viable option for bootstrapping trust across platform authenticators without a roaming authenticator to assist.

While it’s critical to have one or more recovery flows, know that the recovery flows you support, especially any self-remediation flows, are viable attack vectors. It doesn’t meaningfully improve your security posture to remove password-based authentication if your recovery flow isn’t ultimately stronger.

Your organization may likely reach Phase 4 quickly but spend years optimizing passwordless in Phase 5, which is to be expected. Over time, the passwordless space will expand to support additional applications and use cases, and someday, we hope, passwords will be a relic of the past.

If you’d like to see how Duo can help bring passwordless to your organization, visit the product page for our passwordless authentication solution.

05. Further Reading

• 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.