News for hackers. Stuff that matters.
Re:We should have the ability to run any code we want on har... by breakingcups on Monday September 01, 2025 @03:43AM (#45090466)
Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407
Re:We should have the ability to run any code we want on har... by tadfisher on Monday September 01, 2025 @04:13AM (#45090649)
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.

Re:We should have the ability to run any code we want on har... by aw1621107 on Monday September 01, 2025 @04:06AM (#45090617)
> 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?

Re:We should have the ability to run any code we want on har... by g-b-r on Monday September 01, 2025 @08:45AM (#45092301)
> > 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.

Has there even, ever, been an instance of that happening?

Re:We should have the ability to run any code we want on har... by lucideer on Monday September 01, 2025 @10:11AM (#45092819)
There have been literally thousands of documented incidents of this.

There's an entire subsection of the security industry dedicated to this happening. The DefCon international security conference holds an on-stage competition where security researchers demonstrate this happening to real targets in real time in front of a live audience.

Re:We should have the ability to run any code we want on har... by g-b-r on Monday September 01, 2025 @01:13PM (#45094578)
> There have been literally thousands of documented incidents of this.

Of making people export all their credentials from a password manager and send them to a scammer?

Re:We should have the ability to run any code we want on har... by lucideer on Monday September 01, 2025 @04:45AM (#45090815)
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