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.

▲

oefrha 4 hours ago | parent | next [-]

> 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://news.ycombinator.com/item?id=50049311 about userVerification: required. Passkey in 1Password used to be on par or slightly more difficult than filling in TOTP codes (need to click to approve rather than browser extension autofill and even auto-submit on a large number of websites) but that’s no longer true with a good number of websites requiring userVerification. Now you have to type in your login password on desktops without biometrics. Forum thread: https://www.1password.community/1password-at-home-31/user-ve...

▲

lukeschlather 5 hours ago | parent | prev | next [-]

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.

▲

johnduhart 5 hours ago | parent | next [-]

> 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

▲

lukeschlather 3 hours ago | parent [-]

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.

	▲	WorldMaker 19 minutes ago \| parent [-]
		This "use a passcode from another device such as my phone" tech mentioned above is just Bluetooth LTE. Every phone and most laptops and desktops in the last decade or so has Bluetooth LTE support. Hardware support is very good. Passkeys are built on Webauthn (and ultimately sort of synonymous with it) and that has always been the web standard for all physical key support such as Yubikey and is basically the same as it has been for decades when dealing with Passkeys only with updated UX on top. Hardware support here is pretty good, too.

▲

Grombobulous 5 hours ago | parent | prev | next [-]

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.

▲

true_religion 3 hours ago | parent | prev | next [-]

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.

	▲	WorldMaker 15 minutes ago \| parent [-]
		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.

▲

jazzyjackson 4 hours ago | parent | prev [-]

> You're never going to be locked out because …

Yeah and neither will anyone else!

▲

nonfunctional 5 hours ago | parent | prev | next [-]

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.

▲

cvadict 4 hours ago | parent | prev [-]

> 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.

▲

elcritch 2 hours ago | parent | next [-]

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.

▲

cyberax 2 hours ago | parent | prev [-]

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.

▲

crote an hour ago | parent [-]

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.

	▲	lambda_lord 11 minutes ago \| parent \| next [-]
		Fidelity, Capitol One, and US Bank support passkeys.
	▲	cyberax an hour ago \| parent \| prev [-]
		I'm using a Yubikey that is permanently plugged into a USB-C port on my laptop and another one in my dock at home. > 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. And it actually doesn't matter if the secure device is designed correctly. Providing a secure channel over untrusted networks is something that we can do easily. > And you still don't get to use Passkeys with banks, of course. I can. I'm using US Bank and it supports my Yubikey-bound WebAuthn credential just fine.