Therefore, the author's scenario that sites will wait until most of their users are using attested passkeys and then "flip the switch and start rejecting non-attested passkeys" isn't very plausible.

Attestation is certainly a stain on the WebAuthn spec, and it would have been better if Chrome and Firefox didn't support attestation (unless perhaps the browser is enrolled in enterprise management), but this blog post is presenting a hypothetical and unlikely scenario. That's not a good enough reason to recommend TOTP instead, given that TOTP is vulnerable to phishing and passkeys aren't.

If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out, and maybe then the recommendation to use passkeys should be revisited. But until that happens, don't tell people not to use passkeys.

> Addendum: I feel I have made a compelling case for passkeys in this article. And I haven’t even pointed out one of their best security features: they are (in most use cases) domain-bound, meaning they are resistant to what are called Man-In-The-Middle attacks.

"I made a compelling case... but didn't point out the most important security feature that motivated passkeys in the first place"

Honestly I don't think this post did make a compelling case. There's a lot of assuming bad faith on the part of the FIDO alliance, while completely missing that preventing MITM attacks was a key design feature. The FIDO alliance members deal with stolen accounts all the time, and passkeys largely solve that. Stealing accounts is almost always done with phishing or social engineering, and passkeys solve the former and reduce the surface for the latter.

The first time I was forced to use a passkey implemented within the vendor's app (3rd party password managers were not an option). I quickly closed that account.

The second time was an app that popped up a passkey opt-in in the middle of a bunch of transaction screens. I quickly realized the error, but there was no easy undo. The opt in was one green button in the middle of the screen. Turning it back off required digging through settings to find the security option to disable, and then confirm my choice multiple times. That process also signed out all my other devices.

The fact that companies are resorting to dark patterns and forced requirements, where my money is held hostage, should be pretty good evidence of how poorly the passkey rollout is going.

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.

Is the audience of this article the kind of people who are already using passkeys and like them? Because, if so, we’re starting at a deficit here. The author is out to get my beloved passkeys that have saved me so much time and pain.

Are passkeys perfect? No. Are they even very good for no-technical users? Absolutely not…they’re incredibly confusing for that kind of person if you ask me.

However, for my workflow, I’ll take them over a password+2FA type of situation where logging in is such an annoyance. The security part of the discussion is very interesting and a lot of the things in this article are stuff that I didn’t know before reading it.

The issue is that, putting on my user hat, I just don’t care. As long as my accounts are reasonably secure I’m much more concerned about ease of use and workflow.

None of us had a say in our existence itself. Skin color. If we cannot have a say over our provenance itself "ultimate control" is just an empty phrase.

Their concerns about big corp might hold some meager merit but "beware the avarice of rich people who view you as a sheep in their flock whether you want it or not" isn't really new.

But there’s definitely a kernel of truth here. 1Password recently began to enforce userVerification: required[1][2], and suddenly on the desktop without TouchID I have to enter my login password to use the passkey on a good number of websites. I didn’t sign up for 1Password 15 years ago so that I have to enter both my very complex master password and very complex login password to sign into websites, the “one password” contract is suddenly broken after 15 years. This experience independently alarmed me about the additional constraints potential of the passkey standard and power wielded by the FIDO Alliance and partnering organizations addressed in TFA, which are, to be clear, useful for security in an organization. (We use userVerification: preferred now btw.)

Therefore, I believe the passkey technology is great for enforcing a standard of security in an organization and stand by my choice for my org. But as a general purpose B2C auth tech, if the additional constraints become widely adopted, user freedom will be seriously harmed.

Edit: I asked Opus 5.5 to vibe code a passkey auth solution in Go a few times without saying anything specific about userVerification. It chose required each time. So expect to see more of these. Oh and vibe coding auth without understanding it entirely is bad, please don’t do that.

[1] https://web.dev/articles/webauthn-user-verification

[2] https://www.1password.community/1password-at-home-31/user-ve...

Although this isn't true because actually with a password you have to choose how to generate it and everyone chooses different ways.

Passkeys in theory are great, but the capabilities of the spec are worrying. Defaults can and do change, and when they do, so follows 99% of the population, and then you find yourself either getting blocked out of services because your hardware/software doesn't comply, or you give in.

But on the other end, it might not matter anyways. Apple, Google, Cloudflare, are already pushing similar garbage and now you increasingly have to scan a QR code that verifies your mobile hardware to use a desktop.

If you write a long article about the merit of passkeys and there is no occurrence of the string "phish" in your article, I am afraid I cannot take your rant seriously.

Again, this stuff is not merely theoretical. YubiKeys have been a thing at Google and other major tech companies for almost two decades now and the effects are well-studied.

[1]: I have found for some weird reason, this is often overlooked and misunderstood in the industry. People even know about SIM swaps and stuff like that, but don't realize OTP is not phishing-proof.

me: Can you show me my stuff?

website: HTTP 401, who are you? I understand EasyAuth 1.0, if that is good for you.

me: Sure, here's my EasyAuth 1.0: Hi <website>, I'm <user_id>. The time is <timestamp>. Signed, <digital_signature>.

Use proper password managers, like keepassxc. Then you have control. But problem is that not all sites support that. If you can't use the above - then yes, passkeys are bad, especially if they become mandatory.

The protections against MITM you mentioned is probably the biggest one, but the other one in the back of my mind is TOTP is a shared secret. So a compromise of the server side allows impersonation of users undetected, which can be a big problem. Maybe I'm over reacting because no company has ever lost a copy of it's database and they're all super secure. But, imagine trying to argue as a user I didn't do a thing when there is an audit log saying we challenged the user for TOTP and it was provided, was definitely the users fault.

Users constantly fall for website impersonation, this can be solved by your password manager it just has to check the host and the certificate of the login page.

Now browsers don't let password managers do that, I wonder why.

But lets say you don't like the fact that passwords are sent over the wire. I get that I don't like that either. You could just take a random token and have an hmac signature on all your requests, for most cryptographic hashing functions that would probably be quantum secure as well.

But lets just say you don't want to have a shared secret because you know servers get hacked all the time. Totally legit, I like the way you think, asymmetric cryptography it is.

How could we possibly do it? Like ssh with pki on top.

The spec could be literally these 25 words:

Do what ssh does but request a PKI signed certificate instead of a key signature from the server and validate it against your known CAs.

Passkeys are an end run on general purpose hardware largely under your own control, which is a much bigger issue in scale than dealing with customers who can’t access the services they pay for because of some byzantine security or know your customer laws/procedures.

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

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.

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.

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.

Substitute apple with google, pay card with youtube comment and iphone with android for the "open" experience.

I apologize that the headline is provocative. I thought for a long time about how to appeal to both people who are barely aware of what passkeys are but also not put off people who like them. I considered calling them a "Trojan Horse" in the headline as I do in the body (i.e. legitimately lovely, but with a terrible and unobvious problem) but "trojan" has another connotation in computer security.

Nonetheless, I said what I meant. Convenience is how they get you. This convenience didn't have to come with a trap, but thanks to the way it was designed, it does.

So no one implements it for site-local login. Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.

The way secure auth works for small sites is that a third party[1] authenticates you, who the website trusts more than mere users. And that's where all the complexity comes up. You need something secure stored on your known-secure device, a password alone won't do.

[1] In practice Google or Meta. Occasionally Apple or Microsoft. Everyone else is noise.