This is ridiculous. These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.
Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
Fuck passkeys. You’ll have to pry my passwords from my cold dead hands. https://mastodon.online/@9to5Mac/113308029918888989
@lapcatsoftware How would you arrange it so that an attacker who'd compromised your system couldn't just export your passkeys and exfiltrate the exported form, leaving them fatally compromised with no indication to you that anything was wrong?
@tarheel
It's phishable. U2f and passkeys authenticate the site before they'll log the user in. U2F and hardware tokens are a much better answer than trying to build it into the OS, but adoption has been hard. Allowing sealed export to a hardware token would at least help the lock-in problem, though.
@tknarr @lapcatsoftware
@dymaxion @tarheel @tknarr @lapcatsoftware
How would whatever is doing the exporting decide which things that present themselves as hardware tokens to trust (iow, what would it want to know about a keypair before it encrypts the export to it)? I can either see a version where it trusts any keypair provided by the user (and is imo equivalent to just straight up export) or one where it wants some sort of attestation chain that a trusted manufacturer promises that this is really a hardware token, which then creates a potential for lock in. Do you see some other option?
@robryk
Possibly user designation of a device to be trusted for export within uefi so the tpm is in the loop, but we're well back into adoption problems territory there. Some kind of attestation compromise might be possible — a baked in list and the option to extend it in uefi. It's a hard problem though, for all that I'm not sure I think passkeys were the right place in the trade-off space.
@tarheel @tknarr @lapcatsoftware
@dymaxion @tarheel @tknarr @lapcatsoftware
So you're proposing something similar to secure boot root key changing? I wonder why that mechanism (albeit with some woes) is mostly workable on PCs, but there is basically nothing similar on mobile phones (I don't think you can lock an Android bootloader with different software signature verification keys, can you?)?
@robryk @dymaxion @tarheel @lapcatsoftware That's because the phone makers don't want you to be able to change the key. That'd give you control over the phone hardware, and their entire security model is based on the fact that you _can't_ control the hardware.
@robryk
Yeah. I mean, I'm spitballing here. But the real answer is going back to the security key model where they're actually second factors and you can have more than one
@tarheel @tknarr @lapcatsoftware