Don't use passkeys for encrypting user data

Source: Hacker News

Why am I writing this today?

Because I am deeply concerned about users losing their most sacred data. Over the past year or two, I’ve seen many organizations, large and small, implement passkeys (which is great, thank you!) and use the PRF (Pseudo‑Random Function) extension to derive keys to protect user data, typically to support end‑to‑end encryption (including backups). I’ve also seen a number of influential folks and organizations promote the use of PRF for encrypting data.

Primary use cases

• Encrypting message backups (including images and videos)
• End‑to‑end encryption
• Encrypting documents and other files
• Encrypting and unlocking crypto wallets
• Credential manager unlocking
• Local account sign‑in

Why is this a problem?

When you overload a credential used for authentication by also using it for encryption, the “blast radius” for losing that credential becomes immeasurably larger.

Imagine a user named Erika. She is asked to set up encrypted backups in her favorite messaging app because she doesn’t want to lose her messages and photos, especially those of loved ones who are no longer here. Erika is prompted to use her passkey to enable these backups. There is nothing in the UI that emphasizes that these backups are now tightly coupled to her passkey. Even if there were explanatory text, Erika, like most users, doesn’t typically read through every dialog box, and she can’t be expected to remember this technical detail a year from now.

A few months later, Erika decides to clean up her credential manager. She doesn’t remember why she had a specific passkey for a messaging app and deletes it.

Fast forward a year: she gets a new phone and sets up the messaging app. She isn’t prompted to use a passkey because one no longer exists in her credential manager. Instead, she uses phone‑number verification to recover her account. She is then guided through the “restore backup” flow and prompted for her passkey.

Since she no longer has it, she is informed that she cannot access her backed‑up data. Goodbye, memories.

Example images

Example: deleting a passkey in Apple Passwords

Example: deleting a passkey in Google Password Manager

Example: deleting a passkey in Bitwarden

How is a user supposed to understand that they are potentially blowing away photos of deceased relatives, an encrypted property deed, or their digital currency?

We cannot, and should not, expect users to know this.

Legitimate uses of PRF in WebAuthn

At this point, you may be asking why PRF is part of WebAuthn in the first place. There are some very legitimate and more durable uses of PRF in WebAuthn, specifically supporting credential managers and operating systems. A passkey with PRF can make unlocking your credential manager (where all of your other passkeys and credentials are stored) much faster and more secure.

Credential managers have robust mechanisms to protect your vault data with multiple methods, such as master passwords, per‑device keys, recovery keys, and social recovery keys. Losing access to a passkey used to unlock your credential manager rarely leads to complete loss of your vault data.

PRF is already implemented in WebAuthn clients and credential managers, so the cat is out of the bag.

My asks

• To the wider identity industry: please stop promoting and using passkeys to encrypt user data. I’m begging you. Let them be great, phishing‑resistant authentication credentials.

• To credential managers: please prioritize adding warnings for users when they delete a passkey with PRF (and display the RP’s info page when available – see the Relying Party Passkey Endpoints usage spec).

• To sites and services using passkeys: if you still need to use PRF knowing these concerns, please:

  • add an informational page to your support site explaining how you’re using passkeys for more than authentication;
  • list that page URL in the Well‑Known URL for Relying Party Passkey Endpoints (prfUsageDetails);
  • provide as much warning as possible up front to users when enabling it.

Thanks for reading! 🙏🏻

(and thanks to Matthew Miller for reviewing and providing feedback on this post)