Does anyone know the state of the standard wrt this? I know that they planned on doing something about it, just haven't kept up.
Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.)
I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.
But yes, you can export passkeys. They take this format in the backed up JSON:
{
"passwordHistory": null,
"revisionDate": "2025-05-15T11:10:37.341Z",
"creationDate": "2025-05-15T11:10:37.134Z",
"deletedDate": null,
"id": "3b90b785-efb7-491b-92e8-525b446df781",
"organizationId": null,
"folderId": null,
"type": 1,
"reprompt": 0,
"name": "passkeys.io",
"notes": null,
"favorite": false,
"login": {
"fido2Credentials": [
{
"credentialId": "f167c754-5a4c-4c4a-b5e5-6faf18bde5a6",
"keyType": "public-key",
"keyAlgorithm": "ECDSA",
"keyCurve": "P-256",
"keyValue": "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgMnNsrXAHP50Glhs1vBPgCFVv3jj-nuZ9gHVRdGg2anehRANCAATtK7xFvDIn8mAOCniczaG5ytAE_eBR0kkgd5lFVahpI6tQ5U-nBAkgqvlmtObrWDNu0-RgiCgYnOLXFPEyda4j",
"rpId": "www.passkeys.io",
"userHandle": "47GTTn99QtyNUGaMFMzH2A",
"userName": "<masked against scrapers>",
"counter": "0",
"rpName": "passkeys.io",
"userDisplayName": "<masked against scrapers>",
"discoverable": "true",
"creationDate": "2025-05-15T11:10:37.645Z"
}
],
"uris": [
{
"match": null,
"uri": "https://www.passkeys.io/"
}
],
"username": "<masked against scrapers>",
"password": null,
"totp": null
},
"collectionIds": null
}
As for the lack of documented export options: that's kind of the point for many passkey providers. You can't export the key from a Yubikey, you can't export the keys from a smart card, you can't export the keys from an RFID dongle*, and in the same vein you cannot export the keys from many passkey providers.
What you can (or at least should be able to) do, is add a backup key. That can be someone else's PC/account in case your house burns down, or a physical Yubikey you store in a fire safe somewhere, whatever mitigations you need. You could also use a tiered setup; if you use hardware tokens to sign into your relatives' Apple/Google/Microsoft/1Password account, you can in turn use their cloud tokens to sign into whatever services they use. That way, you hand out some trust to their authentication provider, but in exchange managing physical backup keys becomes a lot easier as you don't need to open your safe every time you create a credential for an important website. You can use such a physical recovery key even if your relative prefers to log in with username+password.
On the flip-side, backup keys are not a solution for me in this instance. The model being proposed is one where we have hundreds of passkeys in our vaults, one for each service. I don't want to spend time setting up a backup key on every service; I want the ease of use of just hitting "use passkey" on a new site and having it all work. I just also want a 100% reliable backup option that has no dependency on any service, vendor-specific system or anything. Essentially, I want a backup that my grandmother could hand to a local kid with tech skills, and be able to get into my account(s) while sitting together at her computer.
This same pattern works for Google/iCloud accounts.
I have heard this so many times that, given the big names behind the standard who benefit from vendor lock-in, it’s no wonder they are dragging their feet. Until there is a serious import/export mechanism, I’ll stay away.
If you die or become incapacitated, your emergency contact can click a button to request access to your vault. You receive a series of emails requesting that you approve or deny their request.
If you don't deny their request within a wait time that you specify in advance, your public key-encrypted user symmetric key is delivered to the the emergency contact for decryption with the their private key.
More here -> https://bitwarden.com/help/emergency-access/
I expect something akin to handing out the private key to your heirs is what happens. But the term "giving out" understates what happens: https://bitwarden.com/help/emergency-access/ It's an escrowed time lock. I haven't looked at the details, but I expect it's a multi step protocol involving at least two public keys. It the scheme of possibilities, it's pretty good.
I think that there are some objections about allowing user-friendly way to export passkeys as it's contradicts with their nature. But in the end they are exportable.
May be someone would build pure software implementation as browser extension which would allow export-import as PEM files and to hell with purists.
But in general it's a bad idea to have the passkeys just sitting around in text files so the current managers are largely designed around preventing the tech support scammer from instructing grandma to dump the passkeys and email it to them.
Other than that, which is mostly only a benefit for edge cases around partially compromised devices or servers: yeah they're not much different than random unique passwords. Except they have vendor-lock-in.
But because most managers have no UI for doing this, it's impossible to trick someone into doing it.
I can totally see the value for companies who serve users that don't use password managers—if you can get those people onto passkeys that's a clear security win.
I guess it will be a while before passkeys are the _only_ option that websites accept
Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.
I've weighed the risks and decided that I'm more comfortable relying on Bitwarden for the most critical service than I am hosting in on my own hardware and counting on my own skills to keep it available. I self host plenty of other things, but having `rm -rf /`'d my hard drive before I don't trust myself more than I trust the folks at Bitwarden.
If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).
Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.
For support matrices, see [1].
> there is no syncing between keys
There is a similar problem even in OTPs. I switched phones not too long ago and some OTPs didn't properly transfer. I actually lost some accounts due to this, luckily nothing critical (I checked critical things but it's easy to let other things slip). The problem is that registering a new OTP removes the old ones. In some cases I've used recovery codes and in others the codes failed. IDK if I used the wrong order or what, but I copy-paste them into bitwarden, and I expect this is typical behavior.
99% of the time everything works perfectly fine. But that 1% is a HUGE disruption. With keys, I would even be okay if I had to plug my main key into a dock to sync them. Not as good as a safe, but better than nothing. I feel like we're trying to design software safes like we design physical safes. But if you lose your combo to a physical safe you always have destructive means to get in. With digital, we seem to forget how common locksmiths are. Googling, numbers seem kinda low but I'm not in a big city and there are at least 4 that I pass by through my typical weekly driving. So it seems that this issue is prolific enough we need to better account for actual human behavior.
[0] Don't get me wrong, I love them but I'm not willing to not undermine them via OTP creds because I need some other way in.
Actually it is a feature. The whole point of the Yubikey is that you can't extract the key. Syncing keys would mean extracting them, which would defeat the purpose of the Yubikey.
Now I am not saying that it is a feature you want. That's why there are other kinds of passkeys. My point is that it is not a flaw in Yubikeys, it is by design.
> Actually it is a feature.
The joke is quite old and part of what I'm pointing to. Security doesn't work well if it isn't very usable. At least this is a bit better than secure communication, but it isn't as huge of a difference as it might appear.
The biggest boon in security has come due to making these tools easy to use. That's from decades of experience is realizing you can't get everyone to be technical.
Passkeys use FIDO2, not PGP?
As I understand things, passkeys come in a few different varieties.
You can buy a yubikey if you want the credential tied to one specific physical device. Figure out your own backup strategy, such as spare yubikeys or printed recovery codes or whatever.
Or you can use apple/google/microsoft if you want your passkeys backed up to your cloud account. This means passkeys are basically the "Log In With Google" button, but with extra steps.
I feel like if I must choose between a 99% reliable syncing solution, and a non-existent automatic syncing solution that requires manual syncing, I would still choose the latter for its mental simplicity.
My point is that training doesn't seem to be effective to the general population. Frankly most people don't care. As we both probably know a big part is likely not knowing the importance
> The best algorithms are useless if they're too complicated to use and can't fit the reality of an average user.
I agree. So get rid of needing to understand algorithms and simply require users to understand passkeys in relation to their house keys.
> This strategy has not been tried.
Have you tried to convince your friends to use messaging systems like Signal? What about PGP?
> understand passkeys in relation to their house keys.
There are plenty of cases where I know that people have misplaced Yubikeys. They might have a spare Yubikey. Or the equivalent to finding a locksmith is to log in with a non-passkey method. It's fine and in fact better if logging in without a passkey is considered an unusual fallback.
> A passkey synced using iCloud or Google account does not break that model
> Or the equivalent to finding a locksmith is to log in with a non-passkey method
Both of these were mentioned in my post you originally responded to: https://news.ycombinator.com/item?id=43988957
Eg. My Microsoft desktop, my Google phone, my Apple laptop all have passkeys setup individually that allow login to my various accounts such as my Google account.
So they aren't at all synced. They are all from different vendors but they can all login since i set them all up as passkeys. It's easy to do this too. Setup one site for passkey login via phone, go to that site on your desktop and select "auth via phone passkey" and use the phone passkey and then once logged in on the desktop go to account setup and select "Create a passkey on this device". The end result is you have multiple hardware security keys, namely your phone, desktop and laptop.
Hopefully better syncing comes soon but i'm ok with the current situation for now.
This is where the incentives push and is why we're unlikely to see usable or easy passkey sync.
I'm sort of ok with this (it will be a net security improvement) but it saddens me a little to see more of the web come under centralised control.
Most people won't fully understand the implications of this, which will be that the right law enforcement request will instantly unlock every service you have access to regardless of jurisdiction.
Plus lots of secondary effects relating to fed auth providers having increasing leverage over the web in general.
You are conflating the old model of "log in with Google" and the new model of Google syncing your passkeys in an E2E way. The latter is more resistant to law enforcement misuse (not 100%, see All Writs Act in the San Bernardino shooter case).
It's a nuanced discussion because in practice today, email provider is regarded as ultimate source of truth regarding identity, except for high security domains e.g. where money is involved (banks, crypto) and it's economically viable for recovery to be high touch.
So having access to a user's email is the first "golden key".
Second is OIDC / social logins.
Third would be passkeys / stored passwords / an unlocked device.
My guess about the future is that OIDC / social login will prove to scale and grow better than direct passkeys in most instances. It's a better, more fully developed model for thinking about and managing identity lifecycle, passkeys themselves are a low level primitive by comparison.
Users will understand it (social login) better, providers will support it better (partly because corporates don't have any way to centrally manage passkeys at scale, nor should they) and finally because of the fallback / recovery problem for sites using passkeys.
Backup codes, sms phone recovery, alternate recovery email are all there in all of the above.
It's no different to forgetting your password/losing access to your password manager is it? As in i've literally at points lost access with passkeys (i only had 1 at the time) and the way i got back in was very straightforward and no different to losing access to a password manager. I got an email and typed my old password and i got back in and re-setup my passkeys.
The way I assess risk, that's less likely to happen than I am to lose my passkeys.
If I'm using passkeys but can recover my account with SMS, then why am I using passkeys? That sounds like the weak link of security. I'd rather use passwords, where I can understand what the password consists of rather than passkeys if I'm not getting an increase in security.
It's unfortunately not quite the same level of portability as passwords, as I don't think there's any standardized export/import format yet, but these options are significantly better than Apples's and Google's closed ecosystems.
I back up my 12 word seed phrase, and then I can restore any and all my TOTP/FIDO/passkeys with another one if needed.
Searching online I found an answer on Stack Overflow stating that a PIN is required in this case: https://stackoverflow.com/a/79471904 How did you bypass it? I also find it idiotic that it is required. A PIN is just a password in another name, so we are back to using Yubikeys as the second factor in 2FA rather than a password replacement.
You need to buy a newer Yubikey with biometrics to make this work. I assume you have an older Yubikey and Google is getting to the standard by asking for a PIN.
I have a https://www.yubico.com/products/yubikey-bio-series/ and it works with Google exactly like you want it to, no PIN required. It's completely understandable to require a PIN if you don't have one of these though.
It’s no inconvenience though since the yubikey with a button to press and a yubikey with a biometric button to press work the same.
Is that how it works? A dropped house key essentially has a second factor (the address of the home), but if you have someones Yubikey that can be used for Google, is the Google Username stored in the Yubikey and accessible to the finder?
Like you can argue a dropped house key is similar to a dropped yubikey but i'd still give some benefit to the dropped house key involving real world attempts on locks with appropriate social suspicion on that if seen vs a dropped yubikey allowing anonymous attempts.
Effectively you have a secret that you are using to authenticate yourself. With pass keys managed by a vendor, you are trusting that vendor to manage your secret. If they are able to give your secret to someone else, then they can no longer confirm who all knows your secret.
I'm sure you can come up with a protocol where you can fan out access to the secret in a way that requires fanning back messages to you. But I don't see any clear way to do so that doesn't increase the communication burden on everyone.
I'm also sure smarter people than me can surprise me with something, here. But secrets that can be shared historically tend to not be secrets for long.
the spec actually supports this, it's called caBLE
Asked differently, how does this get a vendor out of the picture?
But the FIDO alliance is apparently working on that: https://fidoalliance.org/fido-alliance-publishes-new-specifi...
I also have to confess this is clearly less convenient than having Apple or Google manage them for me.
[1] https://fidoalliance.org/specifications-credential-exchange-...
https://github.com/fido-alliance/credential-exchange-feedbac...
I am worried about providers blocking exports “because security”. That’s Apple’s favorite argument
The issue with hard tokens is that there is only one of them. By design, you can't back up a Yubikey's content to a second token. This means that any time you add 2FA to a new account, you must have all of your hard tokens in your possession to enroll them. This means a "one token on your keyring for daily use, one token in a safety deposit box as backup" approach isn't possible.
Yubico did propose a potential solution five years ago[0], but that proposal seems to have gone nowhere. Until something like that gets implemented, FIDO2 (and by extension Passkeys) requires some form software implementation backed by cloud synchronization to actually be usable for the average person.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
> When you need to signup for a new service on the go, you can add your backup key when you get to it
Requires you to remember doing that each and every time. Incidentally this isn't that different from just grabbing your keys like the parent suggested. Only it introduces a new variable: time delay. A lot can happen in that time and we all know the reality is that even a diligent person is going to slip now and then. It surely isn't a reasonable expectation for an average person.
every few months I swap 2 and 3, and re-enroll any missing (kept track of with a spreadsheet)
quite annoying, offline enrollment would be considerably better
It's absolutely a goal, since a PIN doesn't prevent your security key from loss, theft, or physical destruction.
That’s one way to look at it: passkeys are just a more convenient form of authentication compared to passwords. Although in my mind you’re arguably not achieving a whole lot considering the security bottle neck is still the same, being the login to your password manager.
I use physical Yubikeys so I’m a bit out of the loop here, but are there any methods for protecting your root password to your password manager in this scenario?
What if you lose your device? Do you install alternate passkeys in a second device? Do you have to do that for every site and service?
Many password managers do just that.
By a far and away WORTH the subscription, for me!
In effect, though, 1Password is both something you have (the device with 1P logged in, login requires a Security Key that you don't memorize) and something you know (the master password) or are (typically biometrics can be used to unlock for a period after entering the master password.)
Pretty much all the problems related to passwords are solved by passkeys, having them synced between your devices does not impact that.
Unfortunately the spec authors think this export feature violates the spec and have threatened KeepassXC with being banned by authenticating websites[1]. This explicit support from the spec authors for client banning makes passkeys non-viable to me. The websites I log in to should not be able to restrict what clients I choose to use to manage my own data.
[1] Spec author writes, "To be very honest here, you risk having KeePassXC blocked by relying parties. ... (RPs [may] block you, something that I have previously rallied against but rethinking as of late because of these situations)." https://github.com/keepassxreboot/keepassxc/issues/10407
Basically, do what we say or expect us to have our corporate sponsors write bad press about your security.
They have no interest... in collecting subscription fees? I'm a satisfied 1Password customer, but it's hard to take this claim seriously. What does it mean? They literally get paid. Isn't that the definition of an interest?
> But how can websites know whether its users are using secure authenticators? Authenticators can cryptographically prove certain facts about their origins, like who manufactured it, by generating an attestation statement when the user creates a passkey; this statement is backed by a certificate chain signed by the manufacturer.
How many scummy companies trot out "Let me protect you from yourself" to justify taking away their users' freedoms?
Exporting/transporting keys seems to be optional on the part of implementors, but my solution has been to use Bitwarden, so I at least get cross platform keys.
One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
The spec failing to distinguish between these two cases is a major flaw and completely kills passkey viability for personal accounts until they resolve it.
I'm interested in reading more about this. Do you have some links? I did some quick searching of the terms you mentioned and nothing obvious came up.
Some quick bits and pieces from my own searching just now:
Apple's documentation on Passkey attestation is entirely under "declarative configuration", their terminology for mobile device management (MDM) corporate tools: https://support.apple.com/guide/deployment/passkey-attestati...
It is noticeably absent from, for instance, AuthenticationServices documentation: https://developer.apple.com/documentation/authenticationserv...
On non-attestation Passkey responses intentionally send an empty AAGUID for privacy/Apple's belief in the spec's suggestion to send an empty AAGUID:
> iCloud Keychain is one of the few (maybe the only?) passkey authenticator that currently follows the spec and will use an all-zero AAGUID.
From: https://developer.apple.com/forums/thread/739004
On the technical side of limitations of attestation for consumer Passkeys (due to iCloud Keychain sync):
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
> Attestation was designed to attest to a specific device, exclusively at the point of creation, with a specific set of security properties. It doesn't make sense for synced credentials for a number of reasons, including syncing to devices with different security properties, changes in security properties that happen after key creation, security properties of the sync fabric, sharing the passkey, or exporting to other passkey providers. We're working hard with W3C and FIDO to solve these problems.
From: https://developer.apple.com/forums/thread/708982
(I believe some of the problems being solved in that one in 2022 is referring to how we got the "uvi" and "uvm" extensions to Passkeys, neither of which is in attestation data nor attested in any way, and both designed for a general semblance of user privacy: https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension)
I believe the juiciest quotes I'm looking for are buried in WWDC videos and I can't find a transcript search tool just yet.
> Passkeys do not provide an attestation statement, as the attestation model currently defined in WebAuthn wasn't designed with syncing credentials in mind.
On any platform, attestation and "syncing" are effectively opposites. Either you're getting attestation that the auth comes from a secure application and on secure hardware (read: non-exportable in-TPM crypto material), or not.
As usual, it's a tug-of-war between security and convenience.
From a freedom perspective, I need to ensure that Google has no idea whether my device is an Android phone bought from an officially licensed manufacturer, or Waydroid or android-x86. Compliance is not an issue because I am, ya know, some random guy. The only way I can ensure this happens is by ensuring attestation is not possible.
For example, iOS uses the App Attest service (https://developer.apple.com/documentation/devicecheck/prepar...). On Android, you get it from Google Play Services (https://developer.android.com/google/play/integrity/overview) then the built in key attest service (https://developer.android.com/privacy-and-security/security-...). MS Authenticator does all the legwork and returns the results to you at sign-in time.
On Windows, WHFB has this built in (obviously). On macOS, this comes from Platform SSO (https://support.apple.com/en-ca/guide/deployment/dep7bbb0531...).
The problem is that Passkeys really conflate two separate feature sets:
1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys.
2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.
Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.
This technically is true because Passkeys are just a subset of WebAuth.
Apple doesn't support it at all anymore; Google only supports it for non-synchronized credentials (which are arguably not passkeys). Bitwarden obviously doesn't either (it can't, as a pure software implementation).
> One of the developers already threatened to use it against keepass when they built an export feature he didn't agree with.
Developer of what? There's no competing software solution that supports attestation, and hardware authenticators complement software ones, rather than compete with them.
Not directly threatening but within that frame of mind:
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...