How Does WebAuthn Work?

In my previous post, I discussed why passwords are problematic at best and a severe security threat at worst. However, you probably currently have a password-based authentication solution.  Hopefully, you have implemented some Multi-factor Authentication. You might even have implemented Brute Force Password Protection and Breached Password Detection.  But in the end, you realize that passwords are still a problem.   Of course, after reading all that, you probably thought, “But what else is there?”

Thankfully, some very smart people have been working on this problem.  They formed an organization, worked on the problem, and came up with a delightfully effective solution.

The FIDO Alliance

In July of 2012, The Fast Identity Online Alliance – FIDO – was formed by PayPal, Lenovo, and other organizations interested in getting rid of the password.  Soon enough, Google, Microsoft, and Apple got on board, along with many other companies.  

FIDO soon developed open and free specifications for doing passwordless authentication.  The key specification is the WebAuthn standard approved by the World Wide Web Consortium (W3C).  WebAuthn uses public key cryptography to allow browsers and web resources to authenticate using passwordless methods such as biometrics.

This solution is formally called “Multi-device FIDO Credentials,” but informally, they are called “Passkeys.”  Passkeys are based on a FIDO-developed protocol called WebAuthn.

How WebAuthn Works

WebAuthn is quite clever.  It leverages the power of public key cryptography to create a way for users to log in to mobile and web applications without those applications having to store any secret information at all.

Usually, when one thinks of public key cryptography, one thinks of using it to send a secret message to a person who then decrypts it and reads it.  Well, this can kind of work in reverse.  If you send them a message encrypted with their public key, then they – and only they – are the only ones who can decrypt because only they have the private key that corresponds to the given public key.  Once they do, you can be highly confident that they are the entity that they say they are.

Currently, all the major browsers – Chrome, Firefox, Edge, and Safari – all support the WebAuthn specification.  If your phone – iPhone or Android – has a fingerprint reader or facial scanner, it supports WebAuthn. Windows provides WebAuthn support via Windows Hello.

All of this translates to passwordless authentication quite nicely.  WebAuthn typically goes like this:

1. You want to log in to a website, so you go to it.
2. The website asks for your unique identifier, usually your email address or phone number.  They may also ask for a username.
3. The website gets the information and realizes that it has never heard of you before.
4. The website says, “Hey, send me a public key that is unique to me.”
5. You validate yourself on your device. This can be via biometrics, a PIN, or inserting something like your Yubikey.
6. Once validated, your device generates a unique public/private key associated only with that website.
7. You send the site your public key. The site stores that for later use. You save the private key on your device. Note that no secret information at all leaves your device.
8. At this point, the site doesn’t know who you actually are, so it may want to verify who you actually are, usually by sending a magic link to your email or phone number.  Note that the application doesn’t have to do this because it’s not required via the protocol, but it will likely want to so it can communicate with you.
9. You click on the link in the message, and the website knows that you actually are the person on the other side of that identifier. Now you are verified by the site.
10. The next time you want to log in, you go to the site and give your identifier (email, phone number..).
11. The site sends you a known chunk of data as a challenge.
12. Your device then signs this challenge with your private key and sends it back.
13. The site decrypts the data with your public key.  You are authenticated if what you sent back matches what the site sent.

Now that’s a lot of steps and looks pretty complicated, but most of it happens behind the scenes and is done by the implementation of WebAuthn.

But more importantly, it’s really simple for your users.  All they have to supply is a press on a fingerprint reader or a FaceID impression or some other “thing that you are.”  The code does the rest. It works great, is very secure, and happens quickly and easily. No fumbling around with passwords, no bringing up authenticator applications, no checking your email or texts, and no worries about compromise.

How Do Passkeys Fit In?

At its heart, a passkey is really just the private key that gets created for every place a user logs in.  That passkey is securely stored on your phone within a “Trusted Platform Module” or TPM.  A TPM is a special chip now included with most modern devices and computers.  For example, it’s required to be present in order for Windows 11 to be installed.  The TPM is excessively difficult to compromise, even if a nefarious actor gets possession of your phone.

The nice part about passkeys is that they can be shared amongst different devices, both within and (eventually) between ecosystems.  Google, Microsoft, and Apple have figured out a way to securely save those passkeys within their ecosystems so you can even share them between devices.  There is even a way to move from one platform to another.

For instance, if you are a totally-committed Apple person, you can log in to a site one time on your iPhone with a passkey, and then that passkey is automatically shared between all of your Apple devices.

If you are a “mixed” person and have a MacBook and an Android phone, you can transfer your login from your MacBook to your Android phone via a QR Code.  The process is quite secure, and it uses Bluetooth LE to ensure that the device displaying the QR Code and the device reading the QR Code is in close proximity to each other.

In addition, your Android phone creates a new passkey during the process that is then shareable across the Google ecosystem.  You can migrate your login to a Windows device using the same system.

The bonus here is that if you lose or upgrade your phone, all your passkeys are immediately available on your new device without any hassle.

So that is how it all works.  But as before, this raises questions. “Is this more secure?” is probably one that comes up.  And that will be covered in my next post.