It's difficult not to see the "it's for your own security" argument as a cynical lock-in ploy.

Because you can export plain-text passwords just fine, and they give you exactly the same access as a PassKey does.

> nobody wants to allow plaintext export of passkeys.

While noble, why? 1Password exports a plaintext file that has all of the credentials in plaintext already.

I guess "100% secure against phising" is incompatible with "the user can in any way access the key" because if you knew the key, in theory some super-convincing phishing site could get you to spill it.

I still think the real reason is lock-in, but I could imagine this is their official justification.

Given all of the horror stories (some real, some hypothetical) told in this thread, it seems that one of the major side effects of passkeys — if not the primary purpose — is to keep you locked into whatever you used to create your passkey. Plaintext export would ameliorate that.

Because passkeys are supposed to be a bit more secure than plaintext passwords.

Passkeys are supposed to eliminate the need for companies to store a password so we no longer have to deal with the fallout of 40 breaches a year. In order to export passkeys it has to be in plaintext at some point, even if encrypted once again into the export file. Point is, one of the huge selling points of pushing people to use passkeys is the portability and lack of vendor lock in yet here we are with choices that are all currently vendor lock in.

Computer security is generally defined as Confidentiality, Integrity and Availability.

Not “or”. Passcodes don’t provide availability, so they are not providing security.

This is undergrad-level stuff.

This sounds a bit like "a turned off computer is the only secure computer"

Because in this brave new world you aren't supposed to own your keys, some proprietary HSM inside your device does.

And what a surprise that is, the one feature necessary to ensure vendor lock in doesn't happen was at 0 priority before they rolled it out.

The whole point is vendor lock-in.

How does that work if you can register multiple different keys using different devices from different vendors on an account?

Edit: I took the last sentence out, it was childish on my part.

Can you, though? passkeys.io does not showcase this. The default assumption from every vendor is that you'll use their passkeys and they don't care about anything else. It's a very explicit silence, no "official" resource from any major vendor addresses cross-platform portability.

Yes, some individual implementers recognize the issue and have "log in with another device" (which is the best option you can have, although still quite clunky), so you can solve the chicken-and-egg problem of logging in on another platform's device to add your another platform's passkeys. But to best of my awareness, this is not a part of any standard or recommendation (it should've been).

And other implementers do the contrary and artificially limit your options so you can't add a portable authenticator with them without some hacking around.

What are the vendor options though? (I think) its Google, Apple, Microsoft, Yubico and 1password? None of which support exporting the keys as per other comments in this thread.

Also (i think) none of them are open source?

1password publishes their implementation: https://github.com/1Password/passkey-rs

If you consider KeePassXC to be one of the big players, they (will) support importing and exporting Passkeys.

...and if i understand correctly, websites can dictate whether they allow KeePassXC (or any other specific vendor) to store their passkey.

In other words, if a website doesn't like that their passkeys can be exported, they can block KeePassXC.

> "If 1Password becomes unreachable for any reason, you still have access to everything in your vaults"

Temporarily, i guess? Since it's not stored in an open format?

Is this not bound to some sort of "Secure Enclave" or whatever, and won't survive a reinstall / restore / etc. ?