[normalaccess]

I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want.

https://bitwarden.com/passwordless-passkeys/

[secabeen]

Can you export the passkeys to an importable form that your heirs can use to get into your accounts if you have passed away? Something that's sealed in an envelope inside a fire safe, for example?

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.

[withinboredom]

Generally, they should be able to get into any account with a death certificate, even if they don't know the password. It just takes longer. It took like 4 months for a friend to gain access to their dad's one-drive account to access photos on their computer.

[patrakov]

This is not possible if the data on the server is encrypted with the key derived from the person's password or a completely independent key and no escrow has ever been implemented. That's why, for example, you can't read my old Wire messages or look at photos that I sent and received there, even if you fake my death certificate.

[toomuchtodo]

Legacy contacts are the pattern here.

https://support.apple.com/en-us/102631

[cube00]

No chance that's happening with Google.

[squigz]

https://support.google.com/accounts/troubleshooter/6357590?h...

[cube00]

Good luck not getting burnt by Google's classic lack of support... https://www.reddit.com/r/google/comments/1fclx16/google_dece...

[jeroenhd]

Bitwarden's hosted platform has a feature exactly for this use case: https://bitwarden.com/help/emergency-access/

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
    }

(I have deleted the account on passkeys.io so don't bother trying to hack my demo account)

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.

[secabeen]

Thank you. This is helpful, as this is the first example of an actual key export that I've seen. The tiering system is interesting, that could work too.

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.

[packtreefly]

I put the passkeys in a password manager, then lock the password manager with multiple physical Yubikeys, keeping several in secure storage.

This same pattern works for Google/iCloud accounts.

[agile-gift0262]

I didn't know Bitwarden exported passkeys. This makes me consider migrating from 1password to Bitwarden. I've been a happy customer of 1password for 8 years, but it doesn't export passkeys, so I've been quite reluctant to using passkeys because of how they would lock me into 1password.

[cevn]

I switched last month and it is basically the exact same flow except.. you don't have to pay due to self hosting.

[ensignavenger]

It is my understanding that there is ongoing work to create an import/export standard, and that bitwarden is planning to support it. But also, you can give your heirs your bitwarden root password.

[sph]

> It is my understanding that there is ongoing work to create an import/export standard

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.

[mcculley]

Giving out the root password is less than ideal. I would prefer that my heirs not have to lie about their identity. I’m not singling out bitwarden here. Most SaaS offerings do not think about these issues. Pretty much every system should have a way of delegating authority without requiring lies.

[panarky]

Bitwarden paid users have a feature called "Emergency Access" where you designate one or more other Bitwarden users who can access your vault in an emergency.

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/

[seemaze]

While I agree with the premise, to equate utilizing another’s credentials as lying conflates a system identity with a physical identity. Is it lying when I give someone the keys to my car to drive? And when will this ‘root’ character realize I’ve been appropriating their login with abandon?

[rstuart4133]

> Giving out the root password is less than ideal.

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.

[vbezhenar]

vaultwarden uses sqlite database, so obviously you can export it.

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.

[SchemaLoad]

Yes. If you use a password manager like 1password you can print out the recovery slip and write your password on it. Then all of your passkeys will be accessible.

[internetter]

I think you missed the point. If I have a passkey in 1password how does it become my passkey? As in, a passkey I can freely read, redistribute, and store in platforms that are not 1password. This is a property of passwords but not of passkeys.

[SchemaLoad]

Today you can do that with open source password managers, and in the future there is a passkey portability specification coming to do passkey migrations between managers.

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.

[devman0]

if a passkey is exportable how is it materially different from a password? Isn't the point of a passkey to be hardware bound so it can't be swiped?

[Groxx]

They're closer to a client side certificate - you never send the server your passkey, you sign data that proves you have it without exposing it. (Or something semantically equivalent anyway)

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.

[hooverd]

Passkeys aren't vulnerable to phishing or breaches (if they are you have bigger problems).

[SchemaLoad]

Passkeys would be vulnerable to phishing if password managers allowed you to export them in plaintext. Because the phishing page would just show you the steps to do this and paste the private key in.

But because most managers have no UI for doing this, it's impossible to trick someone into doing it.

[lolinder]

What do passkeys synced over Bitwarden get you that a username + random password does not?

[izacus]

Same thing SSH keys give you what username + random password does not. Convenience.

[lolinder]

But how much more convenient is it really? Filling out the login form with Bitwarden is a single hotkey: Ctrl+Alt+L. That's such a light burden that I'm having a hard time seeing the value proposition for users who are already on a password manager.

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.

[horse666]

Phishing protection? Unlike passwords, passkeys are bound to a domain.

[lolinder]

My passwords are bound to a domain and Bitwarden will refuse to autofill if the domain doesn't match. I can copy the password manually if I care to, but that's true in every passkey implementation that I've seen as well: they're never the only login option, you can always log in with a password too.

[horse666]

I don’t understand what you mean, sorry. If you are manually copying a password, then you are not using passkeys? There is nothing to copy/accidentally leak with passkeys.

I guess it will be a while before passkeys are the _only_ option that websites accept

[lolinder]

I'm saying that as long as websites use the username/password model alongside passkeys with no way to turn off the former, you're just as at risk of phishing with passkeys as I am with domain-bound autofill.

Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.

[udev4096]

It's not paranoid to host your own password manager. It's about not relying on Bitwarden for the most critical service without which I am locked out of pretty much everything. Plus, you get lots of cool features that are only available on bitwarden premium

[lolinder]

The mission critical problem cuts both ways.

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.