Note that attestation can only be required during credential registration; at login time it's not possible to retroactively require attestation if it wasn't obtained during registration. And browsers will throw up a permission prompt if a website requests attestation. Are Netflix and Twitter currently requesting attestation when people register passkeys, and rejecting the registration if the user declines the permission prompt? I very much doubt it, since Apple's passkey implementation doesn't support attestation.

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.

I've yet to voluntarily enable passkeys, for the main reason that I want portability, and not to be tied to any single device that can be lost. I want to be able to backup and lock my credentials in a safe. I also want to control the strength of my credentials for different services, and I don't consider my thumbprint used to unlock my phone to be as strong as a long password in a password manager.

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.

The very last thing, past the conclusion, the very last footnote is:

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

I’m an advocate for passkeys and I abolished passwords and embraced discoverable passkeys for our org’s key internal systems exclusively. So the battle cry of a title immediately put me on the defensive, unfortunately. The urge to not read is strong. A more measured title may help here.

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

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.

Remote attestation is the root of all evil and a severe threat to freedom. It's disturbing that those working on this technology are so willing to "put the nooses on their own necks."

This 4-year-old article and its comments are worth reading again: https://news.ycombinator.com/item?id=29859106

I like the writing in this article. The author did warn us, but the punchline takes a while to get to:

> I’d like to be clear that there are legitimate uses of remote attestation. By using a website that requires attested passkeys you can be sure you stay safe from accidentally installing a scammer’s fake passkey application that steals your data – the website will reject such a passkey. You might want an attested Passkey even if the website doesn’t require it, since you can use attestation to verify that your software has not been tampered with by a hacker while you weren’t looking.

> As for reasons to not want attestation: you might want to be able to use software that Twitter (formally X) doesn’t specifically approve of, such as Linux. Or a phone with a refurbished operating system.

So the bad timeline is the one in which the industry gradually transitions to "you can't log on unless everything about your system is exactly as we want." Figures.

I've been complaining about passkeys for a long time and it was driving me crazy that it seemed to be the one thing that Big Tech, tech-savvy people, and normies were all on the same page about. The recent PR push a few months back was overwhelming.

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.

I don’t know if it’s productive for me to talk about how a headline is off-putting, but I’m going to mention it because, well, it’s a headline, and a headline is a strong first impression.

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.

Passkeys make it feel like the site is trying to get more info about me; it seems harder to maintain multiple accounts with passkeys. They feel worse for anonymity than a password where you know exactly what you're pasting into the site.

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

"If you accidentally leak your TOTP in a photograph of your desk"

So many security articles just seem to be so far removed from the real world. Like, when is that ever going to happen? It's the same principle that forces people to reset their password every month. Sounds secure in principle but then everyone just writes it down.

The reality is that Passkeys are way more convenient for most people. Reducing barriers to adoption is the best thing we can do to improve security.

Not sure if anyone else has mentioned this point here, but passkeys are likely not protected by the Fourth and Fifth Amendments, whereas passwords generally receive much stronger protections.

Advocating for privacy and at the same time speaking about "corporations like Microsoft, Google, Apple, Facebook, Amazon" is a contradiction for me.

Have all your mails at Google, ship stuff home with Amazon, but your authentication mechanism is a trap and anti-privacy?

My company's product uses passkeys-only and it works great. We don't need to store user's email addresses if they don't want to. Because we don't need a password-reset flow. Because passkeys usually sync and backup. And if you really want, you can have multiple passkeys for your account (or multiple accounts).

I don't see how we could use passkeys as a trap. Our users find it convenient and the security properties speak for themselves.

The main thing I think technical people forget is that just because a protocol calls for transferability being a required feature (not that it really is here), it really doesn't matter if implementing it isn't strictly necessary for the protocol to work. That's one of the reasons why we have a bajillion different OAuth and OIDC implementations that plug into existing account systems in various ways, from being the only way to log in to being an optional way of logging in to an account that can also have an e-mail and password set. Developers are busy, and often implement just what they need to plug in to the OIDC providers their PM wants, and nothing more.

Both Passkeys and OIDC are vendor lockin enablers due to these design choices.

I wish the next standards would keep this in mind.

Given the weight and blessing governments in Europe and America are putting behind passkey roll outs despite the awkward provider lock in, I’m convinced the centralisation of credentials is one of the early steps to making western digital IDs happen and granting convenient access to your credentials for law enforcement. Happy for you to mark my words and call me out if it doesn’t happen.

Ideally, passkeys should be cattle, not pets. You should have more than one per account, saved to more than one password manager. Then it's fine if they're not copyable because you can get another.

Opinion from someone who's working on Passkeys at Apple and is very open and transparent about his work there (For many years already), which is rare for someone working at Apple. This makes me appreciate this much more.

https://mastodon.social/@rmondello@hachyderm.io/117428259125...

> Indeed, just now I generated a passkey using free and open source software, and then I emailed it to a friend, and now we can both access the same website using that passkey. At no point did I have to ask anyone for permission, not the website, not the FIDO Alliance; not even my friend, who kindly let me monopolize her time without objection. What’s more, I don’t have to type any numbers by hand to use a passkey; I don’t have to remember any magic words; passkeys just work.

This (before they go on to describe actual passkeys) sounds like object capabilities to me. Capabilities combine designation and authorization so if you don't have it, you can't use it. It's the type of security that we should be moving to.

Passkey attestation sounds like a nightmare for user privacy and for anyone that doesn't use a major corporate operating system.

passkeys are a website telling you they don't trust you to manage your own password, and they would rather talk to your password manager directly and skip the meatbag in the middle.

and the websites are usually justified in saying that.

Knowing how big tech works this will get forced down throats desired or not

A major concern raised in the article is along the lines of "passkeys have technical mechanisms that may disallow use in future".

That ... doesn't seem like a concern unique to passkeys, though?

It seems more like a policy rather than a technical aspect.

e.g. A website might decide they will only provide services if you upload a photo of government ID, or pass a verification where you show your face.

If it's software running on someone else's computer, you don't get full control regardless.

Passkeys are a pretty terrible UX on their own, in that you have no control over managing them . And every site has a custom experience.

Epic for example has at least 3 different ways to load the pass key e.g. username first, passkey first, username + password, then passkey. Luckily their app lets you in with Passkeys alone

Walmart prompts for username first, then passkey, then it sends you a verification code to your email address.

The issue is that every site has a random flow of username, password, oauth (then a few oauth screens), passkey, 2fa and so on.

Authentication has become absurd. None of this is making people safer. If sites are seeing less fraud reports, it's likely they are harder to detect rather than less frequent.

I learned lots of things about how messed up Passkeys are and there's a well known advocate online for them who keeps going on about how you can export them without ever mentioning that it's also possible for you not to be able to import them.

That's the kind of half assed communication that loses trust.

Passkey attestation is trusted computing.

The equivalent of 'owner override' is user access to all secrets.

As with TC, one could have all the user-protecting aspects without any of the user-limiting aspects, by implementing suitable owner override / by enabling users to know all secrets.

The attestion part only serves to strengthen to Google/Apple duopoly and it should be removed from the standard entirely.

There's also the fact that passkey storage is currently shit. Even the most expensive yubikeys can only store 100 passkeys. I currently have 700+ entries in my password store, and that's excluding the business stuff. Am I supposed to faf about with 8 yubikeys? Somehow labelling them so I know which 100 passkeys each one contains?

If you don't like passkeys the solution is very simple. Resist using them. As long as a significant minority resist and refuse, they will have to keep other types of auth around.

Hmm. Passkeys are advertised as secure because they are difficult to hack. And since they use the same API as hardware security keys, I can store passkeys on my YubiKey for critical infrastructure.

They’re secure, stored in iCloud, and can be used from any of my Apple devices. And if I need extra security, I can use a hardware key instead. What more could I ask for?

I understand why passkeys are being promoted so heavily. They’re secure by design. Otherwise, companies have to think about all the possible ways their authentication systems could be compromised. And even then, they can still get hacked.

Passwords are weak. People can be tricked into revealing time-based authentication codes. But passkeys? They just work. Your grandma can’t read one out over the phone or write it on a sticky note next to her monitor.

Of course they are, if Apple loves a standard then it contributes in some way to platform lock-in. Safari is configured to automatically upgrade user passwords to passkeys (no user intervention is required with the out-of-box configuration of macOS) as long as the target website adopts the necessary APIs. And just like that, you're in.

Once all the big players started rapidly adopting it, it felt like it wasn't a standard working in my interests. I've been dodging all these annoying "don't you wanna create a passkey" interruptions during sign-ins every time.

Never really cared enough to actually look deep into it to this was a good read. Appreciated.

I am a little confused because they make the difference between a "passkey" and a "security key". But I use my Yubikeys as passkeys...

Does it not count as "passkey" then?

Attested passkeys are a dream for Apple. While google is sliding down this slippery slope fastest (eg MEETS_STRONG_INTEGRITY to require security updates) Apple has the most to gain commercially, they must be salivating over the prospect of accelerating device replacement (and blocking Linux/android forks) driven by banks, streaming media and governments.

Passkey, as currently implemented, is not something I wish to use.

I have sign up a few for "get a feel" of what is going on.

but the implementation outside a few flagship website just sucks. It is infested with the "design by committee" disease -- too many options, almost impossible to implement correctly.

I'm not sure how common this is as I don't voluntarily use passkeys, but some platforms have a device manufacturer whitelist. OpenAI for example forces the use of hardware passkeys in some cases and seemingly determines this based on whatever name the device reports.

I'm not looking forward to when passkeys become even more forced upon us and you have to carry around multiple devices by different manufacturers because platform A and B don't support the same devices.

See e.g. https://community.openai.com/t/daybreak-does-not-recognize-t...

Can someone tell why the whole standard for authentication on the web is not just this:

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

Related:

https://news.ycombinator.com/item?id=49753211

I don't like passkeys (hawksley.dev)

853 points by ethanhawksley 23 days ago | 832 comments

TOTP is susceptible to man in the middle attacks. Passkeys are not. That alone is a solid reason to favor Passkeys!

Microsoft logins are automatically taking us through "creating passkey" and "failed to create a passkey" without any prompt to user or consent from user

I wish people would stop pretending TOTP is an adequate solution over passkeys. TOTP provides no defense against phishing, one of the most common ways people get compromised. WebAuthn (and passkeys) make phishing virtually impossible. If you want to convince folks not to use passkeys, you've got to at least recommend something with parity, ie fido.

> receiving a text message or email with a one-time code

This is less secure than pure username+password in principle because it gives an impression of greater security while actually delivering the important secret in plaintext. This can cause platforms to enable the higher trust features, or have additional confidence that someone is not an attacker, even when either one would be highly inappropriate.

TOTP does not have this problem since the secret is enrolled once by the account owner and then never communicated again, especially never helpfully to an attacker right when they need it.

> One use case is particularly intriguing to me. In principle, remote attestation can also be run in reverse, to verify that the server you connect to is not doing anything you don’t want it to be doing (such as stealing your credit card number, or keeping backups of the posts you delete). Sadly, to my knowledge, no major platform has ever implemented “reverse” remote attestation this way.

This is only possible if you've audited the code in order to approve it. In practice, this requires auditing the entire SBOM, manually, yourself, for every single platform release. Or deferring to someone else to do it. I expect this will never happen.

I haven't swapped to passkeys because every website seems to implement and use them in different/strange ways. There's still no standardization here. Also the notion of just wanting everything in my KeePass + have it all integrated is my goal, and right now, that's just not a thing.

Strong password + MFA is still the way.

This is an excellently written article & an excellent bookmark to keep saved & reshare in future discussions around authentication. It comprehensively summarises a lot of thoughts I had had myself about Passkeys, much more eloquently than I could have.

I am a big Passkey advocate, but like many things these days - as pointed out here - they are a double-edged sword that have been very effectively "poisoned" by the same groups responsible for much of the recent DRM-ification of a lot of web tech.

A close parallel of this is the EU's efforts to build "digitally sovereign" software but ending up increasing reliance on Apple & Google in the process[0].

https://github.com/eu-digital-identity-wallet/av-doc-technic...

There are 2 auth mechanisms I would trust my life to: unique, memorized passwords and physical keys. That's it. You really should not trust anything else for anything important.

I have always wondered why TOTP is always the “2nd” factor and not the 1st. The password should be the 2nd factor you opt into if you’re paranoid.

For grandma, include a Login with Facebook button.

The author gently notes what my current Passkey problem is. I don't know what "passkey" really is, because there is a huge array of "things" that "can be passkeys".

I still really like fido U2F. They are (relatively) obvious; they are (relatively) open - there are many third parties that support it; they can be done shareable (I know Trezor - which is mainly a crypto wallet - can be used as U2F with the same "seed" that you can share); it's much more simple to grasp. They also solve the phishing issue effectively.

I can't really grasp what Passkeys are.

I skimmed the article, lots of info. I use multiple Yubikeys with passkeys and feel better about the auth experience than any other solution thus far. When I have a negative experience I'll reexamine my usage.

The precedents for a site operator allowing only “approved” software are many. Passkeys doesn’t prevent that, and indeed offers a new way to implement it. The author argues that this is a trap.

I will never use passkeys, under any circumstances. My 25 year old GMAIL account could require one and I guess I’d just forward the emails and not log in again.

I love passkeys. 1Password handles them beautifully.

I'll accept passkeys as soon as the manufacturing, import, and sale of any hardware that supports attestation is banned.

TOTP is just as phishable as a password and offering it today is as much security malpractice as SMS.

For all their faults, passkeys/webauthn is the future and you can absolutely just use nitrokeys you control, with backups, as you like.

I have seen at least half a dozen people leave random services because "Facebook now demands my biometrics!!"

Which is code for "Facebook suggested a passkey so I could log in with my fingerprint"

Tech illiteracy 1-0 Big tech

I started using passkeys via the browser (chrome) and OS (MacOS) - then my laptop died.

Found out passkeys were a trap and it took over a week to recover.

Now I will only use 1Password for passkeys. Not perfect, but at least portable.

The article had a lot of depth that I couldn’t get to because it’s primary theme seemed to be “I want to illegally share paid services with other people and passkeys don’t let me do that”.

TOTP are stored on the server without any salts. You get TOTP key, you can generate TOTP codes.

So TOTP only targets the situation that user account is compromised. It doesn't help you if the server gets compromised.

> Intended audience: non-technical citizens of the web

A good description of the design principles behind passkeys, actually.

> They can use passkeys to prevent you from running unapproved software.

Nope, that's attestation in general; passkeys are not required for that. Passkeys have nothing to do with secure boot, for example. Which version of manifest and adblock chrome/edge supports also has nothing to do with their passkey support. Nor does the possible mandatory age-verification flag we might soon get built into our phones: it'll definitely use some kind of crypto but that can still be one in other ways than with passkeys.

Passkeys are a kludge for many reasons, but let's be careful with our terminology.

The way passkeys have been implemented is an absolute travesty. If it were one passkey per device, and 2-factor was still being enforced, I'd support them. But

But, instead, we end up with 1 passkey per device (potentially per web browser) per website -- and some websites do not allow any other kind of auth. If you lose that phone, or wipe it, move on, or it is compromised, now you can't login to your account anymore?

There is literally no reason for all of this nonsense.

Websites should be providing a challenge, your device should produce a tweaked key based on the domain, sign the challenge, and that should be it. You have one root key per device.

A standard API to register new passkeys for new devices.

Require two factors Password + passkey, or two passkeys.

No transferring private keys between devices.

Requiring 2 factors per website per user, potentially per device, is far more complexity than most people are capable of dealing with.

And I really do not like that my phone# and email# are now de-facto second factors on everything.

I'm just waiting for my TKey to support FIDO2/WebAuthn.

I don't trust using anything else that I can't backup myself, remote attestation is trash.

I tried using a passkey to log in to something and it gave me an error and I simply didn't care about trying to fix it. So passwords it is for me.

Honestly I don't care about any of that. From my perspective, passkey = phone + app required. That's already a red flag big enough for me to not use them. If I put on my engineer hat, another problem I see is that most services seem to not be competent enough to implement it in a non-broken way.

Very informative. I do not currently use them. Existing solutions cover me.

Password managers drive me furious. I hate them. They don't work and I don't trust them. I've lost count of the number of times I thought to myself "Thank god I didn't trust the password manager and memorized the password." Many times, the password manager doesn't work properly with a particular website or scenario or I need to remember the password for a different form (not web browser-based).

Makes sense, requiring your phone number to send a OTP is another way to get another bit of data about the audience.

First of all, what’s wrong with the author, if you have to read through 14 paragraphs to finally reach the point where they actually write on the topic directly.

Second, I think the article is really silly. If they are concerned that eventually service providers might restrict passkey authentication to authorized passkey providers, what prevents them from disabling password/TOTP authentication? That’s just silly. I’ll use passkeys while they are convenient. If service providers start disallowing my passkey provider, I’ll either switch to password/TOTP if that’s possible or just stop using the service whatsoever. What’s the big deal?

Thinking about passkeys from this angle, how big is the danger of using them for fingerprinting?

> What’s important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys.

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.

You can put your passkeys in a file if you like. I do for my personal agent. It's logged in on a few sites and it uses passkeys. Saves a few steps when it's using the browser to navigate them because it doesn't need to input credentials except for the first time.

Agreed. Working on a fix for this. Will publish in few days.

Hard disagree. Phishing is a major problem. Passwords+OTP are phishable[1]--passkeys are not (the signature is bound to the domain and cannot be forwarded). That alone makes passkeys worthwhile for the vast vast majority of consumers. This is not a theoretical threat model. You simply cannot realistically expect even a savvy consumer to be able to save themselves from phishing all the time. One mistake and they are fucked.

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.

Trap or not, I much prefer passkeys over 2-FA. Phone numbers are insecure and vaults are too easy to lose.

Maybe I've had too much coffee and I'm impatient, but this kind of article bugs me. It has a tremendous amount of valuable detail but you don't learn why Passkeys are a trap until you've read like 2/3rds of it, and it's impenetrable to anyone who isn't a CS professional of some sort.

Add a TL;DR at the top perhaps.

I understand the shortcomings of pass keys but I feel the tone of the article is a bit tin foil hat.

Especially this line: "I believe this was done in order to deliberately confuse users and encourage them not to look too closely at the fine text." Don't attribute to malevolence what you can attribute to incompetence

A lot of people have said there are pros and cons to any authentication method. Pass keys have drawbacks but they also for a lot of advantages.

TOTP has always felt incomplete to me. The key is right there unencrypted in plain sight.

that was an eye opening read. thank you.

tl;dr

"passkeys" is an ambiguous term that could be used to sugar coat "remote attestation"

Thus, for complete information on the pros and cons of "passkeys" search for information about "remote attestation"

It's still possible to buy "modern" computers without a pre-installed "cryptoprocessor", i.e., "TPM"

I have one. I have the option to add a TPM if I want

Letting someone else store and access data on your computer, e.g., in a "cryptoprocessor", should be always be _optional_

There’s so much FUD out there about Passkeys. They are barely any different from the keys you use to push to GitHub. It’s all going to be okay.

Yes, they have some window dressing and opt-in features that extend the basic concept of asymmetric key pairs. Attestation is only in the spec to appease some large enterprise users for very specific scenarios. Signature counters are in there too, but since Apple decided not to implement (which I’m fine with), they are essentially irrelevant in the general case.

In practice, Passkeys are really quite simple.

We can do this, people. We can move beyond the era where poorly protected password databases are handed around like candy.

>>> Two-Factor Authentication (in particular: receiving a text message or email with a one-time code), and later came the more robust system of Time-Based One-Time Passwords (TOTP) – in common parlance, “authenticator apps.”

I stopped reading after that. Obviously this guy doesn’t know what he is talking about or why that sms and otp are just worthless more or less if you care about security. They are actually loopholes in security. If you can use passkeys you would want to make sure that your stupid service provider(I.e Google, bank etc) is not being stupid to fallback to otp or sms crap.

    > In fact there are many different things called “passkeys” and the FIDO Alliance has intentionally named all of them the same thing. I believe this was done in order to deliberately confuse users and encourage them not to look too closely at the fine text.

As usual for an article critical of Passkeys, this one, too, is total nonsense.

> Mozilla wants to avoid having to die on any particular hill.

lol. lmao even

There are some truths in there (attestation exists, passkeys are complicated), but in general, the article strikes me as bad faith.

Various dimensions (copyable vs non-copyable, transferable vs. non-transferable, hardware bound vs. software only, attestation vs. non-attestation) are presented as if they all exist as distinct specification or implementation properties, yet at least half of these don't, at a first glance.

"User-Present vs Non-User-Present passkeys [...] Both kinds exist.": Nope, all WebAuthN credentials require user presence verification:

> requireUserPresence

> The constant Boolean value true. It is included here as a pseudo-parameter to simplify applying this abstract authenticator model to implementations that may wish to make a test of user presence optional although WebAuthn does not.

"Transferable vs Non-Transferable passkeys [...] Both kinds exist.": There's no such property in WebAuthN or FIDO. Passkey implementations may or may not implement the optional password manager migration flow, but the website has nothing to do with that.

"Hardware-Backed vs Software-Backed passkeys [...] Both kinds exist.": Also no, or rather, this point is redundant with "Attested vs Non-Attested passkeys": A non-attested passkey can tell you what it wants about being hardware backed, so they're effectively the same property. The same applies to "Copyable vs Non-Copyable passkeys [...] Both kinds exist."

So let's unpack this statement:

"This means Twitter (formally X) can say to you, “sorry, we only accept the User-Present User-Verified Non-Copyable Hardware-Backed varieties of passkey here."

User-present: redundant, as all passkeys are.

User-verified: This part is true. Sites can choose to demand this, make it optional, or discourage it. Quite reasonable, given that the optimal value probably depends on whether there's also a password being entered, i.e. whether the passkey is supposed to be a single factor (possession of/access to some device) or two factors (being able to authenticate to that device biometrically or using a knowledge factor, usually).

Non-copyable/hardware-backed: Realistically, a site won't be able to make you use attestation, as that would mean excluding the by far most popular implementations in the wild, i.e. Android and iOS's native solutions. By extension, they can't enforce anything about copyability either (or to be precise, nothing they can't already with user agent sniffing and device fingerprinting).

So what's left? Websites can effectively decide whether to require/use passkeys for two factor or single factor authentication. Doesn't sound as scary to me anymore.

All in all, the article makes a few valid points, but arrives at them via heavy handwaving and a lot of motivated reasoning to back it up. This article could have been 70% shorter and would have probably made a stronger or at least equally strong and more accurate point. Generally, I really do agree that there are many possibilities for user-hostile traps in WebAuthN, but if we want to successfully navigate them, critics need to step up their epistemology. The specs are really byzantine and confusing enough.

What is the tl;dr of this article.

[dead]

[dead]

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

Passkeys are crap, use them if you are stupid.

- Never underestimate the effectiveness of school yard persuasion.

> TOTP is a great solution.

TOTP has a fatal flaw: it relies on the human to not paste the number into a phishing website. You can do a lot of bank transfers or whatever, in seconds, with a valid session derived from a phished TOTP.

Characterizing it as a sticky note on the desk is extremely dishonest.

This screed is simply BS:

> What’s important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys

Passkeys are _by_ _design_ representable as clear-text strings. You can export them and sync between devices. I'm using BitWarden with a self-hosted Vaultwarden for the server-side to do that, for example.

What exactly is the trap here? Most websites telling you to use google authenticator or lastpass doesn't mean there is an evil cabal out to get you!

    > Intended audience: non-technical citizens of the web

This article goes down a slippery slope and comes to a conclusion I think is pretty unsubstantiated and dramatic. Passkeys are not a trap.

Curious if the author can provide examples of things we ever had ultimate control over?

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.

I just got a LLM to write a user script that blocks pass key requests:

    (() => {
      // Sites check `window.PublicKeyCredential` to decide whether to offer passkeys.
      try { delete window.PublicKeyCredential; } catch (e) {}

      // Block passkey requests from sites that skip the check. Password/federated credentials still work.
      const creds = navigator.credentials;
      if (!creds) return;
      const refuse = () => Promise.reject(new DOMException("Passkeys are disabled.", "NotAllowedError"));
      const origGet = creds.get.bind(creds);
      const origCreate = creds.create.bind(creds);
      creds.get = (opts) => (opts && opts.publicKey ? refuse() : origGet(opts));
      creds.create = (opts) => (opts && opts.publicKey ? refuse() : origCreate(opts));
    })();