A look into password-less authentication with Passkeys

In the past weeks, I have taken a first look at #Passkey , the new password-less authentication mechanism recently made available by 苹果 , 谷歌 and 微软 . How does it work? What are its properties?

Passkeys make use of the authentication standard #FIDO2 , which itself consists of #WebAuthn and the Client to Authenticator Protocol CTAP2. Passkeys are designed to enable password-less authentication.?

Using a password, a user seeks to prove toward a (web) service the knowledge of some secret (the password). Passwords must be kept secret, which is why web servers normally seek to protect them through hashing and salting: they never store the password, not even in encrypted form, they only store information about the password. But still, even good passwords can be compromised: improperly configured servers still exist, and if people then reuse passwords across services, they may be stolen. Another common threat, increasingly so with the advent of #ChatGPT and the like, is phishing: if somebody manages to lure me into entering my password into a website the attacker owns, all bets are off. So why not rid ourselves of Passwords entirely? By supporting passkeys, Apple, Google and Microsoft now seem to have made an important step in that direction: while they still allow password-based authentication (for now at least), using passkey you can now log in also password-less!

From a user perspective, passkeys work as follows. To set up passkey, you log into your account as usual and then generate a passkey for a given device. On a desktop, that device will typically be your browser, on a mobile device it will be the device itself. Both browsers and mobile phones provide secure generation and storage of secrets, i.e., cryptographic keys. So when you ask the web service to generate a passkey for you, it will ask you which device to store it on. That device will then itself generate a new key (actually a public/private key pair) and store it. The server is being made aware of the public key. Next time you wish to log into that same service, the service then sends to the client, i.e., the browser or device with the passkey, a challenge. The client responds to that challenge by signing it with its private key (which only ever remains on the device), and the server validates the signature using the stored public key. It also validates the challenge itself, which protects against phishing.

There are a number of important things going on here: First, there is a new passkey for any device and any service. No secret is ever reused. This means that keys can be easily revoked at any time. Second, the way the standard it implemented, passkeys are always protected by a second factor, usually your fingerprint. Hence, when you use a passkey, you will have to use a device with a fingerprint sensor. This is an important feature, essentially proving not just that you still own your device but also that you are really you. Essentially, this way, passkeys have two-factor authentication built in. You no longer prove to the service knowledge of something, but possession (of your device) and inherence (who you are).

Now, hopefully, I am not that likely to lose my fingerprint, but what if I lose the device with my secret passkey? To deal with this, the standard allows sharing, between devices. The way I have understood it so far, and observed it in its implementation at Google, is as follows: Using your desktop browser, you log into Google, e.g. by confirming the authentication using your passkey and fingerprint on your Android phone. Google will then offer you to generate a new passkey to be stored directly into your desktop browser. Again you will be asked for your fingerprint - this time on your desktop (or a MacBook in my case, which has a handy fingerprint sensor built in). A nifty detail: As an added security measure: Google will now ask you to place your phone next to your laptop. Why? It uses bluetooth low energy to ensure the physical proximity of both devices. This is also part of the standard. No additional data is being sent using bluetooth, so bluetooth (in)security is not an issue.

One limitation of Google's current implementation is that it will not always alert you that bluetooth needs to be enabled on both devices, and that the browser needs permissions to access it. It took me some minutes ot figure out why authentication at first did not work although the devices were in "close proximity" as Google had asked.

Overall, I think that passkeys are a potentially big step forward. They protect against phishing very well, and are often more convenient to use than passwords. As long as you do not lose your device(s), they seem like a really user-friendly solution. Currently, Apple, Google and Microsoft still offer password-based login even if passkeys have been created. Maybe someday they will offer the option to disable password-based login altogether for an account. That could make things much more secure.

On one front, though, the three vendors have missed a big opportunity so far: they way they currently create passkeys, they cannot be used across vendors: Google allows me to create a passkey for an Android phone, not an iPhone, and Apple the other way around. Microsoft? I actually do not know. My hope is that this will be loosened up in the near future. Then passkeys could have a very bright future indeed.

Find more information here at Fido or here at Google or more technical documentation from Apple .