But if you could back up a passkey, wouldn't the key just be a password?

(I do agree with you about backups being essential, but my conclusion was "the idea is fundamentally flawed," rather than "it's one tweak away from greatness.")

This is the irreducible problem. It's the Emperor's New Clothes™. So either the secrets get generated and stored in tamper-protected hardware, or they are stored somewhere else that can be made portable. For the latter, then they ought to be serializable into some standard form.

No, because unlike a password you never provide the private key for a passkey to the site you’re logging into, which is how many password breaches occur.

Passkeys solve phishing by being domain bound and never exposing the private key. It's a huge improvement!

What do you mean by real backups? What's stopping you from backing up your keys? Its up to the passkey "provider" to allow passkeys backup/sync.

Not really, they have no incentive to provide such a thing nor is it mandatory for them to do so.

Are you saying password managers don't have an incentive to provide a feature users want? That describes literally their entire featureset.

What incentive do they have to make it easy to migrate to a different provider?

People want the ability to back their passkeys up. The fact that this can be used for migrating is an unfortunate side-effect, as far as the provider is concerned.

Well, having your passkey provider blocked for doing that might stop you.

https://github.com/keepassxreboot/keepassxc/issues/10407

Of course, they might just block you for not being on a whitelist of approved providers anyway.

That's such a strawman argument. Read the link you pasted again

Strawman? We are talking about this link, right, the one that says:

> I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

> The reason we're having a conversation about providers being blocked is because the FIDO Alliance is considering extending attestation to cover roaming keys.

> From this conversation it sounds like the FIDO Alliance is leaning towards making it possible for services to block roaming keys from specific providers.

Yes, read the quotes you took again. Attestation is not a thing currently. There is legitimate discussion about how to handle shitty password managers. If LastPass shits the bed again, it would be great to have a mechanism for others to block it or at least know that due to a major incident, keys from that tool are week. Debian OpenSSL keys were vulnerable for a long time and being able to know and alert or block private keys generated on a Debian machine is reasonable if not desirable. If KeepassXC is insecure or promote insecure practices who's fault is that and what do you suggest we do?

The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices. How it that unreasonable?

Yes, we've seen you repeat that we have to read it again. I reread this morning before the post, but really just found more things supporting my position.

> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).

From the linked https://github.com/keepassxreboot/keepassxc/issues/10406 > | no signed stamp of approval from on high > see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.

> | RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference > It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture.

Is your argument that despite being doused with gasoline I can't complain because I'm not currently on fire?

So you’re just not gonna respond to any of the points explaining your straw man. Yeah you should read it again, and read my explanation again and let me know if you have any questions or responses. Dont douse yourself in gasoline and you won’t have to worry about being on fire.

(You have every right do douse yourself in gasoline. No one is taking that way from you. Just say away from everyone else)

Maybe you can let us know what definition of "strawman" you are using in this context?

KeePassXC is at risk of being blocked for making it easy to back up the passkeys. I don't see where that's been disproven or explained, other than saying "well attestation isn't enforced yet" -- that is, the metaphorical gasoline (provider AAGUIDs) hasn't yet been ignited (blocking of provider AAGUIDs)

> The entire issue is about doing the minimum possible of not exporting it in plaintext. Nothing is stopping you from decrypting it and posting it on your Twitter if you so wish. Just don't have the password manager encourage bad practices.

I don't disagree with this in principle, but it does warn you and realistically, what is the threat model here? It seems more like a defense-in-depth measure rather than a 5-alarm fire worthy of threatening to blacklist a provider. Maybe focus energy instead on this? (3+ year workstream now I guess?)

>> Sounds like the minimal export standard for portability needs to be defined as well.

> This is all part of the 2+ year workstream.

--

The more I get exposed to this topic, the less I'm convinced it was designed around people in the real world, e.g. https://news.ycombinator.com/item?id=44821601. Sure is convenient that it's so so easy to get locked into a particular provider, though!

> If LastPass shits the bed again, it would be great to have a mechanism for others to block it

And by the way, if and when something like that does happen, what's the user supposed to do if they suddenly find their passkey provider has been blocked?

The objection there was not to providing passkey backup. It was to doing it in plain text.

Since you keep posting this link, I'll just keep saying it: there is no credential manager attestation in the consumer synced passkey ecosystem. Period. There is no way to build and allowlist, by design. The consumer synced passkey ecosystem is open.

Passkeys on cryptocurrency wallets such as the Trezor and Ledger are tied to the device's seed phrase and can be backed up.

Did you try that? I can't find any confirmation on if it's actually working for classical keys but it's for sure not supported for resident keys on Ledger.

https://www.ledger.com/blog/strengthen-the-security-of-your-...

https://github.com/LedgerHQ/app-security-key/issues/6

https://github.com/LedgerHQ/app-security-key/issues/7

Is Trezor implementation more mature?

Damn I misremembered, I've only tried it on Trezor, not Ledger. What I do know is I've successfully used my Trezor for signing in to Google and several other sites through one or both of Chrome or Firefox.

Even with backups, the attestation issue makes them awful.

I'm not familiar with this issue and a quick search didn't turn up anything obvious. Would you mind elaborating?

They are referring to the ability of a site you are logging into forcing you to use a client from a specific list or having a list of clients to deny.

It's copied over from FIDO hardware keys where each device type needed to be identifiable so higher tier ones could be required or unsecured development versions could be blocked.

This is what I was referring to, and we already have seen this happen in the wild with PayPal at one point (possibly still) blocking passkeys from e.g. Firefox. For now the argument against this seems to be that "Apple zeroes this out so service providers can't do it without risking issues for their many users who use Apple to store their keys", but clearly this is so precarious of a situation it may as well not be a thing. You can't depend on one trillion-dollar company not changing their minds on that tomorrow.

Even with the current flimsy "What about iPhones?" defense against attestation, is there anything stopping say Microsoft from just forcing you to install a different app to use Microsoft services?

It's like DRM: it will annoy legitimate users and keep them from obviously legit usecases, and be circumvented by people who are motivated.

Thanks, yes, I see this just came up in a similar comment thread (https://news.ycombinator.com/item?id=44823752)

What a crock, to not bother coming up with a way to make passkeys portable and then threaten to ban providers who actually thought about how humans might use them in the real world

Specifically they are referring to synced passkeys (passkeys generated by services like Google password manager/1Password/Apple and are linked to that account).

Because these passkeys are stored in the Cloud and synced to your providers account (i.e. Google/Apple/1Password etc), they can't support attestation. It leads to a scenario where Relying Parties (the apps consuming the passkey), cannot react to incidents in passkey providers.

For example: If tomorrow, 1Password was breached and all their cloud-stored passkeys were leaked, RP's have no way to identify and revoke the passkeys associated with that leak. Additionally, if a passkey provider turns out to be malicious, there is no way to block them.

Why?

Erm... Passkeys _are_ backupable/syncable WebAuthn keys. You can get the clear-text Passkey private keys by just looking into your storage (Keychain on iOS).

What's missing is a standardized format for the export.

Same. Sacrificing security by selling superficial convenience and limited security advantages for crucial inconveniences.

Perhaps there ought to be a well-known, "ACME" password-changing API such that a password manager could hypothetically change every password for every service contained in an automated fashion.