Passkeys will be importable and exportable, cross-device, and across passkey managers. They aren’t at this time, but they will be. It’s something that’s being defined and designed.
I see how this is a must-have for them to replace passwords, but if they export as just a file or something they could be stolen like passwords. Fake apps could be made to trick people
And allowing transferring only to apps with some kind of verification wouldn’t be good, as it would limit the available options to only specific ones and not smaller or self-hosted ones
Well the stealing problem is still better than having no portability/syncability, and even so they’d still be better than passwords, but stuff like phishing wouldn’t be extinguished
Maybe I have a wrong idea about how Passkeys work, but I can’t think of a way to transfer them (or anything) without having the possibility of stealing
Being able to set up multiple passkeys for the same account would potentially be a fix for this - so you’d have like a Passkey on iCloud and a Passkey on XYZ, both for the same account - but I guess this would be more on how each website implements Passkeys right?
@rmondello Is there anything in the spec for sharing passkeys? Example: my wife and I share a Gmail account that we use exclusively for all of our son’s school stuff, so we can both see and respond. If I switch my Google accounts to passkeys, can we each have a passkey to the same account? (sharing question is not Google-specific, but that’s just my current use case)
@rmondello at the moment there’s no way to sync passkeys between iPhone Safari and windows chrome? Is that on the cards? I guess this is where third party managers like 1Password can come into play?
@rmondello@siracusa Core to the early passkey design docs was the idea that the user can never ever export the private key. This is true across every public private key design system. If users are exporting private keys from specialized key storage hardware, the system has failed.
The only proposal I’ve seen is that a user would be able to enroll multiple tiered keys at the same time, which neither solves the vendor lock-in problem or the usability design.
@matdevdug@rmondello Platforms have implemented multi-device authenticators, where a sync fabric backs up and synchronizes credentials installs/devices - same as many password managers have taken. This is transparent to relying parties.
The Yubico proposal is about an anonymized reference to another 'backup' authenticator, which could be registered later as part of an account recovery process. The main and backup authenticator never shared credentials, and sites have to opt into the feature.
@dwaite@rmondello I understand that the platform sync is a component of the implementation outside of the spec of webAuthn and there is nothing preventing vendors from taking the sync component and adding the ability to add a target to the sync. I also understand the different between a sync and Asynchronous Remote Key Generation.
My confusion is that central to the idea of webauthn is hardware based storage of private keys. So a vendor is basically trusting itself with the sync component to allow for the exporting and mandating of exports of private keys from the hardware to a software sync. Everything we've seen (publicly) has been the sync process is locked to whatever ecosystem you enroll in. Chrome doesn't sync through the browser to write to arbitrary hardware storage.
Even more complicated is that the standard allows for different levels of quality when it comes to that hardware storage device for keys. So while the sync itself presents an understandable (if high) risk for users, an export either suggests: I can write the private key to a text file and import it to A Password Manager which largely defeats the purpose.
Or vendors are going to extend the sync process to include some other arbitrary target depending on some unknown criteria. I can't find any additional conversation or plans in the spec debate or online in general that lays out how any of that will work, hence my concern.
I.E.: If Apple implements the option to export a private key to 1Password, that's great, but can I put it in Android? Is there a specification that says where I can and cannot put it? Will Apple let me export them in a file and import them into a lower-security device like a cheap Windows laptop?
@dwaite@rmondello Again I'm totally fine with missing something obvious and I'll gladly eat some crow on this but this has been an unanswered question about how this will work since 2018 so if there was a decision made about how the keys get shared somewhere I would love to read it and be less wrong.
Add comment