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.
Epic_Null
While I feel this is more likely to be adopted than multifactor authentication (I fail to do it when only mobile phone based 2 factor is avalible to me since I don’t like handing out my phone number and refuse to rely on it’s accessable, functional presence), one thing I don’t see mentioned is how users can protect and move their private key. If I use Microsoft Hello, will this leave me unable to sign in to anything from my phone? What if my hard drive dies (This happened to me last week) or I drop my RSA card?
I should probably mention that I have a design tweak to help with these things already – storing and managing the public keys in key servers instead of individual sites could help with lost, stolen or damaged credentials since there would be a central location to change them from. Then standards would HAVE to allow import and export of keys to other devices (though only once authenticated) to prevent the user from being locked out of everything when on a different device
Wilbur
“If I use Microsoft Hello, will this leave me unable to sign in to anything from my phone? What if my hard drive dies ”
Given Microsoft’s track record with Windows10 spyware I would expect they have already “backed up” your secret key information on their servers “for your own good”. I like the Yubico physical key approach but most websites don’t use it because they can’t monetize the information by forcing you to give up a telephone tracking number or email address. I haven’t looked lately, but some Yubikeys have Near Field Communications in addition to USB, so the key on your key chain can be plugged in to a USB port if one is available, or NFC if supported by the phone or other device.
I have been hoping more websites would adopt physical tokens but so far I don’t see it happening for the general public. I thought maybe Google was moving in the right direction when they recently announced their new token to compete with Yubico, but then I saw they were having them manufactured in China. That inspired a lot of confidence that secret keys would remain secret.
Farid Tahery
My thoughts exactly with one difference. Instead of adding support for key import and export which is bound to increase the cost of authenticators, we only need public key servers to allow a secure method to change our public key using our current key pair, much the same way that we currently set a new password by entering our current password. We’ll also need a secure way using other methods of authentication to set a new public key in case we lose our authenticator and obtain a new one, again similar to resetting password.
Epic_Null
While I see what you are thinking, that still leaves users with a problem while swappimg devices. While the key server allowing key swapout is a good and critical element, RSA keys are not typically expected to change often. I suppose supporting multiple active key pairs could work, though this would make securing a message to be read later a bit tricky, since you have to guess which device it will be read on.
Farid Tahery
I agree that unlike passwords, having different “active” RSA keys is not necessarily a good thing. I believe we need to change our public key ONLY when we have reasons to believe our private key has been compromised.
SpikeN
Fantastic article, but would have loved more information on what happens if you loose your token? Can you have multiple ones? I have two computers at home (not including ones at work) and would prefer not to keep swapping my token between computers nor have to remove it to auth my phone or tablet. I love the idea but I am struggling to put it into use for myself as all I can see that it will create a lot of extra steps/trying to find my token.
Ideally (I do not know if this is possible) to have at least 3 tokens (one for my main computer, one floating at home for phone/tablet/other and one on my key ring for out and about auth and to be used on my work system) but I have found no information if this is possible, can you sync multiple tokens together or are you allowed to register multiple tokens on a website (I’m guessing this would be down to the individual website) so they work the same? I get that it would increase my risk a little if I lost one of the tokens.
I really want to get behind the idea
Mark Stockley
What happens if you lose your token is down to each website and how they’ve implemented authentication. In theory, yes, you can have multiple tokens, so you should expect sites to honour that.
The first two services I signed added a key to were GitHub and Dropbox. They both use keys for 2FA rather than for true passwordless authentication and both will allow multiple keys, alongside other forms of 2FA.
So, for now, I have added a key and an authenticator app for 2FA on both. The key is more convenient and the authenticator app is a backup.
Anonymous
I guess this will be handled by the authenticator. Upon registration there will be created a public/private keypair with a additional key ID. A server having multiple services to offer would have no way to track down the services a user therefore uses as upon registration different keypairs are generated each time. This key ID will be sent along the challenge for the authenticator to sign and it will according to this key ID lookup the belonging keypair which he can sign the challenge. Using multiple clients , like 2 different computers are no problem , since the authenticator is a USB key or your mobile phone having these tokens stored. So you theoretically just need your authenticator and could use whatever laptop to sign yourself in to the service.
JohnH
On the one hand biometric authentication sounds fine, I think, but then I think about this article I read recentlly; [URL removed]
So not only does it look like all devices if can be hacked but I can’t change my fingerprint, face, iris! There is also the issue that all not web sites need the same level of security. For example I care a lot less about the security for a new website that I visit occassionally that I do about my bank. Not all websites are the same and allied with that there are occassions when I might want a third party to access a site on my behalf. I suspect that people being people there will be no one solution that will satisfy all.
The point about the undersandability of the security system both in terms of what it does, how it works and what happens when it goes wrong are all very relevant to users!
Mark Stockley
We don’t allow links to external sites. Fortunately, Naked Security covered the story you’re referring to. Readers can find it here: https://nakedsecurity.sophos.com/2018/11/16/ai-generated-skeleton-keys-fool-fingerprint-scanners/
Spryte
I would like to like this idea but I refuse to enter my biometrics anywhere. Not google, microsoft, firefox…
Not having a mobile ($30+ a month just for 2FA is not an option), I will stick to passwords.
Mark Stockley
The only place that you enter biometrics is on something you own. No biometric data is shared with anyone, it doesn’t even get as far as your browser.
David
I am always amused when someone says, “No data is shared with anyone.” Whether by design, deceit, or discovery, someone always manages to find a way to steal your data. The case (reported here) of AI-cracked fingerprint ID (also biometric) is a good example. Two factor is a pain, but using biometric data is just as dangerous as giving someone access to your DNA. It’s mine, and I’m not giving it to anyone.
Mark Stockley
I understand your concern about biometrics – you can’t change them if they’re compromised. My point is that stealing your biometrics isn’t like stealing your password because the biometric data is on your device where you’re responsible for securing it, not on a remote website where you’re trusting somebody else to secure it.
The beauty of FIDO2 is that you are not limited to any particular authentication scheme, so if biometrics aren’t your thing you can choose something else. You might use an authenticator that uses a PIN instead of biometrics to authorise cryptographic actions. Your PIN wouldn’t leave your device so it’s not stored on the website and can’t be exposed in a LinkedIn/Equifax style data breach.
Jay
Fingerprints and facial recognition are more akin to usernames than passwords. Moving in this direction worries me.
Biometrics shouldn’t belay 2FA.
David B
I really like this article, but let’s say in the case of I decide to do this and use say my fingerprint and subsequently lose that appendage, how do I get out of that hole then? Amputations happen more often than most of us think. .
Easy as 1-2-3
Easy. You already have the ability to add multiple fingerprints to the system on today’s smartphones. And fingerprints system does not actually mean you must use fingerprints. Scan your elbow, cheek – anything you are sure you won’t get amputated eventually, or hope you wont ;) At the end of the day, there’s always an option to contact the support and send them a photo of your amputated limbs and a sad face
Anonymous
It would be great if this article could be updated to include more detail regarding what exactly FIDO2, U2F, OATH – TOTP (Time), and other protocols supported by Yubikey listed here: [URL removed] are and the differences between them and which is the most secure to use.
Mark Stockley
OATH and TOTP are out of scope for this article, but I might cover those in later article.
FIDO2 is explained in the article: it’s an umbrella term for WebAuthn and CTAP, the two technologies required for passwordless web authentication.
U2F is also known as CTAP1 and it’s a protocol for devices (roaming authenticators in the jargon) used in two-factor authentication. CTAP2 is a protocol for devices used in passwordless authentication (single-factor or multi-factor). The CTAP specification includes both CTAP1 and CTAP2 so that FIDO2 is backwards-compatible with U2F.
So, FIDO2 supports U2F second-factors and CTAP2 single- or multi-factors.
Anonymous
I believe Titan keys actually only support U2F, not FIDO2/CTAP2 for passwordless.
Lawrence W
I’m very much a proponent of public/private key authentication. Tightly integrating it with web browsers to secure user accounts should greatly enhance security across the web.
However, there are some practicality issues–some of which, such as losing one’s Yubikey, cellphone, finger, etc, have been noted above–but from a more mundane perspective: what do I do when I’m traveling (abroad) without my laptop or cell phone?
Epic_Null
I suppose you would have to take your keys with you somehow. I know they make cards designed not to give up your private key, but will encrypt and decrypt.
Paul Ducklin
So-called hardware security modules do this: the private or secret key never leaves the device (in theory) so that keeping the key secure is equivalent to keeping the device secure – you never have to worry how many copies of the key are floating around. NFC cards such as train tickets and credit cards work this way: the card can generate keys and perform cryptographic operations under those keys, but the keys themselves aren’t supposed to be extractable. If you have the card, then you have the key and no one else does. That is a surprisingly useful simplification of the problem of managing keys!
Of course that means you need some serious security for the device itself – either a password, or a PIN with a very limited number of guesses allowed, or a fingerprint reader, or a safe, or somesuch. Phone SIMs take the PIN-with-rate-limiting approach – three wrong short PINs (typically 4, 5 or 6 digits) and you need to use the much longer PIN unlock code, or PUK, that you got when you bought the SIM and locked away in a cupboard at home; 10 wrong PUKs and the SIM destroys itself.
Mahhn
My concern is this creates a single point of failure for access to, well, everything. Whether the key be; lost, damaged, stolen, blocked by X agency (mistakenly or otherwise), subject to the same fraud as SIM swapping.
Epic_Null
To be fair, however, it’s the same single point of failure as a password manager (but with less information when a breach occurs). Instead of having each site you visit be a single point of failure for your reused passwords, only your authenticator would be able to leak your key. From many to one, and all made more secure for it.
Mahhn
True but, I can make a backups of a PW manager.
Epic_Null
You can also make a backup of a private key if you can get to it. PEM is a common format understood by many encrypters, so if your authenticator supports imports and exports, you’re not far from your previous situation.
John E Dunn
WebAuthn (i.e. FIDO2) allows users to register multiple devices or authenticators – it’s simply a way to authenticate without having to use a password. The point about passwords is they are they can be accessed by service providers or stolen by cybercriminals – that’s a pretty big point of failure.
Curt
This is a great article. I did experience this at my former employer when they started to roll out Office 365 for Business.
I already had been using Mobile Iron to have access to my work for email and appointments on my cell phone, so when they converted me to Office 365, all I had to do was setup Microsoft Authenticator and now I had access to Sharepoint, Teams, One Drive, and other Microsoft programs at work from my cell phone, tablet and home computer.
The integration between my iMac, iPhone, iPad, and Apple Watch made this really slick. When I wanted to go to Teams or my One Drive for Business on my iMac, if my watch was unlocked, I would get the question on my watch to go ahead and authenticate. If my watch was on the charger, then I I would use TouchID or FaceID on my iPhone.It was quick and painless from a login standpoint.
It just all worked together.
Jones
It would be nice to implement a good Zero Knowledge Protocol – no fingerprints needed. The protocol by proper designed does not leak “any information” about the users credentials (password) – period. As a side note: In other countries, people are voting on their cell phones using ZKP.
Paul Ducklin
The fingerprints aren’t part of the protocol – just a way of locking the private key parts of it so they don’t need unlocking with a conventional password before they are accessed by the code that is performing the protocol.
Epic_Null
Perhaps with the discomfort around the use of biometrics, a shift should be made from biometric authenticators to an alternative system. The protocols would inherently support a non-biometric authenticator, so decoupling the ideas may help generate acceptance for what is a good idea. Even a familiar password prompt can be an improvement when coupled with this model, since it would have many of the same benefits with less resistance
Mark Stockley
Indeed, the protocols inherently support non-biometric authenticators and problems with biometrics are red herring when assessing the usefulness of FIDO2. As the CTAP spec, quoted in the article, says:
“…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.”
I have a FIDO2 key plugged in to my computer right now that requires a consent button, no biometrics involved.
Joe
Mark, if I set up access to a website with my fingerprint as you describe, and then try to access that same website with my (obviously identical) fingerprint on a different computer, that would not work, because the private key would be only on the first computer, correct?
Mark
The fingerprint (or PIN, button press, or any number of other possible authentication gestures) unlocks the authenticator which contains the private keys and does the cryptographic operations.
So the answer to your question is: yes, if the computer is the authenticator, as it is in the case of Windows Hello, and no, if the authenticator is something portable, such as a YubiKey, that you can plug in to any computer.
bwmuller
This might just be me missing it in the article, but how does it handle multiple accounts on a single website. An example would be multiple Microsoft, github or Google accounts for the same user. Does it still require me to enter a user name before it gets my credential from the system?