The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.

- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.

- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.

- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.

Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication

The big problem is that most passkey providers do not support actually giving users their passkeys.

As the article stated: "I want you to remember this quote and it's implications. Users should be able to use any device they choose without penalty."

As you've pointed out:

>> Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.

and again:

>> Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up.

How can I get my passkeys and back them up on my own storage media? (e.g. USB drive, encrypted cloud storage, burn to a disc, etc.)

How can I import passkeys generated elsewhere?

If you cannot backup or import the passkeys, then you do not control them. They are not your passkeys--they belong to Google or Apple, etc.

And as the article states, in most cases these passkey providers do a piss poor job of managing their passkeys that they claim belong to you.

Agreed, they unfortunately seem to have gone the vendor lock-in route. The big players don't have export utilities for passkeys, despite it being technically feasible and pretty straightforward to implement. That's a pretty major gap in the spec, there should be a standard export/import format, and vendors should be required to implement it in order to be compliant.

It's probably possible to extract passkeys from a rooted Android device, but it would definitely be out of the grasp of 99% of users. I have not looked into it in detail, but I'd expect a Frida script hooking the keystore decryption function would get the raw data, then it would be a question of interpreting whatever proprietary format Google is using for their password manager.

This has always been my objection to them, as a user, as they have been presented. As an employee, I don't care. Businesses have sufficient relationships and mechanisms to self-serve any issues that come up, like lost keys. But as a user, I do not. It is a drop-dead requirement for me for any authentication material that I have some way of backing it up and modifying it in case of compromise.

Besides, give the Silicon Valley venture capitalists and Harvard MBA bros a whiff of the possibility of full control over something as important as your primary authentication material and before you can whisper Richard Stallman they're out having a happy Bacchanalia toasting the name of Portunus [1], whom I will now resurrect out of our ancient past to name him the God of Platform Lockin, and us users aren't going to get a word in edgewise over the debauchery and slides projecting Total Addressable Markets.

Fortunately it seems they all got a little too drunk with power this time, but honestly it's only a matter of time before they arrange another Portunus summoning lock-in party again. This target is irresistible and the annoyance people have with passwords is too good an angle to pass up.

[1]: https://en.wikipedia.org/wiki/Portunus_(mythology) And yes, I am aware of the stream-crossing between Bacchus and another god here. But who knows what a Portunalia even is any more?

I'm not quite sure if even the corporate case works properly with iOS & Android devices as the article states, otherwise you could become a 'corporation of one' and side step all of this stuff. Even the corporations look like they have to use apple or google's crap for employee devices and accounts?

I mean in principle. If I throw my authentication material into a lake, there's an IT department that can have authorization to re-establish it. If I throw my personal authentication material into a lake, there's really nobody who can help me. I can try to convince a large company that I'm really me, but that is indistinguishable to them from a social engineering attempt, and dealing with that is high touch and expensive. I need to be able to back up my stuff. If the aforementioned "large company" is the one holding my authentication material and anything whatsoever bobbles it, then I'm back to trying to convince them I'm me.

A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.

When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.

> The private keys can't actually be stored in the HSM though, because you need to be able to back them up.

Every actual HSM I've ever used allows some sort of encrypted export. But actual HSMs are expensive and PKCS#11 is a terrible API so they suck to use.