Comment by david_shaw
8 days ago
This is a (very long and) well-written treatise against passkeys in their common and disparate forms. It's worth reading, and brings up several interesting and often concerning points.
I don't agree with the conclusion, though.
TOTP is great, flexible, and keeps the user in control; however, using a passkey in a flexible password manager (Bitwarden, keepass, 1Password, etc) really does continue to give the user control. And the user experience is dramatically easier than filling in TOTP codes.
To advocate for TOTP over passkeys, we're already relying on an application to generate those numbers (authenticator apps, password managers, etc). I see no reason to not simply continue using those pieces of software to manage passkeys, too.
> using a passkey in a flexible password manager (Bitwarden, keepass, 1Password, etc) really does continue to give the user control. And the user experience is dramatically easier than filling in TOTP codes.
See my comment here https://www.1password.community/1password-at-home-31/user-ve...
That's entirely a problem with one implementation and not the standard. It's like complaining Torx is bad because one manufacturer adds stabby bits to the handles of their Torx screwdriver.
This is only true until the vise closes all the way, they likely implemented it that way because they will eventually HAVE to:
"Once certification and attestation goes live, there will be a minimum functional and security bar for providers."
https://github.com/keepassxreboot/keepassxc/issues/10406
I can't use a passkey on a device unless I can install my password manager on that device and I am comfortable giving that device access to my passkeys. Passwords are simply unparalleled in their flexibility. You're never going to be locked out because <bluetooth, your TPM, your phone, ...> isn't working today.
I think the bit about TOTP was mostly a joke, the problem with passkeys is that they're billed as a replacement for passwords but they mix lots of MFA concerns in and make interoperability essentially impossible a lot of the time.
> I can't use a passkey on a device unless I can install my password manager on that device and I am comfortable giving that device access to my passkeys.
That's simply not true. I'm able to log onto GitHub on my corporate device using a passkey that's kept in 1Password on my iPhone.
https://bughunters.google.com/blog/passkeys
That's fine if you've got a couple of supported devices. The hardware support is however very bad. If my hardware is unsupported (and most hardware in the world is unsupported) that's not very helpful.
8 replies →
That's not really true, a QR code pops up, and you can use your other device to read it.
Even if your other device is a mainframe computer thousands of miles away, so long as you can photograph the QR code, you can decode it and send the data string for the passkey device needs to it.
The issue that many have with passkeys is that someone will tie a passkey to an ecosystem that they don't personally control like Apple's and then they can't get into their services without an apple device that's onboarded into Apple's ecosystem.
The other device has to respond "in nearby radio space" via Bluetooth LTE when using the QR code bootstrap, but that's about the only requirement and it can be just about any device.
But you can be locked out if the provider decides you need to change your password after a breach, or you forget the password, or you enter the wrong password in too many times.
They’re both equally disposable. You can reset a password just like you can reset a passkey.
> You're never going to be locked out because …
Yeah and neither will anyone else!
I completely agree that KeePassXC and other password managers give you total user control, and they do support "passkeys" -- but crucially, not all kinds of passkeys. KeePassXC has no remote attestation support, nor hardware-backing support, and nor do I think it should.
My claim is not that passkeys couldn't give you control in principle. It's that the standard readily allows for websites to prevent you from being allowed to exercise that control, and the unclear messaging and UX around passkeys means most users will not even notice should this happen.
That has nothing to do with the standard. Any website can invent its own proprietary authentication extension and try to force it on its users. If a website wanted attestation and the standard didn't have it, they'd just make their own extension. See Apple with Thunderbolt.
> using a passkey in a flexible password manager (Bitwarden, keepass, 1Password, etc) really does continue to give the user control.
Sure, but if you read the article you would know that deal can (and will undoubtedly) be altered. The passkey issuer can demand that the passkey be hardware-backed, and I've already run into passkeys that cannot be stored in bitwarden out in the wild (i.e. they REQUIRE that I use a TPM-backed store in my computer). Eventually it will be a particular TPM-backed store running on an attested platform. Now that's not generally the case today, but make no mistake, that IS the ultimate goal... You will only access valuable services from devices that you fundamentally have no control over (e.g. locked down OS's with attestation before you can access X,Y,Z), so that you can't steal from netflix, skip the sponsor segments on youtube, block ads in your web browser, etc. etc. etc. If you want a preview of how this might all work from the technical side, just look into how TEE works for large-scale GPU deployments right now.
Unfortunately I can see Apple eventually getting onboard too. As in "Sorry your device is no longer secure for using passkeys. Please update to a newer device!" Nice little incentive to boost flagging iphone sells.
Except that banks can (and do) already require proprietary apps to generate one-time passwords, often requiring official iOS and Android phones. It's not some nebulous future, it's happening now.
And you can't really blame them. A TOTP 2FA from your password manager is not secure. It WILL be hacked sooner rather than later. And SMS is horrible, expensive, and unreliable.
So far, only FIDO keys provide hardware-backed security ("resident keys", not passkeys) that is nicely segregated into self-contained hardware module. And it does not require you to run a full end-to-end DRM-ed stack.
If you _want_ true privacy and security, that's pretty much the best case you can hope for.
Except that those "self-contained hardware modules" are actually rarely "self-contained" but usually an integral part of a smartphone running a huge bunch of mostly-untrusted code and that the containment keeps getting breached, of course.
The only difference is that banks will now blame you for any losses caused by hacked devices because it is on paper "unhackable" with a well-updated device, so it is now your fault that their crappy bank app's security was broken.
And you still don't get to use Passkeys with banks, of course.
2 replies →
It's unfortunately full of half-truths which are not even necessary to make the point it's trying to make about attestation, so it's the opposite for me: Bad article, (somewhat) valid conclusion.
> TOTP is great, flexible, and keeps the user in control
TOTP is vulnerable to MITM attacks, so it's at best acceptable.
Indeed, there's nothing wrong with, e.g., passkeys backed by KeePassXC. The problem is specifically that passkeys support attestation, so eventually no websites that you need to use will support passkeys from those pieces of software.