The reports of my death are greatly exaggerated. (Mark Twain)

As it turns out, Mark Twain didn’t actually say those exact words but that’s what people remember. Stories are like that. Good stories tend to expand until they fill the human imagination.

Passwords are like that too. The word "password" conjures all sorts of stories that recount frustrating experiences logging into computer systems or applications. Tales about compromised password files on servers are especially popular. The worst stories portray the bad guys relentlessly phishing for our precious passwords. Despite its many shortcomings, however, the password has been the dominant authentication technology for over 50 years.

Like Twain, the death of passwords has been greatly exaggerated. That said, there’s a disturbance on the event horizon, and with a little luck, it may just turn out to be that perfect storm we’ve been waiting for.


The following series of articles employ the semi-structured evaluation framework of [Bonneau et al. 2012] to justify some of the claims made in this blog article:

  1. The Quest to Replace Passwords
  2. Two-Factor Authentication
  3. Passwordless Web Authentication

[Bonneau et al. 2012] Bonneau, Joseph; Herley, Cormac; Oorschot, Paul C. van; Stajano, Frank (2012). “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes.” University of Cambridge Computer Laboratory, Technical Report Number 817. Cambridge, UK. ISSN 1476-2986.


No shared secrets on the server

Technically, password authentication involves a shared memorized secret whereas passwordless authentication does not. In particular, passwordless web authentication requires a PIN—a memorized secret that is not shared with the website. The PIN helps protect a user-controlled security key from being lost or stolen.

Although memorized secrets are not going away any time soon, the use of a shared memorized secret (as in traditional password authentication) is definitely on the way out. Most people will agree that the sooner this happens, the better. It will take awhile to get there, but if you squint, you’ll see a faint ray of hope at the end of the tunnel.

The changing face of web login

The overall usability of passwordless web authentication is competitive with that of passwords even if we assume that users share the same password across websites (which is often the case). The type of authenticator can influence the outcome. For example, the use of biometrics for user verification can improve the usability of passwordless web authentication. On the other hand, a passwordless recovery mechanism that makes it easy to recover from loss remains an essential missing ingredient.

From a user interface perspective, passwordless technology promises to transform today’s typical web login page:

Not only will the dreaded password field disappear (Login Form #2) but in time the username field will be unnecessary as well (Login Form #3). The technology already supports this radical approach to web login, now all we have to do is figure out how to deploy it in an environment that is heavily dependent on passwords and usernames.

A nontechnical introduction to WebAuthn

The W3C Web Authentication (WebAuthn) standard is the centerpiece of the FIDO2 Project. WebAuthn involves a website, a web browser, and an authenticator:

  • The website is a conforming WebAuthn relying party
  • The browser is a conforming WebAuthn client
  • The authenticator is a conforming WebAuthn authenticator (also called a FIDO2 authenticator)

WebAuthn specifies how a claimant demonstrates possession and control of a WebAuthn authenticator to a verifier called the WebAuthn relying party. The authentication process is mediated by an entity called the WebAuthn client, which is little more than a conforming web browser.


For the purposes of illustration, we assume the authenticator is a roaming authenticator (see below for other options). In any case, the WebAuthn authenticator is a multi-factor cryptographic authenticator that uses public-key cryptography to sign an authentication assertion targeted at the WebAuthn relying party. Assuming the authenticator uses a PIN for user verification, the authenticator itself is something you have while the PIN is something you know.

To initiate the WebAuthn authentication flow, the WebAuthn relying party indicates its intentions to the WebAuthn client (i.e., the browser) via JavaScript. The client communicates with the authenticator using a JavaScript API implemented in the client browser.

WebAuthn does not strictly require a roaming hardware-based authenticator. Alternatively, a software-based authenticator (implemented on a smartphone, e.g.) or a platform authenticator (i.e., an authenticator implemented directly on the WebAuthn client device) may be used.

The illustrated flow relies on PIN-based user verification, which, in terms of usability, is competitive with ordinary password authentication. In practice, the use of biometrics for user verification can improve the usability of WebAuthn but there appears to be a lingering misunderstanding among users that biometric data is transmitted over the network in the same manner as passwords, which is not the case. The user must trust the client platform to do the Right Thing.

WebAuthn has all the advantages of the FIDO Universal 2nd Factor (U2F) legacy authentication protocol but WebAuthn does not require a traditional password. Since no shared secret is transmitted over the network, WebAuthn is sometimes called Passwordless Web Authentication, which is somewhat misleading (due to the PIN). From the developer’s or deployer’s point of view, however, WebAuthn is passwordless since no shared secrets are stored on the server.


When the WebAuthn relying party receives the signed authentication assertion from the browser, the digital signature on the assertion is verified using a trusted public key for the claimant. This begs the question: How does the relying party obtain a trusted public key for the user in the first place?

To obtain a public key for the user, the WebAuthn relying party initiates a WebAuthn registration flow that is very similar to the authentication flow illustrated above. The primary difference is that the authenticator now signs an attestation statement with its attestation private key, which is shared by all authenticators of that particular make and model. The signed attestation statement contains a copy of the public key that the WebAuthn relying party ultimately uses to verify a signed authentication assertion. In addition, the attestation statement also contains metadata describing the authenticator itself.

The digital signature on the attestation statement is verified with the trusted attestation public key for that particular model of authenticator. How the WebAuthn relying party obtains its store of trusted attestation public keys is unspecified. One option is to use the FIDO metadata service.

The attestation type requested in the JavaScript determines the trust model. For instance, a type of attestation called self-attestation may be requested, for which the trust model is essentially trust on first use.

The scourge of phishing

Overall WebAuthn earns a B+ for usability, a C+ for deployability, and a solid A for security and privacy. Those ratings put WebAuthn in the running as a possible password replacement. At this point in time, WebAuthn has no viable alternative, with its closest competitor being Mobile Push.

In terms of security, WebAuthn provides a unique benefit, that is, it is resilient to verifier impersonation, a scenario discussed in the NIST Digital Identity Guidelines. An authentication scheme is awarded this benefit if it is resistant to an active network attack. Not even Mobile Push has this increasingly important security benefit.

Some authors conflate verifier impersonation with phishing. We prefer to associate the latter term with a passive network attack. In that way, schemes such as OATH OTP remain resilient to phishing but not verifier impersonation. Note that active network attacks have become feasible only recently (as demonstrated by Evilginx) but this threat can only get worse.

WebAuthn resists verifier impersonation by tracking the web origin of the WebAuthn relying party. With the help of the WebAuthn client, a WebAuthn authenticator associates a newly registered key pair with the origin of the WebAuthn relying party (i.e., the verifier). From then on, the authenticator enforces a same-origin policy on the use of that key pair.

If we build it, will they come?

Will passwordless web authentication eventually replace passwords? Let’s take stock. WebAuthn has the following advantages in its favor:

  • From a technical perspective, WebAuthn is the best option on the table at this time
  • WebAuthn attains high marks in both security and usability, a feat few password alternatives have been able to achieve
  • All major browser vendors (except perhaps Apple) enthusiastically support WebAuthn

The latter point is especially important: the browser vendors have rallied around WebAuthn like no web technology before it. It seems the browser wars are finally over, at least on the face of it.

Things are not all peaches and cream, however. If you’re involved with software development, middleware deployment, or user support, you’ll appreciate the difficulty of managing passwords across the enterprise. You know that the use of password technology represents a significant cost but it's also true that the cost of password alternatives is quite often even greater. This (along with lingering usability issues) has prevented other authentication technologies from taking hold. Even multi-factor authentication, widely recognized to be superior to password alone, has been slow to take off. I think it’s safe to say that multi-factor authentication will never go mainstream as long as it’s based on traditional passwords.

WebAuthn has at least the following issues working against it:

  • WebAuthn has a high cost of deployment
  • The WebAuthn protocol is complicated, with numerous moving parts
  • Despite a widespread dislike for passwords, many users have 1) a healthy distrust of biometrics, while other users will 2) resist an extra carry
  • A WebAuthn authenticator is inherently not easily recovered from loss
  • All major platforms must support at least one WebAuthn-compatible browser

The latter is a potential showstopper. No amount of effort or creativity will work around a platform that lacks a suitable browser. A particularly important barometer of success is Apple iOS. If the WebAuthn implementation currently underway in Apple Safari goes to production, I think WebAuthn will have a decent chance of success.

For the sake of discussion, let’s assume every platform supports a WebAuthn-compatible browser. In addition to a browser, every device needs a platform authenticator. This is especially true of smartphones. As of today, the Android and Windows platforms are in pretty good shape whereas Mac OS and iOS are less so.

If a particular platform has no built-in authenticator, there’s still hope. For example, a laptop running Mac OS has no platform authenticator but a roaming authenticator with a nano USB interface neatly avoids an extra carry.

Even if all platforms have a built-in authenticator, we’re still not done since every user needs a master backup key (or some other way to recover from loss). There are many products that meet this need but all of them are portable. However, portability is an undesirable quality in a backup key, and so this remains an open issue.

All in all, things are looking pretty good on the client side but the server side is still lagging. In fact, very few WebAuthn relying parties exist at this time. Notable exceptions include Google, Microsoft, Dropbox, and

Passwordless web authentication—like any new tech—has its own cost of deployment. Whether or not this hurdle can be overcome is an open question.