The trouble with Passkeys

Have you heard of passkeys yet? Probably you haven’t — they haven’t been around for very long. But if you care about authentication, security, or are in any way involved with identifying users for an app or website, perhaps you should.

To make it very short, Passkeys are a new cross-platform standard for replacing both passwords, as well as 2FA/MFA authenticators with something more convenient and secure. And for the most part, they do deliver on that promise, and really are a worthwhile security improment. But they are not perfect for reasons I’ll outline below.

You can use passkeys today on up to date iPhones and Android phones, on MacOS and Windows, and with a number of password manager apps like 1Password, Bitwarden and Dashlane (for LastPass, the support is “coming soon”, they say). They work on sites like Google, iCloud, Adobe, GitHub, Amazon, Office 365 and many more, but certainly not yet universally.

Passkeys virtually eliminate two really important types of phishing:

1. they make it impossible for someone to steal your access key (formerly: password) by fooling you to reveal it, because it’s practically impossible for you to reveal the large, encrypted, secret number that they are.
2. they also make it impossible for someone to fool you to log in with your passkey on a fake site, no matter how convincingly designed, because it’ll be your browser determining whether the site is the same you originally authenticated with, or not.

They also make it impossible for a stolen passkey (and they can be stolen — they’re stored on your phone, for example) to be used to log in to some other site, because the passkeys system creates a different, long, encrypted secret number for every site you log in to. A passkey works only where it was created for — nowhere else. And they do this while also being more convenient — most combinations of password manager apps and sites supporting passkeys make log-in automatic or a matter of just clicking one button. No entering usernames or emails, no typing in or copy-pasting passwords!

So that’s all great. If you want to learn more about how they work, EFF has published a pretty good two-part primer, where part 1 talks more about the problems passkeys solve, and part 2 explains how you would go about using them.

But what about the problems, then? Let’s review few of the new problems with Passkeys — or more specifically, problems with the ways they’ve been implemented, so far.

Vendors do love vendor locks

First of all, Passkeys create a new vendor lock. It’s really difficult, in many cases entirely impossible to migrate a passkey from one secure wallet to another. This is partially by design, as such functionality would also open a risk of large scale passkeys theft. For example, if you start using Passkeys by allowing your iPhone to create them for you when you log in to a site, the iPhone will store the passkey to iCloud Keychain, making it also available to you on your other i-devices and your Mac, if you have them — but you can’t have the passkey on your Windows machine or Android phone. Nor is it much different if you allow your Android phone to create them — they’ll be stored by Google Password Manager, but good luck getting them out of that sandbox. I understand if you let Windows Hello create your passkeys, they won’t sync even to another Windows machine! So don’t do that.

To work around this, you can add several passkeys to a site which supports them. The problem is, it’s also very difficult to review exactly where you have a passkey today, so let’s say you wanted to switch from iPhone to Android, or vice versa: on the Mac, you can review all your stored passkeys and passwords, one by one, in System Settings / Passwords list. You can’t list only the sites where you have a passkey, so that’s a lot to browse through. Again, this isn’t much different if you were to try to move from Android to iPhone: it’s a lot of work to figure out what sites your old device is going to be the only tool to log in to.

I doubt this lack of cross-platform support is entirely accidental. Vendors do love vendor locks, after all!

You can mitigate this problem by not accepting to use passkeys from the platform, and instead replacing them with ones created by a cross-platform password manager of your choice, like 1Password, Bitwarden or Dashlane, which I mentioned before. You’ll be locked in with those too, but at least it’ll be an app you can use anywhere. And at least with Dashlane, which I use, there’s a separate tab in the app which lists sites you have a passkey to, and nothing else, so that’ll help a bit in a migration — though to actually log in to each one to replace or add another passkey on them will be a lot of work.

It’ll be a long while before passkeys are understood by security policies

Second, and this is more of a corporate policy problem: it’ll be a long while before passkeys are understood by security policies. And that will slow adoption for a long while.

• Are passkeys equivalent to a password secured account for IT support?
  No, they’re better, not the same. For reasons apparent above, losing a passkey is different to losing a password. Support teams need to be retrained, and “reset your passkey” is not at all the same as “reset your password”.
• Are passkeys equivalent to 2FA authentication?
  Sort of, but no. The iPhone, Android and password manager implementations, for example, make passkeys into a combination of something you have (device) and something you are (biometric), but they entirely (and by intent) eliminate something you know. At the same time, though, for the service authenticating you, a passkey is just one factor — so most policies mandating 2FA today would not recognize that a single passkey is sufficient.
  You might see, for example, that a policy demands both a Passkey and one-time-password, which practically will be managed and provided by the same end-user app (again, most password managers support both). A TOTP will not add any additional security, but, hey..
• Where are the passkeys stored?
  If staff are using their personal phones, that makes a corporate strong authentication secret something that is managed by that device, and quite possibly copied to their personal cloud wallets by the operating system (iOS iCloud Keychain or Android/Google Password Manager). This should not be an issue, because the corporate site can reject any specific passkey just as easily as they can invalidate a password, but that’s not in the policies today.
• How should people manage personal passkeys?
  If the policy requires staff to use a corporate-provided password manager app, that’s slightly better for the corporate policy, but can become a major headache for the employee. Did you save that personal Facebook authentication passkey to the corporate wallet you just lost without warning in a layoff? Oops. You may be very much out of luck.
• Does the corporate authentication platform even support passkeys?
  Many of them do, because for this standard, the rollout was beautifully synchronized and a large number of platforms have rolled out their support for passkeys in the last few months. But that information has not propagated to most client organizations, I’m sure.

Security is complicated and often a matter of trade-offs. Authentication has been based on the very weak system of passwords for a very, very long time (over 50 years!). It will be a while still before we get this figured out. In the meantime, be aware of what path you take.