Comment by reddalo
1 month ago
> as soon as passkeys started popping up the endgame became clear
That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does.
They're just a lock-in mechanism.
1 month ago
> as soon as passkeys started popping up the endgame became clear
That's why I'm 100% against passkeys. I'll never use them and I'll make sure nobody I know does.
They're just a lock-in mechanism.
"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything.
Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys".
Two things have changed with the rebrand:
1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually.
2. A lot of large companies have set themselves up as providers of FIDO2 resident keys without export or migration mechanisms. This is the vendor lock-in part (no export feature), but it's not a feature of the underlying tech itself.
Fwiw FIDO are actively working on some standard for exporting/importing keys so that's something.
If you want to use passkeys without lockin, just use Bitwarden or KeepPassXC - they all have full support. Or you can also store a limited number of passkeys on your FIDO2-compatible hardware key like Yubikey or the open-source Nitrokeys.
Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407
> 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?
3 replies →
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.
By the way, notice Yubikey did not really release any new series/models and jacked up their price in just a few years. About 50% in 4 years.
The large adoption of those devices and standards did not lower the price.
They probably just banked on the enterprise market where every CISO was pressured to tick the hardware/2FA checkbox. And is then gonna allow to use the Microsoft/Google "software" one because it is hard to manage otherwise.
I think there's a bunch of factors to why yubi have upped their prices - not least, waiting for competition in their form factor & not seeing any emerge (token2 & nitrokey are much bulkier) probably gave them some confidence in the uniqueness of their product offering.
It's also become a much more niche product as software based (and/or primary-device-hardware-based) solutions have evolved & improved. & niche costs more.
All that said I'm really not sure why they've been so quiet on new series releases.
1 reply →
Passkeys would be wonderful if they removed remote attestation. Remote attestation is still there, so I will not touch it.
Passkeys would be better without remote attestation, no doubt. But remote attestation is not only optional but also, passkeys are not a prerequisite for requiring remote attestation.
Lots of services that don't support passkeys currently require remote attestation. Boycotting passkeys (an open, possibly beneficial tech that doesn't require remote attestation) will not prevent bad actors from requiring remote attestation (with or without passkeys).
2 replies →
For someone who hasn't spent any time thinking about that matter, could you please elaborate your point?
"Passkeys are incompatible with open-source software" https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
Then how come KeePassXC has them?
9 replies →
Imagine using ssh-keygen, but it locks the private key in a vendor-managed secure enclave. You can't copy it, export it, rename it or do anything wth it.
I don't just imagine it, I do it, by using gpg-agent as my ssh-agent and using the private key generated by a Yubikey. Another way is to use tpm2-tools so only your laptop running your own signed boot chain can use the key. It is desirable to lock private key material in a physical thing that is hard to steal.
You can choose not to do this, and that's fine. Hardware attestation is dead because Apple refuses to implement it, so no one can force you to.
2 replies →
Do you recommend a password manager to everyone you know? What's the adoption rate?
As a data point: when non technical friends of mine complain against password I tell them to use a password manager. The adoption rate is zero, probably because they don't even know what a password manager is, except the remember password / fill in password feature of their browser. The best I saw, from a not entirely non technical person is passwords on sheets of paper.
I have tried repeatedly to get my wife to use the family 1Password account for things we will both need, with minimal success. She is reasonably technical, she writes SQL, but she just won't do it.
1Password is completely broken in android. I have barely a 50% success rate with it filling in passwords, I'm usually copy/pasting back and forth.
If there were anything better and as easy to use as Chrome, I'd switch.
I honestly suggest using Mozilla Firefox built-in password manager, it's enough for most people.