mik1998 3 hours ago

So: currently, the cauldron is cold, therefore ignore the fire below it and hop right in.

deltoidmaximus 2 hours ago | parent | next [-]

The cauldron is already warm. I encourage people to read these issue trackers.

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

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

"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. 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)."

"This implementation is not spec compliant and has the potential to be blocked by relying parties."

Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.

	▲	shantara an hour ago \| parent \| next [-]
		These links should be a mandatory reading in every passkey-related discussion.
	▲	mik1998 an hour ago \| parent \| prev [-]
		These are very damning. Pretty straightforward about removing all software freedoms in favour of some sense of security. It really is already happening: > I have a sneaky suspicion that some of our failures with various RP's is because they are only accepting certain authenticator GUIDs. This comment from the KeepassXC maintainer makes me feel like the whole spec is already completely flawed if such a situation is even possible.

▲

undersuit 2 hours ago | parent | prev | next [-]

Just make sure you trust the cauldron you choose.

▲

lezojeda 2 hours ago | parent | prev [-]

[dead]