Insights

With passkeys, the vision of a passwordless future is now becoming a reality.

Passwords have been a source of frustration for years, prompting the quest for a more secure and user-friendly authentication method for online services. With the advent of passkeys, the vision of a passwordless future is now becoming a reality.

Microsoft recently announced support for Passkeys within Microsoft Entra ID.

‘Passkeys’ is a relatively new term, so you might be wondering what a passkey is, how it’s more secure than passwords with Multi-factor Authentication (MFA), and what the future holds for passwords.

This article addresses these questions and explains the concept of passkeys. Although passkeys are technical, we won’t delve too deeply into the mechanics of how they function.

Contents

• A brief history of passwords and authentication
• The threat of phishing
• Passkeys explained
• Authenticator and Passkey Types
• Microsoft Entra and Passkeys
• What does the future of passwords look like?

A brief history of passwords and authentication

Before we touch on passkeys, it’s helpful to first look at where passwords originated and the various controls we put in place to try to secure our identities.

Password and username

At first, we just used passwords and a username to sign into our accounts. Passwords are essentially a secret, while usernames are often publicly visible or easy to guess or obtain (e.g. your email address). Passwords have never been very secure, but a password is something that the average person understands. It gained significant traction and became the de facto method for protecting our accounts.

One-time Passwords (OTPs) and early 2-factor authentication (2FA)

As computing power increased, passwords became easier to break using malicious techniques, such as brute force attacks (where attackers use powerful computers to systematically try potential password combinations until the correct password is found). Therefore, many services started to require a second factor of authentication (2FA) when signing in—with the use of one-time passwords (OTPs)—in addition to your username and password. An example of this is where you’d sign in, and you’d receive an SMS message with a code that you had to type in. This worked, but could be exploited by simple social engineering techniques.

The FIDO standard and Universal Second Factor (U2F)

The next evolution was the use of FIDO, and at this time, it was FIDO version 1 (also known as FIDO, FIDOv1 or FIDO1). FIDO stands for Fast Identity Online and was based around having a much stronger secondary form of authentication, in addition to your username and password. You’d normally use a key or a fob for this form of stronger authentication, and you may have heard the term U2F – Universal Second Factor.

Authenticator Apps

Then came the authenticator apps such as Microsoft Authenticator, Google Authenticator, and Twillio’s Authy etc.

Approve/deny push notifications

Initially, apps like Microsoft Authenticator used a simple Yes/No (Approve or Deny) prompt after your first sign-in with username and password. While better than not having any form of MFA, this method was susceptible to “MFA fatigue attacks”, which involved attackers spamming the victim with frequent MFA push notifications until they hit “approve” in frustration to make the notifications stop, inadvertently granting the attacker access.

Number matching

Next, MFA was adapted to require the user to take additional action – in the form of pressing the number that matched on the screen, as well as additional context such as the location of the sign-in attempt and the cloud app being accessed.

The threat of phishing

There’s one common theme among all the password-based authentication methods mentioned above – they’re all susceptible to being phished.

As cyber-attacks increase in frequency and impact, the most common attack type is phishing, where a user is tricked into providing their credentials to an attacker. This is usually in the form of an attacker pretending to be a trusted source, such as masquerading as an IT employee.

Even modern methods, such as Microsoft Authenticator with number matching, aren’t immune to phishing.

Here’s two examples of how this could be phished:

• An attacker navigates to a Microsoft 365 sign-in page. They phone the user and pretend to be from the IT department, stating they must verify the user’s identity by pressing a number on the app. The attacker signs in, and tells the user they need to type in a number – that number being the number on the attacker’s machine – and the attacker is in.
• Or the attacker leverages more advanced phishing methods, such as Adversary in the Middle attacks.

All these methods discussed so far rely on the user’s cognisance. The user must verify the number, or they must verify that the URL they’re accessing is correct. These are just two examples of the reliance on users, which can weaken security due to the potential for social engineering.

Phishing-resistant authentication

Given the susceptibility of such techniques to phishing, phishing-resistant authentication methods are now required, which can’t be manipulated to trick users.

These phishing-resistant methods work by verifying the proximity and presence of the authentication request and the user.

This generally means a phishing attack cannot be performed remotely by an attacker, as it relies on the user’s authenticator and authentication request being in the same place.

Before passkeys, there were already other phishing-resistant methods available. To name a couple:

• Windows Hello (which is associated with only one device and allows you to sign in with facial recognition, fingerprint, or a PIN)
• Certificate-based Authentication

Both methods verify proximity and presence—and use cryptography for additional security.

The next phish-resistant authentication method to emerge was FIDO2. FIDO2 is the next evolution of the FIDO standard, where it was expanded to other organisations, including Microsoft, Apple, and Google. The main reason for this was to help drive wider adoption for more users. All modern devices now have hardware cryptographic capabilities – Windows devices have a TPM, Apple and Google devices have their own security modules. As devices were further modernised to include these hardware cryptographic capabilities, this provided individuals with the necessary hardware capabilities to support stronger authentication methods.

FIDO2 was first found in physical security keys, such as hardware security keys from Yubico and others. These security keys are USB/NFC keys and require a PIN or biometric authentication.

Passkeys

Research conducted at the time showed that the average person struggled to understand FIDO – it was a complicated acronym that didn’t really explain what it was. To help make it simpler to understand, the term “Passkey” was coined.

When we’re talking about “passkeys”, we’re essentially talking about passwordless FIDO2 credentials.

If you’ve used a FIDO2 security key before, you’ve been using a passkey. To help with wider adoption to the average person, you’ll start to see the term change from “security key” or “FIDO2 security key”, to use the term “passkey” instead.

What does a passkey comprise of?

We won’t perform a technical deep dive in this article, but a passkey comprises a tuple of these three pieces of information:

• User account
• Relying Party – i.e. the system you’re authenticating to with your passkey (e.g. a website)
• Authenticator software – either an app or embedded into the operating system (OS)

You will have a passkey for each provider/website you use, in the same way that you have a username and password currently.
You can simply go to a website, and instead of creating an account with a new password, you’ll be able to select “create a passkey”.

How do passkeys work?

In this section, we’ll provide a high-level explanation of how passkeys are created and how they’re used for authentication.

Passkey creation

Passkeys leverage “public key infrastructure (PKI) cryptography”.

When you create a passkey (let’s assume you’re registering for a website service), your authenticator creates a pair of keys. One is the public key, the other your private key.

As your keypair is created, your public key is passed to the relying party (e.g. the website provider), where it’s then stored in their database and associated with you as the user. The private key is stored separately on your authenticator.

There isn’t a security issue with sharing your public key, as it’s useless without the corresponding private key.

Passkey authentication (logging in)

So how do you log in with your passkey?

Again, let’s assume a user wants to log into a website with a passkey they’ve already created for that web service.

The graphic below shows how this process works at a high level.

1. The user accesses the website’s ‘sign in’ page on their device and browser
2. The user chooses the ‘passkey’ sign-in option and enters their username
3. The webserver takes the username and checks its database for a public key associated with that username, then retrieves it
4. This unique public key is then used to encrypt a ‘challenge’ which is sent back to the user’s device and authenticator
5. The user’s private key decrypts the challenge, and the user has to perform some sort of validation action which shows intent (e.g. enter a PIN or biometric)
6. The private key is then used to sign and encrypt a response, which is sent back to the web server
7. The web server uses the user’s public key to decrypt the response
8. This completes the user verification and authenticates the user

Note that no passwords were involved at any point in the process above. This is still a form of MFA, as the authenticator is ‘something you have’ and the biometric or PIN is ‘something you are or know’.

This is also considered phish-resistant, as the authenticator checks for presence/proximity, and intent. Without this, the authenticator cannot release the necessary information. When you sign-in using a passkey, two web standards called WebAuthN and CTAP (Client to Authenticator Protocol) are used to authenticate:

• WebAuthN is used to verify that the website (relying party) matches that of the passkey and other elements. This is partially what makes passkeys phish-resistant. This is because the WebAuthN specification mandates that the URLs match – if an attacker sends you to a phishing website, the URL won’t match that of the URL of the ‘true’ destination, and therefore WebAuthN will reject the authentication attempt.
• CTAP is used as the communication method to validate proximity and presence, and provides cross-device authentication. Therefore, it ensures that when you make an authentication request in a browser, it verifies that you’re physically near your authenticator (for example, by using a Bluetooth connection from the device you’re logging in from to your authenticator on your phone).

Authenticator and Passkey Types

Authenticator Types

The authenticator is what contains the cryptographic private key and performs validation using biometric or PIN authentication.

1st Party: iCloud Keychain on Apple devices.

3rd Party: Other authenticator apps, such as Microsoft Authenticator.

It’s possible for an authenticator to roam (i.e. move from your old iPhone to a new one when you upgrade, they are stored in your phone backup in the case of iCloud keychain).

Passkey Types

There are also two types of passkeys available, each with their own pros/cons. The two passkey types are:

Device-bound passkey

A device-bound passkey, as its name implies, is bound to a specific device. The passkey cannot leave the authenticator/device. This passkey can be stored in a few different medias, such as:

• USB for use in a security key
• TPM of the device, such as when using Windows Hello
• Stored on the device using hardware security mechanisms and used by an app, such as Microsoft Authenticator

One of the major problems with a device-bound passkey is if you lose your phone or your security key, you’ve lost the passkeys that are on that device. This means device-bound passkeys are likely to be favoured more in highly regulated or corporate environments, where loss of a device-bound passkey is an annoyance, but is not a significant blocker. In the corporate environment, an IT admin can provide a Temporary Access Pass to allow the user to set up a new device-bound passkey. The same cannot be said for the consumer world, however.

Device-bound passkey for Microsoft Entra ID in Microsoft Authenticator on an iOS device

Synced passkey

A synced passkey is whereby a certain entity is responsible for protecting my private key. The passkey is synced to the cloud service, but it is therefore only available for use within that ecosystem. As an example, I can set up a synced passkey with my iPhone and iCloud keychain. I can then go onto my Mac or iPad and use the same passkey – I don’t need to set up a new passkey.

That’s not to say that I can’t use a synced passkey that’s on my iPhone when signing into iCloud on a web browser on a Windows device, as I can, but the passkey won’t be stored on the Windows device, and I must be within the Bluetooth range of the Windows PC, with the two devices connected via Bluetooth.

Synced passkeys make a lot more sense for the average consumer. As an average consumer, if I lose my iPhone, I know that my passkeys will sync back down to my new iPhone.

Synced passkey for BitWarden synced using iCloud keychain

Microsoft Entra implementation of passkeys

As mentioned earlier, Microsoft Entra supports Passkeys using the Microsoft Authenticator app. The current functionality is in public preview stage and will reach general availability stage later this year.

At the time of writing, Entra ID currently only supports device-bound passkeys. Synced passkeys are coming soon, but Microsoft haven’t provided a date as it stands. In addition, there are some limitations. These are:

• For users who wish to use the functionality in public preview, their mobile device must be running iOS version 17 or higher, or Android version 14 or higher, as passkey support relies on foundational components within the operating system.
• An admin must set the AAGUIDs (this is the Authenticator Attestation GUID – which is part of the FIDO2 specification, and is a 128-bit identifier indicating the type of authenticator) for the passkey authenticators that they would like to support. This must include the AAGUIDs for the Microsoft Authenticator app on both iOS and Android. AAGUIDs are unique identifiers for the authenticator, such as specific apps or specific FIDO key manufacturers, and allow an administrator to control the specific types of authenticators permitted.
• Key attestation (that is, the capability of a FIDO authenticator to provide cryptographic proof about its model to a remote relying party) must be disabled during the public preview. Attestation will be supported by the time functionality reaches General Availability status.

What does the future of passwords look like?

No one has a crystal ball for the future. However, we expect that the adoption of passkeys and passwordless authentication will grow. Device-bound passkeys are likely to increase in use in corporate environments, whereas synced passkeys are likely to increase in consumer environments, and in less-regulated corporate environments.

One key consideration is that web providers must increase their support for passkeys and other passwordless authentication methods, while allowing users to disable passwords as an authentication method. Security is not improved if the password authentication method is still available.

Microsoft provide this functionality today for their consumer services, such as Xbox and Outlook.com, but care must be taken to ensure that users are not locked out of their accounts – particularly if using device-bound passkeys to accommodate the lost device scenario.

The ease of use and simplicity from an end user perspective is great to see, and it’s also fantastic to see leaders such as Microsoft, Apple and Google working on a set of standards, without the use of proprietary implementations. The ideal passwordless future is one where passkeys are one of a few different passwordless authentication methods that are in use. Passwords have been in use for far too long and are one of, if not the most insecure part of most systems today.

Due to the recent push by these organisations, I’ve recently had conversations about passkeys with non-technical colleagues, which is testament to the ease and simplicity of them.