I thought this was going to be about Passkeys. Maybe if the FIDO Alliance can stop being obstinant and allow real backups, I'd be all in on them.
(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.")
https://github.com/keepassxreboot/keepassxc/issues/10407
Of course, they might just block you for not being on a whitelist of approved providers anyway.
> 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.
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?
> 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?
(You have every right do douse yourself in gasoline. No one is taking that way from you. Just say away from everyone else)
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!
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?
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.
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.
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
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.
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?
What's missing is a standardized format for the export.