Passkeys are everywhere right now. But Why should I care? My password is secure!

In this post I try to cover how we got into to today’s mess of authentication methods and why passkeys are a good option going forward.

How did we get here?

The first computer password allegedly ¹ dates back to the MIT Compatible Time-Sharing System (CTSS), with multiple terminals that where not user-specific but with each user having an individual set of user-owned files. At the time it seemed like a straight forward idea. Yesterday’s solutions like security questions about your mothers maiden name where also considered but discarded due to higher resource usage for something so unimportant like authentication.

Interestingly for us, the system was also a target of the first password theft. Using punch cards users could request to print specific files offline. Allan Scherr, a Ph.D. researcher at MIT at the time, requested a print-out of the file containing all passwords. The next day he found a printout containing all the systems-passwords.

This illustrates two security issues:

1. If there is a path for actions to be taken with weaker or no authentication it can bypass the resilient authentication flow. This is still the case with passkeys. If you log in using an alternative login method that bypasses the secure path the best authentication method does not protect you. Recent articles about “hacked” passkeys used alternative login methods (e.g. smart TV specific login flows) ² Implementors need to look at the authentication flow holistically instead of adding another option. The weakest link will still break, if you put a strong one next to it.
2. If you have access to the password database, all passwords are compromised. This is true for all shared secrets and still applies today to the concept of passwords. While it is best practice to hash and salt the stored passwords and the plain-text is not written to disk, the hash and salt combination enables an offline attack using word lists or sheer brute force to try to find a match for the given hash. Bypassing every rate limit. Once found, the password can be used to authenticate against other systems as well, if the user reused the password. This concept is known as credential stuffing.

The MFA Pitfall

We now know that passwords are shared secret that can lead to credential stuffing attacks because of password reuse. The underlying psychological issue goes a lot deeper than that. As everyone who interacts with computers from time to time knows: A user can set their own password.

The main security of passwords from the user perspective hinges on only a few things:

1. The password should be complex

   Passwords should ideally contain a random selection of characters from a large alphabet (e.g. numbers, letters, special characters,…) and should have a sufficient length. The result is a password that’s hard to brute force but also hard to remember for most humans.

2. The password should be stored securely

   The complexity makes the password hard to remember. The result is that a lot of people write their passwords down. The classic example how this could be a problem is a post-it note on the monitor or under the keyboard containing the password. Writing passwords down in itself isn’t an issue when stored securely. Only in shared spaces or when others can access it, the behavior turns into an issue, essentially being the same thing as a key under a rock next to a locked house door. This leads to many users logging in via the password reset flow, bypassing the password authentication flow. This is more or less the same as a magic link with extra steps. In a lot of scenarios the support staff can be convinced to change the associated e-mail address via phone, leading to the password reset e-mails being sent to the attacker.

3. The password should only be entered on the correct site

   Phishing is one of the oldest and most effective entries into organizations and user-accounts in general. Scientific studies indicate that awareness campaigns are not an effective solution to the problem. ³ The main issue is that once an attacker convinces the user that the site where they try to log in is the legitimate one the user is very likely to enter their credentials. With minor typos and look-alike, punycode, domains it is error-prone for users to differentiate correct from malicious domains. As an example jrtberlin.de and jrtbеrlin.de are almost indistinguishable from each other depending on the font. The second one contains the Cyrillic small letter е instead of the Latin e.

   This issue is further increased by a very diverse landscape of valid domains. A friend of mine (@ljrk@todon.eu) made a point in a class by having students decide which of the listed domains is an official Microsoft owned domain. ⁴

   Some examples like sharepont.online.com, office.m365.com and sharepointonline.com sound plausible, while legitimate ones can sound phishy as well like microsoftrewards.com.

4. The password should be unique

   People are bad at this because of all the before mentioned points. A lot of people pick the easy route and just use their password for everything where it complies with the password policy.

All in all: The password as a concept fails Saltzer’s and Schroeder’s design principle of psychological acceptability, if the password is good. ^{5 6}

Because of the before mentioned issues with passwords compliance teams, security staff and regulatory rules often require a second factor (2FA), often referred to as multi-factor-authentication (MFA). MFA methods are an add-on to a flawed authentication method, complicating the authentication process, while not resolving most issues. When an attacker convinces the user to trust that the phishing site is the real one and the user enters their password, there is no reason not to enter the time-based one time password (TOTP), match the displayed Number or press authenticate within the app.

Most phishing frameworks have built-in support for relaying second factors in real time.⁷ The second factor usually tries to resolve one issue: credential stuffing, because it makes the secret the user uses to authenticate unique. Through its addition of a truly unique and machine-generated challenge-code, it renders the combined secret the user uses to authenticate as effectively unique. This makes the requirement of MFA so popular, since it’s hard to enforce a unique-password-policy through technological means, unlike enforcing MFA.

📝 Note

If you already have unique passwords, TOTP and similar only add negligible additional security. Further, storing them in the password-manager alongside the password reduces the security only by a negligible amount, if the individual is not targeted directly by adversaries, since credential stuffing is forfeited in this case as well – phishing with TOTP replay works independently of the TOTP’s storage location.

In reality attackers employ a social engineering technique where they try to log in using the credentials, generating authentication request notifications for the user. If the user doesn’t approve the login, the attacker will continue to spam the user with new authentication requests. Annoyance can result in a user approving the action in hope to end the spam or pressing approve on accident. This psychological weakness is known as mfa fatigue.

One MFA-method that increases in popularity that tries to resolve this issue is the magic link: When the user authenticates, they get an e-mail containing a link. Opening the link logs the user in. This method has a few issues but can, when used correctly, offer some phishing protections. One typical issue with this method is in the implementation. It is important that the link does not authenticate a remote session and only authenticates the user on the device where the link is clicked. Otherwise, an attacker would get authenticated when a user clicks the received link and the phishing site tells the user to check their e-mails. A lot of sites in recent years have adopted this method or even replaced passwords entirely with this method. While being an improvement in terms of security, this method has some issues as well:

• The UX breaks when a user authenticates on a desktop system and clicks the link on their phone, because now the mobile browser is authenticated instead of the one on the larger screen.
• The risk of credential phishing is reduced but not removed: The magic link can still be copied into a field controlled by the attacker, but this flow breaks the typical authentication flow expected by the user and will probably reduce the phishing success rate quite a lot.
• Sometimes e-mails will be delivered after the active time frame of the link or not at all. This can lead to a lot of frustration on the users side.
• The security now hinges on the e-mail account. Depending on the mail provider this can be a security improvement or a reduction. Considering password reset flows this was probably the case anyway.

The result of most MFA methods is a complex authentication flow that annoys users and decreases acceptance of the authentication. This complexity can also lead to weaker passwords, because users think that MFA will protect them.

Password Managers

In addition to MFA, password managers are often an argument why the password is still a good option. Password managers are a concept that tries to solve a lot of the issues like having to remember the password, not writing it down in plain-text and built-in generators for complex passwords that additionally comply with a sites’ password policy. In reality only 36% of Americans use a password manager⁸ and the amount of people using password generators is likely even lower. In addition, 23% of surveyed users by Forbes reported using the same password for 3-4 different accounts⁹.

Glimpsing at risk management (ISO 27001) we can apply one of four different strategies to the identified issues: accept, transfer, reduce, avoid. From a technical perspective we mostly care about reducing the risks, or to avoid the risk by designing a system that inherently does not result in the identified risks.

Password managers are unable to avoid most issues because it requires the user to either use the software in a correct way for example using the built-in password generator or using autofill to ensure the correct site is used.

Autofill is a good idea in theory as well, that tries to detect login fields and entering credentials specific to the site. If the autofill feature is working as intended, it only autofills the credentials on the legitimate site which the credentials belong to. With a lot of websites trying to differentiate themselves by implementing custom design elements or using non-standard components, password managers sometimes are unable to identify the correct login-form elements, resulting in the user having to copy & paste the username and password, even worse: some sites prohibit pasting into the password field.

This brittleness trains users to be comfortable to manually enter credentials on a site. This results in phishing sites being able to convince users to enter their passwords despite the user having autofill enabled. A standardized API for registering and logging in is therefore an important part of passkeys.

One thing that password managers do particularly well is remembering the passwords. This is one of the main risks that the password manager solves and that’s why some passkeys are still stored within a password manager.

How do passkeys deal with these issues?

Passkeys assume that the issues in authentication systems aren’t psychological issues, but technical ones that can be avoided or reduced by an authentication scheme that considers human limitations. Increased technical complexity is accepted if it reduces the complexity from a users’ perspective.

Passkeys address the shared secret issue by leveraging a so called challenge-response method using public-key cryptography.

📝 Note

Public-key cryptography (asymmetric cryptography) relies on a mathematically linked key pair: a public key and a private key. While the public key is shared openly and linked to your identity, the private key remains strictly secret. For passkeys, the central concept is the digital signature: The private key is used to perform a mathematical operation on a message to generate a unique cryptographic proof. Anyone else can then use the corresponding public key to verify this proof. If the verification succeeds, it proves that the signature was created by the holder of the private key – without ever exposing the secret key itself.

Passkeys use this technique to sign challenges from the site with the private key and proving to the site that the user who signed the message is in possession of the private key and therefore likely the legitimate user.

This results for example in the fact that if a website gets breached the attacker does not gain your secret required to log in and the site does not need to rotate all secrets because the website does not store the users confidential private-key.

---
title: Passkey Key Storage
---
flowchart LR
    PW(Passkey Generation) -->|Public Key| Server[("Website
    (relying party)")]
    PW  -->|Private Key| Authenticator[("Authenticator
    (e.g. User owned device)")]

Let’s compare the password requirements above with how passkeys solve the issue or absolve of the need entirely:

1. The password should be complex

   Passkeys are always based on a private key that is not picked by the user and instead generated.

2. The password should be stored securely

   Passkeys are created, stored and updated by the password manager, operating system keychain or a physical device.

3. The password should only be entered on the correct site

   Passkeys are only valid for the relying-party id (rp.id: Passkey lingo for the domain name or an application) that they are created for. An attacker controlled site can not request an authentication for a different domain.

4. The password should be unique

   A relying-party (e.g. a website) can have multiple passkeys, but a passkey can not be shared between sites.

In practice a user is prompted by the operating system or browser to choose an identity provided by a credential manager, like a password manager or a hardware backed credential:

A more technical explanation of the passkey building blocks and how they work together can be found in the appendix below.

FAQ

What is a passkey?

A passkey is a marketing term for a FIDO2 resident-key credential with user-verification.

Are passkeys an authentication vendor-lockin?

In short: No, passkeys are an open standard.

In the past companies like, Google, Apple, Facebook, … tried to tie authentication of third-party services to themselves using “Sign in with …” login-options. Passkeys are a universal standard. And with the Credential Exchange Specification (CX)¹¹ there is a common solution to export credentials to different providers. That being said relying parties can restrict the choice of the authenticator in a few ways:

• restrict to a specific authenticator using the AAGID ¹²: useful in an organization to restrict the authenticator to the one given out by the IT department or to ones that comply with a specific certification
• restrict to device-bound passkeys (exclude software based, syncable passkeys e.g. password managers instead of TPM or USB Token backed passkeys)

One negative example how this can be used for consumers outside of organizations is apples restriction to iOS devices and only allowing FIDO2 USB tokens as a second factor for the password login-flow.

Can I still use my hardware token?

Yes, FIDO2 USB tokens that support resident keys are and will be supported going forward. It is just not required for a user to own a security token to participate in the FIDO ecosystem anymore. For most people software based passkeys are an overall improvement in user experience and security. People with different threat-models should keep using FIDO2 USB tokens or at least hardware-backed credentials that are non-transferable and protected by a strong PIN.

Should I use a hardware token?

It depends, we need to differentiate between at-risk users like public figures and privileged users and regular users that typically don’t get targeted specifically.

A hardware token is a form of a device-bound passkey, a roaming authenticator because it is device-bound but can roam between different platforms. A secure enclave for example is a platfrom authenticator because it is built-in to a platform.

Since hardware keys require more effort to be used, it can be helpful to protect the password manager with a physical token and put other passkeys within the password manager.

Lack of universal platform support

This was and is indeed one of the pain points that slowly gets addressed. Current versions of Android, iOS, macOS, Windows and ChromeOS support FIDO2.

Desktop Linux is lacking behind quite a bit, supporting USB security tokens and Bluetooth authenticators (via some Chromium based browsers) and password manager support via browser extensions. The universal backend on the operating system level with an option to store passkeys on device using the TPM2 is work in progress. See the linux-credentials project ¹³

Passkeys are not shareable

The shared Netflix-Password is ubiquitous, and it is a common misconception that passkeys prevent shared accounts.

Most sites allow the registration of multiple passkeys and some password managers, like Apple Passwords, allow temporary sharing of passkeys. A roaming authenticator, for example a YubiKey, can be handed over like a pair of keys.

Passkeys enable big tech to get your biometrics

No, biometrics are used to locally unlock the authenticator, similar to a PIN on a SIM used in your phone. Biometrics are an optional feature, that falls back to device credentials like the device PIN or password.

Additionally, biometrics can improve security in some contexts and threat models: For example when unlocking a phone or signing in on public transport shoulder surfing is often used to see the PIN code to remove the activation lock of the phone after stealing it. Using biometrics can reduce the likeliness of getting the phone stolen in public.

Law enforcement in some jurisdictions is allowed to force you to unlock the phone using your fingerprint but not you to tell them your password. So depending on your personal threat model you might want to make a conscious decision whether to use biometrics. (Relevant aspect here is that Android¹⁴ and iOS¹⁵ have a quick way to disable biometrics)

Passkeys complicate digital inheritance and account recovery after death

If passwords are handled appropriately the issue is more or less identical. Passkeys for most users are stored within their password manager that is unlocked with the device credentials. Device credentials on commercial devices usually have an unlock option via the cloud service. In some countries cloud services and device manufacturers need to give access to the account or device when a death certificate is presented by close family members.

Additionally, a few sites allow managing your digital inheritance, like Google.¹⁶

Appendix

What are the passkey building blocks?

So what are passkeys made of? To understand how passkeys work on a basic level we can investigate the following diagram:

---
title: Passkey Building Blocks
---
flowchart LR
	Authenticator("
	Authenticator
Credential Storage
(e.g. USB token, password manager,...)") <-->|CTAP2| Client("Client
Usually the browser or OS")
    Client <-->|WebAuthn| RP("Relying Party (RP)
Service to login")

There is the authenticator, that can be a secure enclave in a smartphone, a TPM2 in a laptop, a password manager or a FIDO2 USB token like a YubiKey, that stores the credential. The roaming authenticator, authenticators that are not built-in to the platform (like TPM2 or secure enclaves), communicates with the browser or operating system of the user (client) via a protocol named Client to Authenticator Protocol 2 (CTAP2). The CTAP2 protocol standardizes the integration of an external authenticator in the platform via a transport method like USB, NFC or Bluetooth. When a user tries to authenticate with a relying party, for example a website, the communication between the client and the relying party happens through a protocol called Webauthn. This process is called a ceremony.

There are two types of webauthn credentials: resident key (rk) and non-resident key (nrk). Resident key refers to the property that the private key of the webauthn credential resides on the authenticator. Non-resident keys on the other hand are ephemeral, and the private key is regenerated in a deterministic way based on the credential-id provided by the relying party. This has an impact on user experience: a non-resident key depends on the relying party providing the credential-id and the site only knows the correct ID associated with the user, when it knows who the user is. The UX effect of this is that the user has to enter a factor identifying the account, like a username or an e-mail address. This type is often used as a second factor for password based login-systems.

The resident key is a full private key stored on the authenticator, containing the relying-party and an account identifier. This can be used to authenticate the user without being required to fill-out a login form by the user. From a user experience perspective in practice this looks like the user pressing sign-in and getting prompted by the authenticator or platform to scan their finger or enter a device pin to log in. This user-verification (uv) is optional but largely a set requirement for sites that refer to it as a passkey. In addition, there is the concept of user-presence (up), which verifies that the user is in physical proximity to the authenticator. This is usually realized by the user tapping the USB Token. Biometrics like a fingerprint reader usually imply user-presence in addition to the user verification.

The built-in user verification on the client side is why passkeys are often referred to having MFA. Whether this is an actual second factor or if the concept of a second factor is useful at all from a security standpoint goes a bit too much off-rails for this post.