FIDO passkeys part 1 - passkeys for authentication

Note: For the use of passkeys, I'm focusing mostly on the possibilities of use within Microsoft Entra ID, which are currently being introduced. However, this article is general, focusing more on theory, and describes passkeys according to official documentation and standards. The next part will focus on practical use, for example within Google.

Introduction to replacing passwords with passkeys

Official information can be found on the FIDO Alliance website in the Passkeys 101 - What is FIDO section, primarily Passkeys (Passkey Authentication). Details are in the FIDO2 specification, which has two parts CTAP and Webauthn. The FIDO Alliance designed a wide range of user authentication options, but manufacturers (or platforms) may only support a certain part. An example is Microsoft's support for security keys, which has been here for some time.

A general description can also be found at Microsoft in the article What Is FIDO2?. More detailed (also for developers) at Google Passwordless login with passkeys or W3C and FIDO Alliance passkeys.dev.

Dangerous passwords

The fact that passwords are not secure enough is probably understood by everyone today. A password is a shared secret that both parties must know. There is a risk of it being stolen (from the user or server) or revealed (password attacks). During authentication, it is transmitted over the network, where it can be intercepted. Attackers are increasingly using phishing to lure out passwords (or verify users). We should use a different password for each service, and it should be strong (complex). This places great demands on users. Even long-promoted regular password changes are not a solution.

As a defense, multi-factor authentication (MFA) began to be used. Common MFA methods work with a verification code (SMS or OATH) or approval of login, where we must own a specific device. But attackers manage to bypass even this security (in some cases). Using phishing, they lure the verification code or login approval from the user on a fake page and log in to the target service themselves.

Today's solution is to replace passwords with passkeys or generally phishing-resistant passwordless login. For users, this method is presented as logging in simply using facial recognition (Facial recognition / Face ID) or fingerprint comparison (Fingerprint / Touch ID). This is of course technically very inaccurate, but it may seem so to users.

I provided a lot of general information about authentication methods in the article Multi-Factor Authentication (MFA) in Microsoft Entra ID.

Passkeys vs FIDO2 (security key)

Recently, I focused on Sign-in with FIDO2 security key (mainly from a practical perspective, in this article we will discuss more about the principles of operation). FIDO2 is an open standard for user authentication from 2019. It was most often talked about earlier in connection with a security key, i.e., FIDO2 security key. Probably in 2022, a new term passkeys appeared, but a lot of attention has been paid to it only in recent months (in my opinion). Even the FIDO Alliance pages have been changed, we no longer find a link to the article about FIDO2 (the page still exists) and the main term is passkeys.

Both FIDO2 and passkeys talk about FIDO Authentication, abbreviated as FIDO (Fast IDentity Online). Which is a global authentication standard based on Public Key Cryptography. In simple terms, I would say that passkeys is a term for a pair of cryptographic keys, a more accurate term would be FIDO2 sign-in credentials, because they also contain other information (attributes). So overall, we correctly talk about FIDO Authentication with passkeys.

On the FIDO Alliance website, only the term FIDO is used. Passkeys are more precisely based on the set of FIDO2 specifications, which has two components. The W3C (World Wide Web Consortium) standard Web Authentication - WebAuthn and the complementary FIDO Alliance protocol Client to Authenticator Protocol 2 - CTAP2. WebAuthn is an API implemented in web browsers and platforms, so registered devices can perform FIDO2 verification. CTAP2 allows external authenticators (like a Security Key) to communicate with browsers and platforms for authentication. Currently, we have CTAP 2.1, CTAP 2.2 is in draft, and WebAuthn Level 2, WebAuthn Level 3 is in draft.

A FIDO2 security key is an external (roaming) authenticator, cryptographic hardware that performs FIDO authentication using passkeys. Microsoft has previously implemented the ability to log in using a FIDO2 security key. When talking about passkeys today, the use of other authenticators is considered. It can be a mobile phone, where the features of the operating system and hardware are used. Or directly the computer from which we are logging in, and its hardware (for example, Windows Hello with a TPM chip).

Later I read that Windows Hello is also FIDO2 certified (from Windows 10 1903). So it's an internal (platform) authenticator. Therefore, Windows Hello for Business also supports FIDO authentication using passkeys. If we want to create a passkey on a Windows device, Windows Hello is used (and required).

A Passkey can be tied to one device (like a FIDO2 security key, but also a mobile phone or computer) or synchronized between multiple devices through a cloud service.

Entra ID and phishing-resistant MFA methods

Microsoft Entra ID supports several Passwordless MFA methods that are Phishing resistant. They all use an asymmetric pair of private and public keys and are tied to a specific device. In principle, they are similar.

These include Windows Hello for Business (computer TPM chip), Certificate-based authentication (smartcard or computer storage) and FIDO2 security key (HW key). Currently, Microsoft is adjusting the support for FIDO2 security key, which will expand to more general device-bound passkeys.

Among the passwordless MFA methods is also Phone sign-in using the Microsoft Authenticator app, but it's not among those resistant to phishing.

What are passkeys and how do they work

In the introductory chapter, we provided a comparison of passkeys and FIDO2 security key. Ideally for those who are familiar with security keys. There is also a certain description there. Now let's describe it in more detail.

Passkeys

Passkeys are a replacement for passwords with a more secure option of passwordless authentication using multi-factor authentication (MFA). We can say that it's a simpler and faster login option that is also phishing resistant.

Passkeys are always strong (we can set a weak password) and no shared secret (password or key known to both parties) is used during login. An asymmetric pair of private and public cryptographic keys is used. It's a transition from credentials based on knowledge to those based on ownership.

They are created uniquely for each online service (the term Relying Party [RP] is used) or application to which we want to log in. It is directly tied to the service domain (RP ID) and cannot be used with another.

The word passkey, is a common term that should be used similarly to the word password. It should be written with a lowercase letter. Passkeys are FIDO credentials conforming to the FIDO2 standard (WebAuthn and CTAP2).

Passkeys are being developed within the FIDO Alliance, which brings together many large companies. They are based on FIDO standards. Support for passkeys was announced by the biggest players Google, Microsoft, and Apple in 2022. So it's built directly into the main mobile and desktop operating systems (Windows, macOS, iOS, Android) and web browsers.

Microsoft has supported them since Windows 10 1903 (in Windows 11 22H2 with KB5030310, support for management was added). Apple since macOS Ventura (13) and iOS 16. Google since Android 9. All common web browsers have supported FIDO login (the WebAuthn protocol) for a long time.

Principle of passkeys operation

There are two different operations

• registering a passkey with an online service
• using a passkey for login

When a user registers with an online service (supporting FIDO2), they first select a supported FIDO verification method. Then they must activate (unlock) the FIDO authenticator, for example using a PIN or fingerprint. The client device (authenticator) generates a key pair that only works for the given website or application. The private key is securely stored on the end user's device, which can be a computer, phone, or security key. Access is protected by biometrics or a PIN. The public key, along with the generated Credential ID, is encrypted and shared with the service. The service stores it on its authentication server.

During login, the service generates a unique cryptographic challenge, which it sends to the client. The user must unlock access to the private key. The client device signs the challenge using the private key and sends it back to the service. The service verifies the signature and data using the registered public key, thereby authenticating (logging in) the user.

FIDO authenticators

An authenticator is a software component or piece of hardware owned by the user that is capable of performing FIDO authentication. Authenticators are used to verify ownership and confirm the user's identity. They are responsible for generating key pairs during registration and protecting the private key.

• Roaming authenticator (external) - portable HW device separate from the client device, an example is a mobile phone or security key, connects to the client device via USB, BLE or NFC, allows users to carry their credentials with them and use them to authenticate on multiple devices, also called a cross-platform authenticator
• Platform authenticator (internal) - is built into the client device, such as a computer or phone, includes biometric features and hardware chips (like TPM), for example Windows Hello, Android Fingerprint or Apple Touch ID

The authenticator stores the private key and thus the passkeys are tied to a specific device. It can be a computer, where we can only log in on it. Or a security key or phone, which we can use to log in on various computers.

Cross-Device Authentication

Cross-device authentication allows the use of a passkey from one device to log in on another device. The CTAP protocol is used for communication between the authenticator and the client platform (the client uses WebAuthn with the service).

Web browsers today standardly support the use of Sign-in with nearby Device. In this case, the passkey is on a nearby device (Roaming authenticator), typically a mobile phone or security key. The mobile phone must be connected to the computer, most often Bluetooth Low Energy (BLE) is used to verify physical proximity. A security key is connected to the USB port.

Synced passkeys vs. Device-bound passkeys

Passkeys can be synchronized between user devices using a cloud service. Then they are referred to as Multi-device passkeys or Synced passkeys. Or they can be bound to the device from which they cannot be copied. We refer to these as Single-device passkeys or Device-bound passkeys.

I think the technical difference is that Device-bound passkeys have the private key stored in a way that it cannot be copied (obtained). Ideally in some cryptographic HW (cryptoprocessor), such as TPM, Smart card or Security Key. Only cryptographic operations are called, which the HW performs using the private key.

The FIDO Alliance is trying to convince users to replace passwords with a more secure method. A great advantage of passwords is that we can use them anywhere (from any device). Therefore, the alliance proposed the possibility to synchronize passkeys between devices to overcome users' reluctance in this regard.

The alliance tries to argue that it is still sufficiently secure (synchronization providers must have strong account security protection, communication is encrypted, etc.). We store synchronized passkeys (typically) according to the platform with our Apple account (iCloud Keychain), Google (Google Password Manager) or Microsoft (Microsoft account). Nevertheless, Microsoft decided to support only Device-bound passkeys for Entra ID.

Personally, I think that using specialized cryptographic HW (such as a smart card or security key) to store the private key provides higher security. Than when it is stored in the operating system (on a mobile phone or computer). There, Trusted Platform Module (TPM), Trusted Execution Environment (TEE) or Secure Element (SE) should probably be used. With the possibility of synchronization, when the private key gets outside our device, security is further reduced. However, it's better than using a password. It's necessary to look for a compromise for certain situations between security and simplicity and availability.

Discoverable credentials

Passkeys can replace not only the password but also the username during login. The user doesn't have to enter anything when logging in. It's enough to choose the corresponding login method (FIDO passkey / security key) and select an account from the list of passkeys. FIDO Credentials contain various attributes such as cryptographic algorithm, username, and service domain.

Two-step verification may be required, where the user must know their ID (enter a username) and keys are searched based on it. Credentials that can be found without knowing the ID are called Discoverable credentials (previously referred to as resident key). Login credentials must be created as Discoverable credentials already during registration.

What is the strength (category) of passkeys authentication

Multi-Factor Authentication

Authentication using passkeys meets the basic principle of multi-factor security (MFA). Keys are stored on a device (something the user has) and biometrics (something the user is) or a PIN (something the user knows) must be used to use them. It's important that an attacker cannot obtain the private key from the user's platform (for example using a stolen password, then they would need only one factor to log in).

Passwordless Authentication

Logging in using passkeys is referred to as passwordless login because we don't use a password to log in to the application or website. So no form of password is transmitted over the network. Instead, a private key is used and it signs data that is sent to the service. So even the key is not transmitted over the network.

Access to the key on the device is protected using the same biometrics, PIN, or password that the user uses to unlock it (log in). The user approves logging into the application or website using the given method. Biometric information or PIN/password is used only locally on the device and is not sent to the target server.

In many cases, we can use a PIN to access the key. To the user, it may seem like they are logging in with a PIN, which is essentially a password. The meaning of passwordless login is that this PIN (password) is not used for verification with the target service. If an attacker obtained the PIN, they couldn't use it to log in, they would also have to obtain the device.

Phishing resistant login

A private key is used for login, but the user doesn't work with it directly and in most cases doesn't even have access to it. So it's not possible for an attacker to lure it from the user, as can happen with a password (by displaying a fake dialog where the user enters it).

The second thing is that logging in using passkeys can only be done on the device where the keys are stored. Or on another device in physical proximity (Roaming authenticator). We also need to unlock access to the authenticator. If we use login approval on a mobile phone (Phone sign-in) for MFA, we can approve an attacker's login somewhere on the internet (which they fraudulently lured from us).

Protection against MITM (Man-in-the-middle attack)

All documents about passkeys emphasize that they are resistant to phishing. In some places, it's also stated that they are resistant to man-in-the-middle attacks (MITM). This information is directly in the WebAuthn specification. It's harder to find details on how this is achieved.

A passkey is tied to the service domain and can only be used for it. If an attacker creates a spoofed page, the URL doesn't match and the passkey is not used. It's contained in the technology, so even the user cannot bypass this feature and try to log in. The service domain (RP ID) is also sent during the verification communication.

In the authentication process, a challenge is used, which is created by the service in the first step of the credential request. It must be unique, cryptographically secure (unpredictable), with limited validity. It protects users against replay attacks. The Transport Layer Security (TLS) protocol is also used, i.e., certificates and domain verification.