Banks want attested terminals and for the customer to pay for them. An even better deal for the bank than ATMs, kind of like of how cable TV boxes enforce DRM on the customer and are paid for by the customer.

Any site/service could easily implement their own proprietary solution to force compliance around usage of said service. Whether they can abuse Passkeys or not is irrelevant. If the service does something inappropriate, you can stop using it and, if necessary, build a competing service that is not abusive.

To suggest that people should stop using Passkeys over this is throwing the baby out with the bathwater. All of these features of Passkeys are appropriate in a given context. The only concern is where a service that might not need/justify "high security" Passkeys starts demanding them anyway, and no-one is forcing you to use said service in that case.

So they're gonna stop supporting Apple users?

Can someone more familiar explain the end goal?

Would a website want you to have to use Apple Passwords to guarantee that the account you're creating is connected to an Apple account, and thus making it more likely that you're a real, non-anonymous human?

edit: Why not just require "Sign in with Apple/Google" if that's the goal?

It's not a conspiracy theory when it's just another instance of the patterns big tech has overtly used against us for 20 years now. We see, every day, a frog being stung by a scorpion when crossing the river. So we don't let scorpions ride on our frogs any more. No conspiracy theory, just pattern recognition.

"I'm different!" says this particular scorpion - yeah yeah, I don't believe you.

You are saying this as if these companies don't care about CVR or compatibility at all. The reality is that most companies are extremely conservative about pushing you to change your authentication method. Here are my observations, as both a user and an industry insider:

1. Many services have old users with passwords that predate password-strength meters (or their ill-conceived brethren: password complexity rules). The service provider knows these passwords keep falling, and the cost of having to deal with stolen accounts is very real: customer support calls, reimbursements and investigation. But I've rarely seen services that force users to upgrade their passwords (even though it's a very easy solution). Whenever I've offered doing this myself, it was always shut down (either immediately or 3 years down the line) by a myriad of seemingly unrelated stakeholders.

2. To go further than this, companies can also know for certain that some credentials have been leaked by looking at password breach aggregators like Have I been Pwned and forcing users with affected accounts to change their passwords. That too, is rarely done.

3. 2FA (with SMS or TOTP) has existed for ages now, yet very few major non-financial services have made 2FA mandatory by forcing you to register an authenticator app or a verified phone number[1].

4. Webauthn was available in Chrome and Firefox in 2018, and got pretty widespread support by 2020. The "Passkeys" brand was not a thing yet, but the basic functionality was there and both hardware and software support was quite solid. It still took several years for services to even start offering Webauthn to users, beyond small and limited trials. The rationale was simple: UX around Webauthn was still rough, syncing and transferring credentials were still unsolved and the worst part was "What do we even ask the user to do?". The broad concept of passkeys is extremely confusing, but the non-concept we had before was far more confusing. Supporting Webauthn back in 2020 would have given tremendous security benefits for power users who could have understood it and deal with the rougher UX back then, but nobody wanted to take the risk of regular users setting up a passkey, losing it and locking down their account.

5. Now that passkeys are being supported by more and more services, you still don't see them being pushed very hard. Passkeys are great for the service provider, since they just kill a big category of security incidents, but even then you're see pretty conservative adoption. And I've never seen a single service forcing you to use Passkeys.

My point in all these examples is that most companies are extremely conservative here. Forcing users to do something that might confuse them, break their account or frustrate them is risky, since you may lose a very real chunk of your customer base. Sometimes you have to do this, the costs from keeping the old way or the benefits or forcing the change have to be high enough to justify that. Think about how long it took for companies to drop support for IE6. The cost was high, but as long as it still had a sizable market share, it was hard to do. Google was probably the first major company to take steps towards killing IE6 support, and this was famously entirely bottom-up, and was done by engineers either hiding it from their bosses or tricking them[2].

With this trend. I personally find the scenario where non-copyable attested passkeys are forced on everyone unlikely. OP keeps mentioning Netflix, but streaming services are a rather special case, most service providers would get very little benefit from restricting users to an attested non-copyable passkey. Why would they risk all that friction for... nothing at all?

The more real risk with attestations (and we're already started seeing it) is that some services (namely banks) will use attestations to limit you to use their own shitty app instead of using a proper passkey.

---

[1] Keep in mind I'm only talking about companies that already had password-based accounts without 2FA. Companies that started out with a simple username and password are rarely forcing their users to add 2FA. The farthest they generally went is sending you an OTP code or link on a verified email address they already had, and this is usually only done for sensitive operations, a new browser and/or a suspicious location.

Email OTPs, notably, aren't 2FA by definition, since your Email address might be only password-protected, and at the worst case (and excruciatingly common) scenario it might be sharing exactly the same password as your service. Companies would love to have all their users using a stronger solution, so they can stop having to deal with all these pesky credential stuffing botnets, but not at the cost of losing a non-negligible portion of their customer base.

[2] https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

The "there is something wrong with you if you are at all off the beaten path" has cropped up a lot more for me recently; two examples both from 2026:

1. You can't use Firefox with our website (when I got this popup, I thought I had been transported back in time 20 years, but with Chrome substituted for IE).

2. You can't sign up for accounts with an e-mail from a "custom domain"

2a. I ran some tests; it's the domain itself, not the host, so e.g. foo@gmail.com is allowed but not a foo@somewhereelse.com, even if hosted by google).

2b. After a bit of back-and-forth with support: "No, we won't tell you the list of allowed domains, but gmail and hotmail both will work."

This is a great comment, and yes, the entire industry seems to keep doing this over and over.

My computers and devices feel less and less like tools under my control and doing my bidding, and more and more like something controlled by faraway tech companies, to do their bidding.

Oof, this comment convinced me to go from loving passkeys to "maybe I should be careful". However, I don't think these are technological issues, I think they're policy issues. We need to vote for freedom of computing, and against corporations doing whatever the hell they want.

There is no truly secure options for this, unfortunately. Passkeys have to be online to enroll additional keys, so any kind of software or smartphone solution is going to depend completely on cloud sync. Any form of offline copy stored in a physical safe will quickly be outdated.

It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.

Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.

[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...

What if they meant a real safe? The big metal kind.

> I store mine in my vaultwarden.

Can you export it from there? My main gripe with passkeys in 1Password is that seemingly you can't export them, unless you export it to "someone else", which isn't clear if that someone can be just "you".

Silicon Valley suffers an utter lack of respect for the user, it's user-hostile.

I remember that comment, it's perfect.

TOTP is this decade's "just have a better password", and we all know how well that went before.

> solved the problem with text messages

Especially considering how easy it still is to do a SIM swap.

There is a reason that banks send increasingly strident text messages that they will never ask for this code.

For their bank accounts, search tech support scam on youtube to see how that goes. Btw passkeys do nothing to stop this, they probably make it easier since grandpa doesn't have to search for a password or unlock a password manager to send his money to the scammers.

Why are they being MITM'd? Because some people want money and don't mind breaking laws.

Because it prevents an attacker from stealing the password. It's both extremely hard to "steal" a passkey, and to phish a login from one. Neither of those are true for passwords, and TOTP only partially solves the stealing part.

Passkeys aren't solving for security nerds who like portability and have 30 character long passwords, they're solving for grandpa who will happily read their bank's 2FA SMS to the "bank" over the phone. The FIDO alliance has literally billions more of these users than they do users who know what hardware attestation is and how it impacts their auth workflows.

So companies can use passkeys and set policies around what hardware they're stored on. IMHO, not particularly useful or desirable for everyday Internet users, but really nice if you have specific requirements.

Passkeys are the consumer implementation of PKI to solve these problems.

There's functionally no alternative for consumer logins, and certainly not one that doesn't require learning what PKI is. "like SSH with PKI" is a bit "draw the rest of the owl".

> this can be solved by your password manager it just has to check the host and the certificate of the login page

Which is exactly what Passkeys does. And it also has built-in functionality to prevent any kind of "Oops! We changed our login method, just ignore the warning and retrieve it manually." social engineering, which a user would often genuinely see when random services move their login page to a different url.

The vibe coding attempts I tried weren’t passwordless. For the actual passwordless internal system, AAGUID is checked so only whitelisted password managers are allowed, “something you have” hardware keys are not accepted. I know AAGUID can be spoofed but employee somehow hacking part of the process just to register a hardware key against policy isn’t really part of the threat model.

> 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

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.

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.

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

Yeah and neither will anyone else!

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.

> the wrong apple pay card

Expand on this? Haven't heard of this failure mode.

You know what’s a great way to get me to not read something? Shitting on it immediately and making it seem like the articles just going to be another pointless rant.

The title put me off completely.

I’m tired of people shitting on everything. Especially without offering any advice on how to improve things. It’s exhausting to read. And apparently it’s not even the point of the article. So why is it the title?

Very very strange choice.

Sure, I think your logic makes sense, and I don’t want to overemphasize complaints about headlines.

Regarding how I feel about passkeys after reading your article, logically I am reading what you wrote and conceptually understand the trap, it’s just hard to wrap my head around what kind of situation would cause this trap to “catch” me so to speak.

I.e., the upside is real and immediate, the downside is theoretical and tied to future uncertainty.

Want to guess how many non-tech individuals save passwords in Chrome on desktop and in iOS on their iPhone?

It's not that hard. Chrome and something else. (Such as iOS.) A different kind of backup authentication method would work too.

if I can't have two password managers for redundancy then none it is.

For starters, AAGUID already reveals the passkey provider. It can be spoofed without attestation, but good faith (debatable choice of phrase obviously) users already reveal more about themselves, a fair bit more depending on who you ask and how unusual the choice of passkey provider is.

An uncompromising minority has surprising power. See Nassim Taleb's idea of assymetric minority rule.

Passkeys are only one kind of 2FA.

Yes, banks are particularly bad at this because their threat model is strong.

My bank required installing an authenticator, but apparently recently they've allowed SMS based 2FA. It seems users complained/resisted and they had to accommodate them. Maybe you should give feedback to your bank. Be the uncompromising minority.

I think 2FA is fine and a good idea, but I agree with the author that passkeys seem fraught as designed.

If you also support TOTP and physical security keys as an alternative to passkeys, that should be enough to provide a stable long-term alternative for users of FOSS devices. And of course, RP-side you can choose to never require the remote attestation flag to be set.

Convenience is precisely the thing that big tech established tech platforms want to reward their users with to keep them around. The undeniable convenience of passkeys didn't have to come with a standard that is threatening against unattestable devices like my Linux phone. But it does, and that means passkeys are a way that the industry can discourage people away from using non-Google/Apple/Microsoft-approved devices.

Ah! Are there any that require that?

Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.

> far more difficult to use in practice

I guess I am envisioning the user agent doing all of this. You go to a site and create click account, your browser shows a pop-up: "<website> is asking you create an EasyAuth account. Would you like to create an account on this site?" If you click yes, then the user agent does this in the background:

website: Sure you can have an account. Use this token <token> once and this ID <user_id> forever.

me: Ok, here's your token <token> for ID <user_id> and my public key is <public_key>. Signed, <digital_signature> to prove it works on my end.

Maybe generating a unique public key for each website is not substantially better than generating a password, but at least a signature cannot get stolen on the server side or in transit. You wouldn't have to change your public key if their database got slurped.

Passwords also aren't standardized, so they are pain to generate (special characters required or disallowed?). They don't reliably autofill into a website. You still have to go through a manual flow to login; user-agent doesn't just keep you logged in. I guess I would be fine if the user-agent knew how to authenticate me to every website.

Maybe this is what the passkey system was before it got designed-by-committee'd into oblivion. I am just always amazed by how complex authentication is when the user-agent should be able to handle this rather painlessly.

> Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.

While that is an option, I've been using passkeys on Amazon since 2023.

> Phishing is a major problem, but it happens less than you think.

Bullshit. Literally number one attack vector.

> Password managers are also checking the domain before supplying a saved password.

Password managers are not anywhere as ubiquitously used as you'd think. Even if you rely on password managers, you encounter scenarios where the website relies on a different domain that's not paired appropriately. Some "legitimate" mofos like Plaid used to ask password for third party website. Consumers don't see a password manager failure to fill out a password as a security issue. They see it as a routine password manager failure.

Your "SSH cert" option, in a consumer package, is effectively the passkey.

Yes you get me though my argument is the inverse; possible to assert any claim with abstract philosophy like "ultimate control"

And our agreement doesn't stop there. No views I encounter anymore at my near ripe old age of 50 are new anymore

Social conservatism whittles value statements down to a finite subset of cause-effect

Take HN for example; run a trend analysis on the comments going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth

Religious people are not the only ones who live in rhetorical fantasy

End of day the provenance of any socialized idea is some rando I have no obligation to march in lockstep with; physically or philosophically

Sure, if they are actively pushing for that, it's bad. But otherwise passkeys are OK. It's a neat way to use private / public key pair instead of a dummy password.

> That's not the intention of the relevant standards.[1]

Sigh. IT LITERALLY IS.

The name "passkeys" itself means "exportable keys":

https://fidoalliance.org/passkeys/

> When a user creates a passkey on any of their devices, it gets synced to all the user’s other devices using the same passkey provider that is also signed into the same user’s account. Thus, passkeys created on one device become available on all devices. > Notably, if the user gets a new device and sets it up with their passkey provider, the user’s passkeys are synced and available for sign-in on the new device.

The resident keys (the ones created by platform-specific TPMs) are not passkeys. And they had been standardized _before_ the passkeys.