Thomas Cannon

“Okay, but what about THIS failure scenario with passkeys?”

“Okay, but what about THIS failure scenario with passkeys?”

Important caveat: I’m not a security researcher, I’ve just read a lot about passkeys & thought about their implementation. I’ve been trying to collect findings from actual security researchers; if you know of any discussions related to this, please send them my way!

When talking about passkeys, I’ve gotten the same set of questions, poking at the edge cases of them. Which is good! Skepticism is always good; especially with new authentication techniques. But I wanted to answer some of these FAQs in a centralized location to save having to repeat myself a bunch.

“What about if my computer/phone breaks?”

If you’re in the vast majority of users, you’ll likely have your passkeys stored in a distributed credential manager; like iCloud keychain, Bitwarden, 1Password, Google’s saved credentials, etc.

Apple has a really great breakdown of the security measures for iCloud keychain, including the security of recovering access:

In short: as long as you’re still able to access your credential manager, and it syncs online, you’re good. 💪

“What if I don’t want to rely on an online service?”

A good question! I always recommend that folks use a hardware security key (such as a Yubico) for their essential accounts, and keep it in a safe place. The analogy I use is: “treat it like your passport, birth certificate, or other essential documents.”

This will allow you to make sure you can access your most essential services, even if there is a SNAFU and your credential manager is no longer accessible.

“Okay, but what if I really lose access to everything? My backup hardware key, my iCloud/Google/1Password account, everything”

This is also a good question; and needs to be addressed. What we’re talking about here is not passkey specific, it’s a general question of “how does account recovery work?” So the questions being asked are the same ones we ask about our current password-based authentication flows.

For the vast majority of services, a familiar email-based recovery process makes sense:

  1. You request an emergency passkey registration for your account
  2. You’re emailed a token that can only be used once, and expires
  3. You use that token to register a new passkey (likely on a new credential manager/hardware key)
  4. You’re logged in!

And if you’re unable to get a new security key or credential management account, this flow works so long as you’re able to access your email. You can use a browser/OS that stores credentials locally. Because of this, even though it’s not recommended, you could recover your account on a public computer (just make sure to delete the passkey when you’re finished!)

This is why it’s important to make sure your email account is as secure as possible, with multiple avenues for recovery. Your email is your identity card online; for better or worse.

This one is tough to tease out a bit, because:

“What about accounts I share access for, like utility accounts?”

Good passkey implementations allow you to register multiple passkeys. This is for a number of reasons, including this one!

  • You can save passkeys for devices on different ecosystems, to reduce the headache of working across platforms. For example: if there’s a service I access on my windows gaming PC, I can create a passkey specifically for that windows machine to avoid the hassle of having to use my phone + Bluetooth to log in every time.
  • Ecosystems can allow you to share a passkey, such as Apple allowing you to AirDrop a passkey to a nearby contact
  • This reason, so your partner/family member can access this joint account independently

“What if I need to remove someone with a passkey from the account?”

Good passkey implementations allow you to remove previously registered passkeys after verifiying that you can access a different passkey (to avoid deleting the passkey you currently have access to!). This is no different than someone using a shared password to change the password on an account; but it is less disruptive.