Unlocking the Future of Account Security: Exploring WebAuthn and Biometric MFA

Maybe you've heard the horror stories about SMS two-factor authentication being insecure. Or you're frustrated with needing to dig out your phone and click through a notification every time you log into your email account. Or perhaps you're worried about losing your phone with your TOTP authenticator app and being locked out of your crypto account. If so, let's chat about an easier way to handle multi-factor authentication on your (and your company's) accounts. And if the last paragraph was jargon soup to you: don't worry; we've got you too.

MFA 101

First up, let's do a quick review of two-factor (2FA) and multi-factor authentication (MFA), along with some options and tradeoffs for enabling MFA. If this is old news, feel free to skip down to the "Fine, tell me about WebAuthn using biometrics already!" section.

Two-factor authentication ultimately means that to prove you are who you claim to be, you'll need to provide two separate elements that vouch for your identity (also known as credentials). For example, to log into your bank website, you might need your password and a security code that was texted to you. Your password (that matches the one you previously set) is the first factor, and the correct security code is the second factor. Multi-factor authentication is a more general way of describing those requirements, allowing for the possibility of requiring more than two credentials (for example, requiring email verification when logging in from a new device in addition to a password and SMS code). And to be considered real MFA, the various factors should be of differing types. Needing two separate passwords (or even requiring a password and an answer to a security question like your mother’s maiden name) isn’t MFA as they are both just things you know (as opposed to things you have or things you are).

Why use MFA?

One of the most significant threats to online security is the reuse of passwords. And that risk can spread to corporate accounts when users reuse personal passwords, as a compromised website could lead to leaked passwords for all accounts. Without asking employees to hand over a list of their passwords (don't do this!), how can you be sure they aren't reusing personal passwords (before a breach that makes those passwords public)?

Requiring MFA for corporate accounts is an effective way to mitigate the risks of password reuse. With MFA, even if a hacker obtains an employee's password, they will still need to provide another form of identification to access the account. And the beauty of MFA is that, unlike chains, MFA is at least as secure as the strongest individual factor. For example, even if you've set your password to password, requiring a security code means that breaking into your account is still at least as difficult as getting access to that security code.

The downsides of SMS security codes

We all use them, usually because they are the default option, but SMS security codes for MFA have a few major downsides:

• Getting unauthorized access to them isn't as hard as it should be. If you enabled SMS previews on your phone, local attackers could simply glance over your shoulder and be on their way to draining your bank account. And remote access to your SMS messages might be even easier: most cellular carriers are all too happy to update your address to 1525 Criminal Street and ship out a new SIM card as long as the person calling in knows your personal details. And you can probably think of at least one company that has already had a data breach and leaked your name, SSN, address, and password - it might have even been your cellular provider!
• It can be incredibly inconvenient! Maybe you have poor cell service at your vacation cabin in the mountains, or you're traveling overseas and skipped the expensive roaming plan, or a hurricane hit your area and the cellular network is overloaded. Or maybe you're at a research station in Antarctica. The point is, it's not hard to envision needing access to an account when you don't have reliable, easy access to your SMS messages.

Two factors steps forward, one step back

Another option is an "authenticator" app linked to your account that generates a security code (also known as a TOTP). Generally speaking, they are more secure than SMS security codes but not necessarily more convenient. Why?

• If it's on your phone, you still need to find your phone, unlock it, and transcribe a security code. And security that makes it harder for you to log in probably means you're less likely to bother setting it up.
• If you're ahead of the curve and use a cloud-syncing password manager to store and generate security codes, you've put both factors (the password and the security code) behind whatever protects your password manager. Hopefully, you're using MFA for the password manager, but then where are you storing the non-password factor for that?

You-bee-keys and external authenticators

Alright, now we're operating in the future! Fancy little USB security keys with lights and buttons (and sometimes even fingerprint readers) that you plug into your computer like you're a hacker in the movies just so you can check your latest eBay auction bid. Secure? Definitely (at least when it comes to remote attacks). Convenient? Anything but. You’ve got to be seriously dedicated to security to use one of these:

• The website will need to support hardware (also known as “roaming”, “external”, or “cross-platform”) authenticators in general and yours specifically, and that can vary depending on the standards that the website and hardware authenticator each support (FIDO, U2F, FIDO2, UAF, CTAP1, CTAP2… I promise the cat that I don’t have didn’t just walk across my keyboard). Are you willing to choose your bank based on hardware authenticator support rather than having a nearby branch?
• Like SMS security codes sent to your phone, you need to find your external authenticator and do something with it to log in.
• The security advantage of needing that specific external authenticator to log in is also a major usability disadvantage: either you accept that losing, for example, a tiny USB key means losing access to your account, or you need to add and manage another backup MFA method to your account.

Fine, tell me about WebAuthn using biometrics already!

Chances are at least one of your devices has some sort of hardware-based biometric authentication mechanism, usually either a fingerprint reader (e.g., Touch ID) or a camera-based face scanner (Windows Hello, Face ID). And you already use it to log into your device, open your mobile wallet, or log into your bank's mobile app. Pretty convenient, right?

Now the neat part: websites that support hardware security keys can easily (and may already) support using that same fancy biometric mechanism as a second factor when logging in! This is enabled by a neat and open standard called WebAuthn. To use a fingerprint or face reader instead of a hardware token, you'll need to be using a modern browser, and the website will need to have enabled support for "platform" authenticators (rather than or in addition to "cross-platform" authenticators like hardware keys). A couple of examples of sites that do this include GitHub and AWS. You can also test out a demo at https://webauthn.io/.

Example: Using WebAuthn with Touch ID

You'll typically need to go through the same website workflow that you would use for adding a hardware security key. During the process, the website may specifically ask you if you want to add a "Built-in authenticator" or "This Device", or it may assume that's the case and ask if you want to do something like "Create a passkey for example.com". After choosing, you'll be prompted to authenticate using the Touch ID reader, and then bam, you're good. In the future, you'll be able to log in by entering your password and then touching the fingerprint reader (or smiling for the camera) without waiting for an SMS message or digging out another device.

Wait a minute, you said Passkeys… that's a proprietary Apple/Google/Microsoft thing!

Well, yes and no. Passkeys (or, more technically FIDO2 authentication) in the form of what Google, Apple, and Microsoft are encouraging folks to adopt are really just WebAuthn under the hood, along with another open standard called CTAP2, and some cloud magic to sync those passkeys between devices. This has the advantage of only needing to add a passkey to a website or app once, and then you’ll be able to authenticate from any device supported by the third-party passkey service.

Contrary to the marketing efforts of certain large companies, the official human-speak name for any FIDO2 (WebAuthn + CTAP2) password-replacement credential is a “passkey”, even if it isn’t being managed and synced by a mega-tech company. Passkeys that are restricted to one device were previously known as “single device credentials”, and are now also referred to as “single device passkeys”. And some browsers that support WebAuthn have started referring to it as passkeys, regardless of whether the website is using it as a second factor instead of replacing passwords entirely. From here on out, we’ll use the terms “plain WebAuthn” or “vanilla WebAuthn” to differentiate SDCs that serve as an additional factor from passkeys that replace passwords entirely.

As alluded to above, one big difference between using plain WebAuthn instead of passkeys is the number of factors involved. FIDO2 passkeys are intended as a replacement for passwords and only require the passkey to log in. A passkey can be considered 2FA by itself - you are providing proof of identity in the form of a thing you have (access to the encrypted passkey) and a thing you are (your fingerprint or face biometric that is used to decrypt the passkey). By extension, an account protected by a traditional password login AND a WebAuthn authenticator is protected by three factors: a thing you know (your password), a thing you have (the encrypted key stored on the device), and a thing you are (your fingerprint or face used to decrypt the key).

Choosing between “passkeys”, single device passkeys, and plain WebAuthn

Whether you’d prefer to use a passkey stored and synced via a third party instead of a single device passkey or a plain WebAuthn credential could depend on a few different factors:

• Whether the website has added support for passkeys. Passkeys require FIDO2 support (CTAP2 in addition to WebAuthn), vs WebAuthn only
• Whether the primary account you would use for cloud syncing of Passkeys supports them - for example, Google Workspace accounts don’t support Passkeys (yet) even though personal Google accounts do.
• Your or your company’s comfort with a third-party storing your credentials in the cloud. This could be a security risk if the provider doesn’t secure the keys sufficiently, and an access risk if the provider can cut you off from retrieving your passkeys for use. Of course, this should be balanced against how realistic is that you (or your company) are more vigilant about security than a provider like Google or Apple.
• Whether you prefer the phishing protections provided by the passkey specification or if you prefer the additional MFA factor from requiring a password in addition to the WebAuthn credential.

If you’ve decided that synced passkeys aren’t the right choice, you may still be concerned about access to a site or app being tied to a specific device that has your single device passkey or WebAuthn credential. Whether because of the threat of loss, theft, or the irresistible attraction between anything with a screen and the nearest hard surface, it’s risky only to have one copy of whatever can get you into a critical account. The good news is that most services that support WebAuthn allow you to add more than one authenticator. We’d recommend that you’d add a single device passkey or WebAuthn credential from at least two devices or add a TOTP authenticator kept separate from your devices.

Go for it!

At the end of the day, either passkeys or plain WebAuthn are likely to bring substantial improvements in security and convenience when compared to your current MFA options. We encourage you to give either one a try - more adoption by users will only encourage more widespread adoption by websites! Oh, and if you are a financial institution or security provider that only supports SMS MFA (or none at all): shame on you please enable passkey or WebAuthn support!

‍