On 20 November 2018, Microsoft announced that its 800 million Microsoft account holders could now log in to services like Outlook, Office, Skype and Xbox Live without using a password.
The announcement is part of an apparent acceleration in the march towards a passwordless web, and comes at the end of a year when Mozilla Firefox, Google Chrome and Microsoft Edge all rolled out support for WebAuthn, one of the keystone technologies.
Passwordless authentication means ditching usernames and passwords in favour of biometrics, like fingerprints and face recognition, or other forms of authentication compatible with the FIDO2 specification, such as YubiKeys or Titans.
In security terms, it’s great news, but there’s no guarantee that people will embrace it just because it’s more secure. In fact, if the slow uptake of two-factor authentication is anything to go by, I imagine getting users to adopt it will be an uphill struggle.
One of the reasons that passwords have hung around for so long is that they’re very, very easy to understand. Passwordless authentication works in a different way, isn’t as easy to grasp, and comes with a lexicon of new (or relatively new) acronyms and standards like FIDO2, WebAuthn and CTAP.
It also comes with misunderstandings. Users who come at it assuming it works something like password authentication are left wondering if using their fingerprints to sign on to a website means sharing their fingerprint data (it doesn’t). Passwords might not be great, they reason, but at least they can change them if there’s a breach.
Passwordless authentication is a Good Thing and it deserves some explanation.
In this article I’ll try to explain, in simple terms, how it all works, what some of the important acronyms mean and how they fit together.
How to log in without a password
Normally, when you sign up for a website you have to tell it who you are and what password you’re going to use. Once you’ve shared that password you have no control over what the website does with it, you simply have to trust that the site will store it safely.
A quick glance at the number of data breaches in the news will tell you how well that’s working out.
With passwordless authentication you don’t have to trust the website with a password, or any other kind of secret.
That’s because it uses public key cryptography, which authenticates you using a pair of cryptographic keys: a private key that’s a secret, and a public key that isn’t.
You keep the secret, private, key and you give the public key to the website when you sign up. Because the public key isn’t a secret you don’t have to worry about whether the website will keep it safe, lose it in a data breach or leave it in the back of a taxi.
The public key can only unlock things that were locked using the corresponding private key, and that never has to leave your possession.
You authenticate yourself by using your private key to encrypt a challenge (a very large random number) sent by the website and then having the website decrypt it with the public key. If the encryption/decryption sequence works and the web server gets its challenge back then congratulations, you’ve proved you’re the owner of the private key.
That’s the theory.
To make it work in practice you need something that can create and store keys, an Authenticator, and a set of rules that allows your computer, your browser and the websites you visit to cooperate and make it all work.
WebAuthn
WebAuthn is a recently minted set of rules, an API (Application Programming Interface), that websites and web browsers can use to enable authentication using public key cryptography instead of passwords.
All the major browsers already understand how to handle WebAuthn, so now it’s up to individual website owners to do their bit and change their code.
Instead of providing a login form where you type your username and password, websites can authenticate users using JavaScript code embedded in its web pages.
The code uses the WebAuthn API to ask browsers to create credentials, when you want to sign up to a website, or to get credentials, with you want to log in.
Although the JavaScript code is downloaded with the web page and is running on your machine, in your browser, it’s still considered part of the website so it isn’t trusted with access to your private key, or any other secrets.
Instead, it just acts as a go-between, asking your browser to do the secret stuff, and then relaying information back and forth between the browser and the website’s web server.
Although the browser accepts requests to do the secret stuff it doesn’t actually do them. It’s a go-between too and actually outsources the secret stuff to the authenticator.
Authenticators
By design, a website you’re authenticating to doesn’t know or care how you generate or secure your private keys, so you’re free to do that in what ever way suits you.
You can use authentication that’s built in to your operating system, such as Microsoft’s Windows Hello facial recognition, or a remote authenticator like a cell phone or a security key.
To support a wide variety of remote authenticators efficiently, it was important that the major players agree a set of rules about how web browsers and authenticators are going to talk to each other. The rules free browsers from having to know or care about different authenticator types, manufacturers or versions, and make it easier for companies to enter the market with new authentication solutions (something that has been difficult in the past).
Those rules are called CTAP, the Client to Authenticator Protocol, and they define how a client like a web browser can talk to a remote authenticator over USB, Bluetooth or NFC (Near-field Communication).
(While we’re talking acronyms, let’s get another one out of the way: FIDO2. FIDO stands for Fast IDentity Online and FIDO2 is just an umbrella term for the combination of WebAuthn and CTAP.)
The authenticator provides the cryptographic know-how in the whole transaction, generating and storing your keys, and encrypting the website’s WebAuthn challenge on behalf of your browser.
Crucially, the authenticator must ask your permission before doing its crypto-magic. From the CTAP specification:
In order to provide evidence of user interaction, a roaming authenticator implementing this protocol is expected to have a mechanism to obtain a user gesture. Possible examples of user gestures include: as a consent button, password, a PIN, a biometric or a combination of these.
And that’s where all the different forms of authentication come in, and why if you choose to log in to a website using your fingerprints they aren’t shared with that website – they’re only ever used to unlock the authenticator.
Your secrets, like your fingerprint data (or face, PIN, iris etc) and your private keys, are only ever shared with the authenticator, a device that’s in your possession.
Putting it all together
Let’s say you’re logging on to a website using your fingerprints.
You arrive at the website and your web browser requests the login page. The code in the login page uses the WebAuthn API to ask your browser to sign a challenge using your private key. Your browser passes the challenge to the authenticator, and the authenticator asks you to grant it permission to sign the challenge, which you do by putting your finger on its fingerprint scanner.
The authenticator checks that, yes, it’s your finger, signs the challenge and passes it back to the browser, which passes it back to the website’s client-side JavaScript code, which hands it back to the website’s server. The server successfully decrypts the challenge with a (non-secret) public key you provided when you signed up, proving who you are.
Although behind the scenes it’s more complex than simply sending the website a password, you’ve done almost nothing.
You’ve not had to type anything or remember anything. You’ve proved who you are without anything secret leaving your possession, and if you want to upgrade your security tomorrow with a newer, shiner, more secure authenticator that doesn’t rely on fingerprints you can.