Passkeys

Don’t we all know the hassle of managing loads of passwords, trying to come up with secure and unique ones only to try afterwards to remember them? Or always staying on high alert whether the URL is definitely the valid one for the website we are trying to visit?
What if all this could be over soon?

Welcome to Passkeys!

Based on FIDO standards, passkeys are a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys cannot be guessed by attackers and are phishing-resistant. Passkeys simplify account registration for apps and websites, are easy to use, work across most of a user’s devices, and can even be used on other devices within physical proximity, according to the FIDO Alliance.

But who is this FIDO Alliance you ask? The FIDO Alliance is an open industry association with a focused mission: reduce the world’s reliance on passwords. To accomplish this, the FIDO Alliance promotes the development of, use of, and compliance with standards for authentication and device attestation.

OK now we know they don’t like passwords. But let’s take a step back and try to understand why that is.

Passwords and Their Problems

The most prevalent issue around passwords roots in the fact that users will have to remember them. Consequently, users tend to choose passwords based on things that are familiar to them – like the name of a relative or pet, their favorite holiday locations, movies or books. As required by most password policies, throw in some special characters and numbers et voilà, you’ve got your password. However, while “Hemingway61!” or “$Mallorca89$” might look hard to guess, that’s not really the case. Attackers can simply follow along the same thought process to try and come up with potential password candidates – oftentimes with alarmingly high rates of success.

The most obvious solution to this might be to resort to randomly generated passwords that don’t follow any specific patterns or logic and are therefore hard to guess by attackers.

But now they are hard to remember, so one idea is to just use the same strong password for multiple services. This creates another problem. If one of those services is affected by a security breach and all used passwords are disclosed, whoever gets access to them can try the same passwords on other services. The next logical step would now be to create secure and random passwords that are unique for each service. At this point – unless you possess an eidetic memory – you might require some technical assistance to help you manage and remember all those passwords, something like a password manager. While this is generally considered a good practice, there are still some caveats to consider. Regardless of the password manager solution, now the access to it is very important, because if the password manager is compromised, so are all your passwords. This opens up other topics like securing your password manager with two-factor-authentication, enabling or disabling synchronization between devices etc.

No matter what approach is used to choose passwords, another big security problem are phishing attacks. In a phishing attack, an adversary usually recreates a login website for any popular service and publishes it on a URL that is very similar to the original login page. Instead of URL google.com the same login page can be published on something like gooqle.com with the second G replaced with a Q. Attackers will then try to trick unsuspecting users into visiting this phishing page to enter their password. If they do so, the attackers can use the password to login to the legitimate service in our name (and also try the same credentials on other services).

To avoid such attacks, users are often told to closely look at the domain displayed in the browser address bar before signing in. However, in today’s interconnected and interwoven Internet landscape with identity providers scattered all over the place, new fancy top level domains popping up constantly and websites being visited from all kinds of devices, this proves to be highly unreliable and even security-aware IT professionals are prone to fall victim to phishing attacks.

At this point, we are faced with quite a list of problems associated with password-based logins, and only some half-baked solutions to address them. Time to introduce passkeys!

What is a Passkey?

A passkey is basically a passwordless login mechanism. If you’re wondering now if that means you don’t need to remember anything, you’re correct. But what do you need to prove its you? For example, one way is to use what you have and what you are to prove that. More specifically you can use your mobile phone to store a passkey, and during the login process to a website you must provide your fingerprint or face recognition to your phone in order to complete the login. As a result, without possessing your mobile phone and your fingerprint, no one else can log into your account on this website.

Passkeys make use of public key cryptography. So, if you’re browsing with your Client (this can be a browser on your computer or phone etc.) and you want to register with a new service (we will call that Relying Party or RP for short) using a passkey, your client and the RP will automatically agree on a cryptographic key pair that is later on used to log in. Each key pair is associated with a specific RP, denoted by a so-called Relying Party ID. This ID corresponds to the domain you want to register with.

Let’s say you want to set up an account with Github. In this case, the ID of Github would be “github.com”. Behind the scenes, a few additional checks are performed to ensure the registration can be completed securely. For example, your browser will verify whether the RP web site uses encrypted communication with a properly configured and valid certificate. Secondly, your client will also compare the domain of the website you are currently visiting with the Relying Party ID that it advertised. If any of these checks fail, the registration process will be cancelled. Otherwise, the registration continues and both parties verify that the cryptographic keys have been set up correctly through a challenge-response protocol based on a digital signatures. After this, the process is completed and you have now successfully registered your authenticator with the Relying Party, along with a cryptographic key pair and a few additional pieces of information such as the ID of the Relying Party.

The following diagram shows a simplified sequence of the registration ceremony (please note that some technical details & aspects are omitted here for simplicity):

Later, if you want to authenticate to the Relying Party, you will have the option to do so using your passkey instead of (or in addition to) a password. The Relying Party (let’s assume Github again) will send its ID (e.g. “github.com”) to your authenticator, along with some additional information, such as a challenge.

If your authenticator has a passkey associated with the respective ID (remember this was stored along with the key pair during registration), the process continues, and your authenticator will again perform some security checks for you. Specifically, it will verify that the ID of the Relying Party matches the domain you are trying to sign into and that the communication is protected by encryption and a valid certificate. If all checks are passed, the authenticator signs the challenge received in the first step with the private key and returns this response back to the RP for verification. After validating the digital signature, the RP completes the sign-in process by authenticating the user.

Note that the process described above takes place without requiring the user to provide any form of secret or password (there are authenticators that can be protected with a PIN or fingerprint however). This means that a user generally does not have to remember or safely store any information associated with a login.

The following diagram shows a simplified sequence of the authentication ceremony (please note that some technical details & aspects are omitted here for simplicity):

Do Passkeys Really Fix the Password Problems?

In the beginning of this article, we discussed a few common problems with passwords. Let’s quickly recap them. Passwords are:

• often easy to guess
• hard to remember if chosen securely
• reusable across different services and accounts
• susceptible to be leaked by third parties
• susceptible to phishing attacks

If one now decides to use passkeys instead of passwords, how are these concerns addressed?

First, let’s talk about guessing passwords. As explained previously, passkeys are based on cryptographic key pairs automatically generated by the authenticator. This means that we can already eliminate the problem of users choosing insecure, easy-to-guess secrets. Of course, the actual resistance against guessing attacks (i.e. the entropy of the keys) depends on the underlying cryptographic algorithms. Which algorithm is used in a given instance is agreed upon by the authenticator and the Relying Party during registration. Given a properly hardened setup (i.e. up-to-date authenticator, and restrictive set of supported algorithms) the risk of an attacker guessing a passkey is negligible.

The fact that passkeys are automatically generated and stored on the authenticator also addresses the second problem of hard to remember credentials. When using passkeys, users effectively don’t have to remember anything at all.

In order to tackle the problem of password reuse, a new passkey is generated for every registration procedure and associated with the respective Relying Party ID. This means that every key pair can only be used for one service. So even if a specific passkey would be compromised, an attacker would not be able to authenticate to other Relying Parties with it.

While on the topic of compromised keys, let’s discuss what would happen if – instead of your authenticator – the server of a Relying Party gets compromised. With regular passwords, this usually means that some secured representation of your password (ideally a salted hash) is leaked to the attacker. In the worst case, the attacker may even be able to recover your cleartext password, which could then be used to log into other services. With passkeys, the RP only stores the public key on their side, while the private key remains protected on your authenticator. So even if the Relying Party gets compromised, this only discloses your public key, which can not be used to authenticate. Yet another problem solved!

This leaves us with maybe the most important concern. Can we really browse the internet without worrying about phishing attacks?
As we saw earlier, with every sign-in the Relying Party specifies its ID as part of the authentication protocol. The browser then verifies whether the RP ID matches the website you are visiting, and whether the website uses encryption and has a valid TLS certificate before the authentication continues. As a user, you don’t have to do anything in this process. In fact, you can’t do anything, even if you wanted to. The passkey mechanism has no option to allow a user to bypass these checks (as compared to when your browser warns you about an invalid certificate for a website).

Let’s look at a specific example of a phishing attack:
If an attacker tries to impersonate a legitimate website like  github.com, using for example a Machine-in-the-Middle attack, the connection will typically either be unencrypted or show an invalid TLS certificate. In both cases, our browser will fail the previously mentioned checks and the authentication will not complete. So far so good.

But what if the attacker lures us to a cloned version of the Github login page, hosted on qithub.com for example? Then the Relying Party ID check will kick in. The browser compares the domain of the page we are visiting (qithub.com) with the Relying Party ID announced by the phishing web server (github.com). As these values do not match, the authentication process is stopped again. But wait a minute – why can’t the phishing web server simply announce an ID that aligns with its domain, so “qithub.com”? In theory, the phishing web server can of course do this, but then our authenticator would not be able to locate the correct passkey to sign-in, as our passkey for Github is associated with the ID “github.com”. As you can see, if we use passkeys to authenticate, we can browse any website, but if it is not the correct one (where we initially registered) the passkey will not authenticate to it. Or in phishing terms, we are off the hook.

About Authenticators

We already learned that we need an authenticator to create, store and manage key pairs. Authenticators come in all shapes and sizes, but they can be categorized into two groups. On one hand there are platform authenticators where the credentials are stored on the same device (or ecosystem) that uses them to authenticate. They are embedded in the hardware and because of this tied to a specific device. Examples include the secure Windows Hello where the authenticator is embedded in the hardware of the Trusted Platform Module (TPM). Apples iCloud Keychain or Google Password Manager are also considered platform authenticators, since they can only be used on systems within the same ecosystem (even though the authenticators are implemented in software).

On the other hand we have cross-platform authenticators. As the name tells us they can be used across different platforms or systems. Colloquially, these devices are called security keys and adhere to the FIDO2 and WebAuthn standards. Among the most famous one are YubiKeys. They can be connected via means like USB, Bluetooth or NFC to any other platform and be used to create and use passkeys.

Attestation

With all these different types of authenticators available, along also come some differences in terms of security features. And of course, there also exist malicious or rogue authenticators that do not (fully) adhere to the proposed standards and are therefore not trustworthy.

To provide verifiable information to a Relying Party about the type of authenticator used to create a passkey, a so-called attestation mechanism is available. The way this works is during the registration of a passkey, the authenticator sends an attestation statement to the server, which includes metadata about the authenticator (manufacturer, type, security level). The attestation itself is signed with a certificate pre-installed on the authenticator by the manufacturer. The RP can then verify the attestation statement by checking the signature against the attestation certificate provided by the manufacturer. Based on this verification the Relying Party can either accept or deny the registration request, depending on its own security requirements. For example, the operator of a website might limit the accepted authenticators to a very specific make and model.

Implementation

Now if you want your websites users to be able to profit from these security benefits and support passkeys, there are a few things to consider.
Since the security of passkeys is reliant on how cryptographic functions are performed, it is important that they are implemented correctly. Exactly for this the FIDO Alliance in collaboration with the World Wide Web Consortium (W3C) has developed a web standard called WebAuthn (short for Web Authentication) which defines an API enabling the creation and use of strong, attested, public key-based credentials by web applications, for the purpose of strongly authenticating users. At the moment the latest version 3 of the WebAuthn standard is still a working draft. They are continuously working on in to improve the standard and integrate new functionality.

Since there is a standard you are probably not the first person trying to implement this for your web application and that’s exactly why webauthn.io
does not only provide a demo of the WebAuthn specifications but also references multiple libraries implementing WebAuthn for different programming languages.
Regarding security configurations, it highly depends on your use case. For example if you have a corporate website and all your employees already own a security key, it is possible to only trust these corporate issued ones to register for the website. On the other hand if you have a public website with a wide range of users you probably don’t want to restrict the usage of certain authenticators, to make the use of passkeys available to as many users as possible. If you are interested which operating systems, browsers etc. support passkeys, or their specific features like for example attestation support, the website passkey.dev gives you more information about that and keeps things up to date.

Now with all that said, there is nothing more stopping you from leading us into a new passwordless future.

Compass Security Blog – ​Read More