Comment by Dagonfly
7 days ago
Passkeys are just a private key plus some metadata.
Bitwarden lets you export your vault, and the export contains the private key in plain text. There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.
This changes if attestation ever becomes widespread. Which will only happen if Apple does a U-turn on their stance.
> There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.
The big difference is not just that a passkey is a private key, it's that the server you register the passkey within holds only the corresponding public key. They don't have a copy of your password (long or otherwise), not even a hashed version of it that could be recovered from a password database dump of the server.
This is a big improvement compared to the days of having your "strong password" end up on the dark web somewhere.
Yeah, I was only talking about differences for backup.
As long as no attestation is used, you only have to store the private key, credentialId and userHandle (basically the server generated ids of the passkey and the user). That's not to different to writing down username and password.
Bitwarden is the only vendor I'm aware of that currently allows this, and it wouldn't surprise me if their new management takes this away in the medium term.
The FIDO alliance is trying very hard to squash any workflows that a scammer can use to convince an elderly retiree with $1mil in savings to wire their life savings to Russia. Unfortunately, nearly all of the export paths that we want as hackers overlap with these attack vectors. The drafts of the Credential Exchange format or Protocol assume that end-users and open-source tools are not valid targets.
Skimming through the exchange protocol draft it seems like a pretty standard diffie-hellman. Seems easy enough to write a FOSS script that requests an export and then dumps it to plaintext.
My read of it is that there won't be an endpoint for an FOSS script to connect to to make the request. All that stuff will be provider2provider on private channels that aren't publicly exposed.