Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407
FIDO can't force any app developers to do anything but fwiw I think "pressuring" people to encrypt secrets at rest rather than storing them in plaintext is ok.
---
There's levels to appropriate paranoia around these things of course. SSH private keys are stored in plaintext for millions of engineers around the world - sometimes probably even passed around through unsecured emails or whatnot I would guess. They're still largely more secure than user:pass on aggregate, despite that rather major peril.
So ultimately, plaintext creds are not necessarily catastrophic. But still - imo - something worth concerted effort to dissuade at least at early stages of standards' implementation.
---
Edit: also, looks like the outcome of that thread was ultimately that KeepassXC have opted to implement the spec as per[0]. Good outcome to a good request.
[0] https://github.com/keepassxreboot/keepassxc/issues/11363
That threat has no teeth; anyone requiring attestation these days will cut out Apple users, because Apple will not implement it (for consumer use cases). If they don't block Apple passkeys, then KeePass can send Apple's AAGUID and the game is over.
I've complained about this GH exchange in the past and have come to understand that Apple is also part of the alliance, and the entire concept of blocking software-only password managers is just dead outside of enterprise situations where they mandate the hardware/software anyway. Mr. Cappalli might disagree, but he and his employer do not have the power to change this without breaking the standard and throwing away over a decade of work.
> trying to pressure KeepassXC to remove exporting passkeys in an open format
I'm not sure that's an entirely accurate representation of the request? At least from a quick skim the claimed issue is being able to export keys in plaintext. For example, from the issue author:
> I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption.
And later:
> > Besides, determined advanced users could just write code to decrypt the kdbx file and extract the passkeys anyway.
> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.
> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
To me that doesn't sound like they're requiring a proprietary format. Something like AES encrypted JSON sounds like it'd work as well, and that sounds pretty "open" to me?