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.
> at login time it's not possible to retroactively require attestation if it wasn't obtained during registration.
Of course it is, the site will reject the passkey and require you to create one that is attested.
> Are Netflix and Twitter currently requesting attestation when people register passkeys, and rejecting the registration if the user declines the permission prompt?
They could start tomorrow.
> a hypothetical and unlikely scenario.
You have not been paying attention, that scenario is where this whole thing is building towards.
> If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out
It's going to be the banks first.
Why called out, it's all for your safety, to make sure you are not using an insecure client that might leak your data.
In Japan, this is already the reality. The FSA required brokerages to implement passkey authentication, and the effect is that it's no longer possible to have a brokerage account without a passkey. (Some brokerages, like Nomura Securities, will offer two separate client portals. The portal with money and trading-related functionality requires a passkey).
The thing that sucks a lot is that brokerages seem to also restrict the allowed software/hardware. Don't know the details, but none of my FIDO2 hardware keys were able to be used. I consistently use these hardware keys through WebAuthn, so I was surprised when my brokerage explicitly told me my hardware key is unsupported and I must use either Windows Hello or the iOS Passwords app.
The FSA's official explanation for mandating passkey implementation is that people kept falling for phishing attacks, and the attacks were getting too sophisticated thanks to "AI" or something.
They could also start requiring you to mail a DNA sample to create an account tomorrow.
> It's going to be the banks first.
The same banks that (in the US) largely don’t even systematically use 2FA for online banking logins and completely ignore 3DS for card payments? Attestation usually requires customers to buy and carry extra hardware, so I highly doubt it.
The only place I’ve seen mandatory attestation is in enterprise IT, where admins can supply and enforce usage of e.g. Yubikeys.
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.
While not directly related to passkeys, CAs require private keys for code signing certificates to be generated on FIPS-certified hardware security devices, and use attestation to verify this.
We have more than enough technology in browsers to allow JavaScript reading live video from your webcam. A website could use that so they can see if you’re looking at the ads enough.
They could start doing it tomorrow. They just have to flip the switch.
I am very hopeful that passkeys will fail overall. They've definitely forced a lot of adoption quickly, but I think also that a lot of people have no idea what they've signed up for, and there is a decent chance of a quiet, slow retraction in the long run. Their death will be well-earned by just the attestation alone - one hundred percent, in my opinion. I tell my loved ones to not use passkeys simply because they're much more likely to accidentally run into scenarios where they lose the device. I'm not going to stop. I encourage everyone to do the same.
I still am using passkeys for some sites because they otherwise force you into insecure processes like SMS-based 2FA with implied humiliation rituals, but banks are the worst offenders and they seem to like discriminating against open source password managers, so while they are not using attestation I am still patching my password manager to lie about its identity. Hopefully this will become more common in the future.
Also worth point out that Apple consumer devices intentionally do not support attestation at all, and only support it for devices under enterprise management. That's still a dominant enough number of devices in the US at least that a consumer site seems unlikely to want to disable/break logins for all iOS and iPadOS users.
Even stronger, they used to support it, but now no longer do, so we know for a fact that Apple knows how to do attestation, has already expended all resources necessary to implement it, but has then actively decided to go into a different direction (i.e. that of cloud synchronization).
I believe Android still has the option to use hardware attestation, but that automatically opts credentials out of cross-device synchronization, but Apple's veto alone is enough to make attestation non-viable.
If this can't make the "WebAuthN implies mandatory attestation!!" critics update, I wonder if anything can, and how useful their criticism still is.
Be that as it may, they can still roll out the passkey attestation requirement gradually, -- "flip the switch" just a few thousand users at a time -- so that at no one point in time is there a large blip in users. Truth be told, tech platforms don't even really need to measure what portion of users' devices support remote attestation, since the overwhelming majority of devices will support it. They just need to know that users are passkey-capable in the first place; once enough users have passkeys in any form, they can start requiring remote attestation.
As for the browser permission prompt: Firefox simply warns you that the site is "requesting extended information about your security key [sic] which may affect your privacy." [1] It does not make it at all clear to the user that what's really happening is that the website is gating acces behind a specific approved software stack. If I use a non-widely-used OS or device, what website is going to approve its attestation credentials?
Sorry, bit this is just the standard "boil the frog" playbook that tech companies always use for user-hostile features. It's usually:
1) There is this new entirely optional feature, but it's not relevant to you, so feel free to ignore it.
2) The feature is now active by default, but no worries, there is a simple button for you to opt-out.
3) The feature is active by default, but because we value our users, there is an option in the advanced settings to deactivate it.
4) Our data shows that 99.9% of users activated the feature, but if you belong to the handful of diehards who still refuse to use it (rolls eyes), you can use this obscure command line flag or about:config entry to turn it off
5) Managing opt-out infrastructure for the feature has significant maintenance and security cost that we feel, we can no longer justify. Therefore, effective in three months, the opt-out flags will stop working and the feature will become mandatory. According to our metrics, this will affect 0.0001% of our users, so no disruption is expected.
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."
> The feature is now active by default, but no worries, there is a simple button for you to opt-out.
How I wish this were true for (US) banks. They usually force whatever new hell on you they just came up with without asking, or in fact even telling you about it.
The most bizarre instance I've seen so far: "We have unilaterally added this phone number we believe to be in your name (surely cell carriers have better KYC than we do!) to your account as the only SMS-OTP authentication method and are choosing to disregard the one we've had on file for years since it's an evil VoIP number. Please do not contact us again without access to the former number for authentication."
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.
Having read the very complicated WebAuthn spec so I could implement an RP, and participated in too many stupid debates about attestation like this one: multiple, simpler specs focused on specific use cases would have been better than a single gargantuan spec that tries to do everything.
There's also another scenario - annoy most users into using passkeys, then say "well everyone is using passkeys already, we don't need passwords anymore", and _then_ slowly start requiring attestation. Really I'm not one to look for conspiracy theories, but with the recent pushes around e.g. chat control, it's not that far fetched to assume someone pushes for more control over users' accounts
This is the obvious endgame. Right now you have people who will say that passkeys are unphishable so we should switch to them. When you point out that people will lose their devices and credentials they'll then tell you can just use account recovery emails to get back in. They actually argue you absolutely need an iron clad door with a guard employed by some one else to protect account on some random website (that the website decided was precious, not you) But that's OK because they left a same old shoddy back door open in case you can't get in. So why even bother? Because that isn't the point. The plan is to remove the back door after enough people are trapped, they just need to keep the screaming to minimum while they get everyone in there.
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?
I share that concern somewhat, but I think your point stands even better without suspecting some shadowy attestation cabal.
The US has thousands of banks, and nobody tells them how to authenticate their customers – they just all end up doing the same few horrible things, since nobody ever gets fired for doing what all their peers do (and maybe a little bit more to be sure).
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.
> That's not a good enough reason to recommend TOTP instead
In what way is TOTP an "instead"? My understanding of passkeys is that they basically replace the username/password combo, but do not provide any kind of second factor. I know at least one service (I think Amazon, but I'm not 100% sure) still requires TOTP when logging in with a passkey from an unrecognized device.
TOTP also does not imply a second factor, it's just a time-based password calculated from a shared secret that can be stored anywhere, for example in your password manager alongside the username and password. And worse than your password, of which only a hash should be stored at the service you have an account with, they store the shared secret too (which can thus be leaked from their side), so TOTP is never fully hardware-bound, it always exists in at least two places. Passkeys _can_ be fully hardware-bound, with the secret only existing in the secure chip of your phone or hardware security key for example, not at any moment in its lifecycle exposed to user, service or potential attacker.
> Amazon (..) still requires TOTP when logging in with a passkey from an unrecognized device.
I noticed Amazon does that and it annoyed me greatly.
My understanding is that the passkey branding is specifically for copyable, user-verified keys. So the second factor is the biometrics (or equivalent) of your device. But yeah there doesn’t seem to be consensus yet about still requiring TOTP with passkeys.
Some how the Passkey topic comes up again and again. There is not much of a background information about the Author so its really hard to take that into context. Without knowing the agenda its hard to say anything concretely however most of the information presented is twisted in certain ways
A lot of people are aware of public key cryptography or asymmetric encryption, its already supported as identification & authentication method in sensitive places via MTLS. The whole idea of MTLS is about the server verifying the identity of the client and one of the core concepts is validating that the client certificate is issued by some Certificate Authority that can be trusted by the server. Its Phishing resistant, meaning some one cannot trick you into giving them the your credential that they can use by accident. The client certificates could be baked into physical devices (PIC, CAC cards) or Digital certificate on your machine. MTLS is used universally for machine to machine communication, however there is a certain degree of complexity so its not used everywhere for user identity.
1. FIDO is trying to leverage the same concept and trying to make it bit easier for use compared to MTLS. The core idea is to just use it for authentication not identification. It allows the user to authentication as long as the client can prove that they have the private key for a corresponding public key
2. Passkeys were/are target for Enterprise/Workforce users. When a consumer account is hacked the impacted user is just the consumer, whereas when an Employee account is hacked the entire company is at risk.
3. Passkeys/ (WebAuthn+CTAP) have been there for a while. Its still still evolving and everyone (platforms, Browsers, OS, Password managers, IDPs) wants to get something out of it which keeps on making it more complex
Since the client/authenticator is storing the private key, its important to ensure that they are doing it in a uniform and secure way. The authenticator implements a protocol called CTAP and they are supposed to conform to certain tests. The attestation is a means to ensure that the authenticator is doing the least minimum from security perspective.
Personally I do not like the idea of centralization, however as long as the path to attestation for different passkey providers is not locked I would say the attestation is a part of security.
At the same time the things I would worry about would be if the Authenticator provider starts generating a unique attestation for every user in customer identity space (its almost 0 cost in case of software based authenticators). A unique certificate for every authenticator instead of a batch one is where the privacy would be leaked, its akin to fingerprint. Some big companies are already doing it for their employees, thats a valid use case, employees unfortunately do not have a privacy when they are acting on behalf of the company
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.
You can put your passkey in another safe. I store mine in my vaultwarden. You can also do keepass with a plugin. You don't have to store it on your phone.
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.
Right, but... I can already store my credentials in a password manager and enable MFA. I understand the pitch, but Passkeys seem to buy me very little as a user and add significant brittleness.
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".
Same for me.. I don't want my login information to be tied to a particular device, or device vendor. TOTP is a clear winner in all of this. Minor inconvenience, but highly secure and portable.
A password manager solves this problem. I use 1password but there are others, including open source solutions. Passkeys for me are by far the most convenient form of MFA-based authentication.
Silicon Valley suffers an utter lack of comprehension of the concept of consent. As another commenter pointed out some time ago, if we were in a nightclub they'd be the creepy guy that keeps coming up to you asking:
> 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.
For any given Passkey-enabled service you use, you can have multiple Passkeys - ideally one per device, and it doesn't prevent you from also authenticating with another method, such as username and password.
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 sort of started skimming when the article was saying industry solved the problem with text messages and TOTP. I think there are several arguable problems with Passkeys as implemented, but to argue TOTP is equivalent is going to leave lots of people vulnerable.
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.
If the credentials get stolen from a website database, they’re useless for every other website on earth. No matter how poorly they’re stored, it’s just a public key and is not useful. Hell, they can get code executing on the webserver that collects full login information, and it’s not useful.
Passwords always require full transmission. Hashing for storage requires a proper implementation, which we’ve seen does not happen. 100% of the time. There’s a reason hackers are still stealing passwords from websites after three decades.
Passkeys solve that. Nothing else available to the average user does.
>There's a lot of assuming bad faith on the part of the FIDO alliance
Yeah, it's just a bunch of "big company bad!"
Yes, Google and Twitter and Yahoo are just trying to get your data and sell ads, but I fail to see how Passkeys furthers that specific goal. Even if these companies have bad motivations in certain parts of their business, they all have an incentive to make accounts more secure (to reduce fraud) and improve the user experience (to increase engagement/happiness)
I noticed that too. This also seems like a bit of an insult to the intelligence level of the average person. It’s precisely because attestation is a nuclear weapon that I doubt one of the big three will try it outside of their own specialized credentials. If someone tries to change ecosystems and finds that they’re going to have to reset all their passkeys it’s not going to take long for them to tell all their friends that passkeys suck and not to use them. This instantly kills adoption.
Furthermore, the rest of us are the people at the companies implementing passkeys. I did an implementation recently, didn’t require attestation, and can’t imagine why I ever would.
If we’re at this level of trust for all of FIDO, why aren’t we at legislative centers doing something much more dramatic about it instead of navel gazing about how we’re the smart ones who have recognized FIDO’s next big trick? How is attestation the problem here?
Why is your grandpa or fictional billions users being MITM’d?
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.
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.
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 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.
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.
We don't need attestation and most of the data bits. Apple consumer devices don't support attestation. Only Apple enterprise managed devices do. It's a paranoia tool for big enterprises with strict device management requirements. Apple has a lot of good reasons to believe attestation is a privacy violation for consumers and seems likely to keep up the good fight in making sure it remains an enterprise-only tool.
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.
I think the real issue is that it's all about tracking. It's another level of spying on people, data being mined, people being locked in somehow someway so someone somewhere else can have an increased level of precision in some floating point number in some algorithm that is being used to grind the joy out of human existence in exchange for money being moved from one incredibly rich consortium to another, the animus of cpr on a dead god for a dying race.
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.
1Password suddenly offering to save passkeys without mentioning that they can't be exported to other apps (but are seamlessly synced between devices using 1Password) is what lost them "good guys" status in my mind.
It immediately creates a huge lock-in in a hard-to-notice way. Luckily, I did noticed early on and manually removed the 20 or so passkeys I had created.
Earlier this year, I lost my iPhone and restored from backup. I was shocked to see that I could log into my 1Password account using only the master-key, and that the secret-key was not required. 1Password clearly stated that the secret-key was required to setup a new device, but it turns out that they also (perhaps recently) configure it to upload to all devices in your iCloud account[1]. Ever since then, I've lost faith in 1Password's ability to communicate their security model to me and started looking for an off-ramp.
For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more:
For the iCloud syncing, I believe they've done that since iCloud Keychain/Apple Passwords was first a thing; I've been aware of it since they introduced it, but perhaps that was more explicit when it was first added. The comment below from a now-defunct 1Password employee account describes the thinking there:
> Importantly, the entire role of the Secret Key is to protect you from us and anything that might happen on our end, like a breach of 1Password’s servers. It does not (and can not) protect you from a local attack. This is mentioned in 1Password’s Security Design white paper [ed: on page 74 of an old PDF; I've linked the newer HTML document below], which goes into detail about the locally exposed Secret Key.
I do get why that might be surprising. Without going through the whole onboarding process on a fresh device I can't say how well they highlight that or how easy it is to blow past. All I can say is 1) I've known about it for years and 2) having read through the white paper of how iCloud Keychain works I _personally_ trust iCloud Keychain/Passwords about as much as I trust 1Password, maybe _slightly_ more - but I am also not a security professional, so take my word with very little salt :)
Oh, also, the firefox extension recently rolled out this feature, I think it was default-enabled:
> Use universal sign in for logins
> Our next-generation autofill combines all login types into a single sign in prompt.
What the f does 'next-generation' mean? No link for more information. Obviously I have to turn it off, else for all I know it will start setting up passkeys (now or in a future update) or do something else anti-user. And it also means that I need to be careful about updates to 1password. Sad to watch my relationship with my password manager go downhill.
The vibecoding part is probably because "userVerification: required" is essential to have it work somewhat-securely as your sole form of security - like Passkeys is heavily promoting. Without it anyone with physical access to the device can use it to log in. This might not be so bad for a password manager which already has strict session password requirements and short timeout periods of its own, but it is a completely different story with, say, a Yubikey.
If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.
> Without it anyone with physical access to the device can use it to log in
No, they would need to be able to log onto the device and have the password manager unlocked.
If your passkey is stored in a Yubikey and someone steals it, then how does this feature help you? When the thief plugs the stolen Yubikey into their own Windows account, what is Windows going to do? Ask the thief for the thief's own password? How does that help?
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.
The change to 1Pass is annoying and I don't mention these to discount your valid concerns with it, only to make people aware of the options that can help with this and make it less taxing than continuously entering a password:
* On Windows you can enable Windows Hello for biometric authentication.
* On Mac, as shit as it is, you can buy Apple's magic keyboard with TouchID (for crazy money, but still) and use it while the notebook is shut.
I hope 1Password can eventually consider adding something like face recognition from a webcam as an alternative method.
Unfortunately, without this they are not compliant and it gives a false sense of security to claim it is multi-factor when it's actually only one factor. You'll find the same with other Passkey stores like Kevault that require biometrics as well.
Yeah I thought about getting a Magic Keyboard with TouchID for this, but ultimately decided against being strong armed into replacing my beloved keyboard for a decade plus with one I may not like. And I happen to like Apple’s keyboards (at least the early mid 2010s ones) and sport an old Magic Keyboard; it’s even less of an option for people who swear by loud mechanical keyboards with long key travel.
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.
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.
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.
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.
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.
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.
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.
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."
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.
Before anybody thinks "surely they can't ban all linux users", they don't need to.
The systemd folks are also working on a startup that is building verifiable computing into Linux via systemd. So, we have no choice on the matter anyway.
It could become of choice of approved distro vs non approved distro.
> So the bad timeline is the one in which the industry gradually transitions to
We have been on that timeline for every other tech transgression. There are no signs that this will be a different timeline.
They would have to start by banning Apple users. Apple does not support attestations from consumer devices. Apple has said multiple times they see it as a consumer privacy violation.
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.
The intended audience is people who are not yet using passkeys, or have just started (due to all the websites demanding them now) but don't really know what they are.
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.
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.
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?
You don't care, until you use the wrong apple pay card and apple nukes your account and you can no longer login to anywhere because all your keys are in your now remotely bricked iphone.
Substitute apple with google, pay card with youtube comment and iphone with android for the "open" experience.
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.
Passkeys only give a random public key + some capability bits, whereas almost all password logins ask for your email or phone number, for the inevitable reset dance likely facilitated over antiquated email or SMS. Realistically the latter is much leakier.
My understanding is that TOTP and physical security keys both share very little information about you. Perhaps passkeys, being part of a standard that the FIDO Alliance keeps updating, may some day be expected to reveal considerably more information. And the limited number of remote-attestation-approved passkey managers might someday all start start volunteering such information regardless.
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.
"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.
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.
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.
One of the biggest issues with the implementation of passkeys that I've encountered is that I'm not offered the choice of where a passkey will be stored. It's just a fight between my password manager, my browser and my OS which all try to be "first" to intercept the passkey request, and if the "wrong one" gets it there's no way to say "actually no, I didn't want you to handle this passkey request".
> It's just a fight between my password manager, my browser and my OS which all try to be "first" to intercept the passkey request, and if the "wrong one" gets it there's no way to say "actually no, I didn't want you to handle this passkey request".
This is one of my biggest issues. My family full of normal people are nothing more than dark pattern victims. And if you teach them to avoid certain dark patterns, big tech is quick to update them.
The author is clearly saying that the attestation feature is a trap. Typical consumer-oriented websites don’t use this feature. Therefore it is not a trap for your users. However there is no way for users to know and understand that.
I dread the day my mom encounters a web app that only allows passkeys. She gets passwords, and importantly, the ability to log in from any PC just by knowing her password (which, yes, is written in a little notebook, baby steps). If she wants to log into her account on some shared PC, she understands that flow, the password is a key that is synced through her typing it in.
If I have to explain Passkeys syncing from her PC where she made the account, to her phone, then to the 3rd PC using some qr code or bluetooth, then we're both gonna lose it. There is value in passkeys, but there's also huge value in a stupid and slightly less secure password that we've just completely abandoned.
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.
Those are not passkeys then. The idea of passkeys is that they’re synchronizable, since having to manually manage multiple credentials per account is extremely tedious.
To avoid lockout, you want to have more than one key to open a door however you do it. At least, for accounts that are important to you. It might be that one is a passkey and one is something else, though.
I'm sorry, what? Who has more than one password manager (other than a personal/work split)? That's absurd and not something anyone I've heard of would put up with
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.
I think you’re right. They won’t make it mandatory, but passkeys will increase the risk of account loss enough for them to convince a majority of people that using your real ID everywhere is the only way to make sure you’re secure and don’t lose access to your accounts.
Everything and everyone that tries to resist it will be labeled a bad actor.
> 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.
I'm in small tech saas and users having their accounts breached because they share a password with 100 other services is a constant. I have had to set forced 2FA on many products because we take the blame when the user has their account compromised.
Passkeys offer the same and more security but are less of a pain for the user.
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.
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.
Yes, but also: passkeys are a website to prevent you from sharing your password with friends (like the Neflix example in the article). It's just a new form of corporate controlling.
But also, right now giving a website a passkey basically means being technically savvy or using a sensible system like the browser/OS. TOTP used to be this way, but then people got annoyed at the process and put everything into 3rd party apps that synced across devices. The same will happen with passkeys, at which point "passkeys are a website..." will morph into "attested passkeys are a website..." and the rest will remain true.
The part unique to passkeys is that the ability to disallow use is already sitting dormant everywhere and literally just needs websites to flip a switch. The other things you mentioned would all take effort for websites to set up.
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.
I follow this person on Mastodon. They are a known advocate of passkeys. Working on the same thing for many years can certainly cloud one’s judgement. Here are their three points and my opinion:
> 1. Intentionally presenting things that are complicated as inherently suspicious. (Delivering security by design can be complicated, yes!)
This is a matter of opinion. Personally I think making a technology understandable is more important than incomprehensible but secure.
> 2. Describing TOTP as a “great solution” for adding security to a password-based account. When the most common threat model on the web is phishing (a word the post never mentions!), TOTP hardly buys you _anything_. TOTP is phishable.
Phishing isn’t a big threat to regular consumers. It’s a bigger threat to workers at corporations and government agencies. These places have IT departments. They have better solutions than passkeys, including using a Yubikey as a second factor. It may be based on WebAuthn but it’s not a passkey.
> 3. Seeming to be unbothered by how many logical leaps are being taken without actually understanding the topic being discussed.
Why are the logical leaps? I don’t see any. What I see is clearly delineated hypotheses for future scenarios. We can’t predict the future but the original author is predicting a particularly dire future, whereas rmondello is predicting a better future.
> Phishing isn’t a big threat to regular consumers.
Can you back that up with data? Anecdotally regular people get phished all the time, why do you think banks are sending out frequent reminders, show banners on their websites and apps about phishing attempts in the wild and mail providers explicitly showing if something is an official Google / Fastmail communication and when it's not.
When I see phishing mail they are always for banking, Google / iCloud accounts and not specifically targeted at "corporate" or government agencies.
This is a pretty unconvincing argument. It's just one guy saying "trust me, no one will abuse this." It's especially unconvincing when you've got this other Passkey dev directly contradicting it:
> To be very honest here, you risk having KeePassXC blocked by relying parties. ... I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
What about Apple implementing TOTP codes sent via Apple Business messages (basically iMessage) but open the protocol to more devices ? Don't need to give everyone blue bubbles - just do it for TOTP codes only.
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.
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.
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.
Has to be a significant majority or else they'll just turn the other methods off.
I don't have the choice to use a bank card online without 2FA - it's mandated. I can either use one of the options provided or I will go to my bank in person and close my account. Those are the possibilities. Nothing else.
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.
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?
> The attestion part only serves to strengthen to Google/Apple duopoly
That's strange, since neither of them are a big player in the attestation enabled key manufacturer market. AFAIK Apple doesn't even make keys, and barely anyone uses Google's keys. You even mention Yubikey, yet somehow think Google and Apple have a duopoly here.
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.
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.
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.
Well they built it, verified everything was in place, presumably got some tick from govt/banks/etc then removed it. I’d love to know what happened/what they are thinking. And what happens next and when.
Do you think they did that to keep us FOSS neckbeard hackers happy?
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 was confused also, I use my Yubikey a passkey, so I did not get the rant.
Yubikeys can be used as a device-bound passkey, that the FIDO2 thing.
Now software managed passkeys are also a thing and can be stored in a (good?) old password manager, of course this is less secure and could be disallowed in the future.
Thus the rant is about people without dedicated hardware keys that would have to use things like device-bound passkeys their OS instead of their password manager.
Yes it's very common on sites, and even somewhat forced to have these digital passkeys. It's almost automatic setup and there's a lot of skepticism about them.
Copyable vs Non-Copyable passkeys
Transferable vs Non-Transferable passkeys
Hardware-Backed vs Software-Backed passkeys
User-Present vs Non-User-Present passkeys
User-Verified vs Non-User-Verified passkeys
Attested vs Non-Attested passkeys
They forgot
Roaming vs Platform passkeys
(roughly: movable vs device-bound).
This is what e.g. PayPal uses to prevent you from using your Yubikey as a passkey, while it works perfectly as a passkey on other providers (e.g. Wise bank)
It's checkable in the browser with e.g.:
`await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()`
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.
Eh, it’s alright. The spec is quite overengineered, but practically it’s very possible to achieve a good user experience.
And conversely, there are also many ways to make legacy password based auth break password managers and annoy users even though there’s no specification for that at all.
Because you or someone needs to publish "<digital_signature>" in a way that cannot be forged, stolen, MiTM'd, or otherwise compromised. Basically the key generating that signature just becomes another password, far more difficult to use in practice, and sharing all the same disadvantages.
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.
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.
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.
The objection is not against using keys for authentication, it's against the standard including attestation provisions, because there is an incredibly large space for abusing these to limit user freedom.
BigTech doesn't need attestations in the passkey spec to limit freedom.
Attestations were added so that highly specific domains where attestation is required (by law, a regulator etc.) can still use the same passkey spec as everyone else without having to invent their own thing.
If there was benefit to BigTech of locking in Auth to a specific device, they'd have done it long ago - it's not difficult.
sure, and some planes still crash, but that's still not reason why I will stop flying (using TOTP), it's about odds, I've never heard about TOTP MITM attack in few EU countries I read news from daily, it's unheard thing, only heard about it in US with crap identity verification
Microsoft logins are automatically taking us through "creating passkey" and "failed to create a passkey" without any prompt to user or consent from user
> 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 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.
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.
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].
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.
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 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.
That's why the article calls it a "trap". Like any trap, you have positive experiences until it's too late to leave. In this case, adoption of passkeys reaches a threshold where they all start requiring attestation, and now your fallback option is unsupported.
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.
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”.
> 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.
>> They can use passkeys to prevent you from running unapproved software.
The expression was wrong, but the real meaning was described further in the post. The author meant that sites with passkeys can render unapproved software useless, in contrast to TOTP where any client is compatible.
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.
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.
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).
You probably don't use a lot of different software like I do. For example my work computer is encrypted at boot in the BIOS and I need a password for that... There is no password manager available during BIOS boot up to fill in the password for me. Or I need to run a legacy application in a less popular browser or in the terminal/CLI where the password manager is not available and I don't want to open my vault and manually copy my plaintext password in front of my colleague who I'm currently screen-sharing with. I've had times when I was temporarily locked out of the password manager or I my laptop was wiped clean after a mandatory laptop swap/upgrade at my company (my work is confidential so there are a lot of security protocols I need to follow).
Once, I lost the master password of my password manager and the email to reset that master password was sent to my email inbox which required a password which was stored in my password manager which I was trying to regain access to... Catch 22... In the end, I got lucky that I didn't trust the entire security model and I had written down the password for my email on a sticky note on my desk!
The reason I lost the master password is because my company made me change the password every few months and didn't let me reuse old passwords and forced me to use a specific sequence of special characters. Eventually I couldn't remember which of the last 10 passwords I used was the latest one and which special characters were not allowed for which environment.
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?
If they will be popular, and made inconvenient, you could be forced to use them. Like 2FA in corporate environments; it's forced and you can't do anything else than to put a code every time you login somewhere.
> 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.
If you keep reading the article, you’ll see that the claim is current (unattested) passkeys are a stepping stone to “attested passkeys”. Attested passkeys would require remote attestation with OS, TPM, and password manager all working together, and would allow websites to require things like hardware backed non transferable passkeys that you don’t control. This has always been my suspicion and I do think it’s worth worrying about.
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.
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.
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.
Phishing is a major problem, but it happens less than you think. Password managers are also checking the domain before supplying a saved password. A user who relies on autofilling the password every time will notice when their password manager suddenly does not autofill.
Yubikeys are a great second factor honestly. But do you want to use a Yubikey as a passkey? Sorry you are likely dissatisfied. Many websites and apps (especially apps) support passkeys but would prohibit using your Yubikey as a passkey.
> 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.
YubiKeys have been a thing at Google and other major tech companies for almost two decades now and the effects are well-studied.
My experience is that yubikeys have a tendency to get lost, get cleared, get mixed up (which of my 4 identical yubikeys has the right passkey?), stop working reliably from random USB issues, etc. And worse, yubikeys are awful to use. Like am I seriously supposed to take off my phone case every time I want to plug in a yubikey to the USB-C port (which may or may not be working depending on whether moisture has condensed in the port) so I can use the one mobile browser that supports them to retrieve a passkey every time I want to log in?
No, fuck that. Just let me use an SSH cert at that point. The existence of phishing is a comparatively minor evil.
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.
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.
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.
This is just completely unsubstantiated conspiracy.
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.
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.
> 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.
> 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.
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.
This is ridiculous. You can nullify basically any argument by bringing up abstract philosophy that has very little to do with the issue at hand. "I want the ability to choose between A and B" - oh, but can you choose? Are you saying you have free will? What's to say the choice wouldn't be the same every time? And so on.
The point is very simple - there was once a day when we had considerably more control over the way we use computers and the networks that connect them. That is slowly being taken away, piece by piece, until the only path to use them is to 'consent' to whatever demands the corporations put up. Not that this doesn't exist already, but today will seem like the wild west in comparison to what's coming.
"Big tech is coercive and evil" isn't a new view, but "passkeys are one of their tools and not just some agnostic technology-first nerd solution" is still not widely known.
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 viable value statements down to a finite subset of cause-effect. And I don't mean just flag waving holy book social conservatism. This community is clinging hard to social tropes the other 8 billion are moving on from
Run a trend analysis on the comments of HN going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth; don't speak too far outside the experience of readers or the inherent short term prediction engine in their brain will segfault from a biological memory overflow
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
The LLM should have suggested where you find the browser setting to disable it - they all have one. Can you explain why you're leaving the setting enabled, and using a user-script to disable it instead? Most browsers even offer per-site permissions.
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.
> at login time it's not possible to retroactively require attestation if it wasn't obtained during registration.
Of course it is, the site will reject the passkey and require you to create one that is attested.
> Are Netflix and Twitter currently requesting attestation when people register passkeys, and rejecting the registration if the user declines the permission prompt?
They could start tomorrow.
> a hypothetical and unlikely scenario.
You have not been paying attention, that scenario is where this whole thing is building towards.
> If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out
It's going to be the banks first.
Why called out, it's all for your safety, to make sure you are not using an insecure client that might leak your data.
> It's going to be the banks first.
In Japan, this is already the reality. The FSA required brokerages to implement passkey authentication, and the effect is that it's no longer possible to have a brokerage account without a passkey. (Some brokerages, like Nomura Securities, will offer two separate client portals. The portal with money and trading-related functionality requires a passkey).
The thing that sucks a lot is that brokerages seem to also restrict the allowed software/hardware. Don't know the details, but none of my FIDO2 hardware keys were able to be used. I consistently use these hardware keys through WebAuthn, so I was surprised when my brokerage explicitly told me my hardware key is unsupported and I must use either Windows Hello or the iOS Passwords app.
The FSA's official explanation for mandating passkey implementation is that people kept falling for phishing attacks, and the attacks were getting too sophisticated thanks to "AI" or something.
2 replies →
> They could start tomorrow.
They could also start requiring you to mail a DNA sample to create an account tomorrow.
> It's going to be the banks first.
The same banks that (in the US) largely don’t even systematically use 2FA for online banking logins and completely ignore 3DS for card payments? Attestation usually requires customers to buy and carry extra hardware, so I highly doubt it.
The only place I’ve seen mandatory attestation is in enterprise IT, where admins can supply and enforce usage of e.g. Yubikeys.
34 replies →
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.
7 replies →
The banks are also a commonly mentioned reason to not use Grapheneos when it comes up on this site.
Attestation is already putting the screws onto open computing, and the frog is already on the boil.
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.
22 replies →
> It's going to be the banks first
This is a great point as banks already did exactly this and to me this seems like a very strong proof that we can't rely on "vigorously calling out"
So they're gonna stop supporting Apple users?
20 replies →
While not directly related to passkeys, CAs require private keys for code signing certificates to be generated on FIPS-certified hardware security devices, and use attestation to verify this.
I think OP was referring to “initial attestation”. Without that you cannot attest again.
We have more than enough technology in browsers to allow JavaScript reading live video from your webcam. A website could use that so they can see if you’re looking at the ads enough.
They could start doing it tomorrow. They just have to flip the switch.
What’s your point?
I am very hopeful that passkeys will fail overall. They've definitely forced a lot of adoption quickly, but I think also that a lot of people have no idea what they've signed up for, and there is a decent chance of a quiet, slow retraction in the long run. Their death will be well-earned by just the attestation alone - one hundred percent, in my opinion. I tell my loved ones to not use passkeys simply because they're much more likely to accidentally run into scenarios where they lose the device. I'm not going to stop. I encourage everyone to do the same.
I still am using passkeys for some sites because they otherwise force you into insecure processes like SMS-based 2FA with implied humiliation rituals, but banks are the worst offenders and they seem to like discriminating against open source password managers, so while they are not using attestation I am still patching my password manager to lie about its identity. Hopefully this will become more common in the future.
https://github.com/jchv/nixos-config/blob/c85e4ecb7434603ec1...
Also worth point out that Apple consumer devices intentionally do not support attestation at all, and only support it for devices under enterprise management. That's still a dominant enough number of devices in the US at least that a consumer site seems unlikely to want to disable/break logins for all iOS and iPadOS users.
Even stronger, they used to support it, but now no longer do, so we know for a fact that Apple knows how to do attestation, has already expended all resources necessary to implement it, but has then actively decided to go into a different direction (i.e. that of cloud synchronization).
I believe Android still has the option to use hardware attestation, but that automatically opts credentials out of cross-device synchronization, but Apple's veto alone is enough to make attestation non-viable.
If this can't make the "WebAuthN implies mandatory attestation!!" critics update, I wonder if anything can, and how useful their criticism still is.
8 replies →
Be that as it may, they can still roll out the passkey attestation requirement gradually, -- "flip the switch" just a few thousand users at a time -- so that at no one point in time is there a large blip in users. Truth be told, tech platforms don't even really need to measure what portion of users' devices support remote attestation, since the overwhelming majority of devices will support it. They just need to know that users are passkey-capable in the first place; once enough users have passkeys in any form, they can start requiring remote attestation.
As for the browser permission prompt: Firefox simply warns you that the site is "requesting extended information about your security key [sic] which may affect your privacy." [1] It does not make it at all clear to the user that what's really happening is that the website is gating acces behind a specific approved software stack. If I use a non-widely-used OS or device, what website is going to approve its attestation credentials?
[1] https://github.com/mozilla-firefox/firefox/blob/8e9ac3e12bba...
Sorry, bit this is just the standard "boil the frog" playbook that tech companies always use for user-hostile features. It's usually:
1) There is this new entirely optional feature, but it's not relevant to you, so feel free to ignore it.
2) The feature is now active by default, but no worries, there is a simple button for you to opt-out.
3) The feature is active by default, but because we value our users, there is an option in the advanced settings to deactivate it.
4) Our data shows that 99.9% of users activated the feature, but if you belong to the handful of diehards who still refuse to use it (rolls eyes), you can use this obscure command line flag or about:config entry to turn it off
5) Managing opt-out infrastructure for the feature has significant maintenance and security cost that we feel, we can no longer justify. Therefore, effective in three months, the opt-out flags will stop working and the feature will become mandatory. According to our metrics, this will affect 0.0001% of our users, so no disruption is expected.
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."
13 replies →
> The feature is now active by default, but no worries, there is a simple button for you to opt-out.
How I wish this were true for (US) banks. They usually force whatever new hell on you they just came up with without asking, or in fact even telling you about it.
The most bizarre instance I've seen so far: "We have unilaterally added this phone number we believe to be in your name (surely cell carriers have better KYC than we do!) to your account as the only SMS-OTP authentication method and are choosing to disregard the one we've had on file for years since it's an evil VoIP number. Please do not contact us again without access to the former number for authentication."
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.
18 replies →
Heh. This is exactly what happened to me at stackoverflow sites. I had been using OpenID to log in. Eventually they eliminated it.
> Attestation is certainly a stain on the WebAuthn spec
Attestation is necessary for corp use cases. Adding it as an option to WebAuthn is better than forcing more standards to be developed.
Having read the very complicated WebAuthn spec so I could implement an RP, and participated in too many stupid debates about attestation like this one: multiple, simpler specs focused on specific use cases would have been better than a single gargantuan spec that tries to do everything.
There's also another scenario - annoy most users into using passkeys, then say "well everyone is using passkeys already, we don't need passwords anymore", and _then_ slowly start requiring attestation. Really I'm not one to look for conspiracy theories, but with the recent pushes around e.g. chat control, it's not that far fetched to assume someone pushes for more control over users' accounts
This is the obvious endgame. Right now you have people who will say that passkeys are unphishable so we should switch to them. When you point out that people will lose their devices and credentials they'll then tell you can just use account recovery emails to get back in. They actually argue you absolutely need an iron clad door with a guard employed by some one else to protect account on some random website (that the website decided was precious, not you) But that's OK because they left a same old shoddy back door open in case you can't get in. So why even bother? Because that isn't the point. The plan is to remove the back door after enough people are trapped, they just need to keep the screaming to minimum while they get everyone in there.
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?
1 reply →
I share that concern somewhat, but I think your point stands even better without suspecting some shadowy attestation cabal.
The US has thousands of banks, and nobody tells them how to authenticate their customers – they just all end up doing the same few horrible things, since nobody ever gets fired for doing what all their peers do (and maybe a little bit more to be sure).
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
2 replies →
I have come to the comfortable conclusion that in 20 years I will have two computers. One is my phone, used for buying stuff, banking, etc.
and the other is a laptop, capable of doing none of that
That could happen but passkeys won't be the reason why.
1 reply →
> That's not a good enough reason to recommend TOTP instead
In what way is TOTP an "instead"? My understanding of passkeys is that they basically replace the username/password combo, but do not provide any kind of second factor. I know at least one service (I think Amazon, but I'm not 100% sure) still requires TOTP when logging in with a passkey from an unrecognized device.
TOTP also does not imply a second factor, it's just a time-based password calculated from a shared secret that can be stored anywhere, for example in your password manager alongside the username and password. And worse than your password, of which only a hash should be stored at the service you have an account with, they store the shared secret too (which can thus be leaked from their side), so TOTP is never fully hardware-bound, it always exists in at least two places. Passkeys _can_ be fully hardware-bound, with the secret only existing in the secure chip of your phone or hardware security key for example, not at any moment in its lifecycle exposed to user, service or potential attacker.
> Amazon (..) still requires TOTP when logging in with a passkey from an unrecognized device.
I noticed Amazon does that and it annoyed me greatly.
My understanding is that the passkey branding is specifically for copyable, user-verified keys. So the second factor is the biometrics (or equivalent) of your device. But yeah there doesn’t seem to be consensus yet about still requiring TOTP with passkeys.
Some how the Passkey topic comes up again and again. There is not much of a background information about the Author so its really hard to take that into context. Without knowing the agenda its hard to say anything concretely however most of the information presented is twisted in certain ways
A lot of people are aware of public key cryptography or asymmetric encryption, its already supported as identification & authentication method in sensitive places via MTLS. The whole idea of MTLS is about the server verifying the identity of the client and one of the core concepts is validating that the client certificate is issued by some Certificate Authority that can be trusted by the server. Its Phishing resistant, meaning some one cannot trick you into giving them the your credential that they can use by accident. The client certificates could be baked into physical devices (PIC, CAC cards) or Digital certificate on your machine. MTLS is used universally for machine to machine communication, however there is a certain degree of complexity so its not used everywhere for user identity.
1. FIDO is trying to leverage the same concept and trying to make it bit easier for use compared to MTLS. The core idea is to just use it for authentication not identification. It allows the user to authentication as long as the client can prove that they have the private key for a corresponding public key
2. Passkeys were/are target for Enterprise/Workforce users. When a consumer account is hacked the impacted user is just the consumer, whereas when an Employee account is hacked the entire company is at risk.
3. Passkeys/ (WebAuthn+CTAP) have been there for a while. Its still still evolving and everyone (platforms, Browsers, OS, Password managers, IDPs) wants to get something out of it which keeps on making it more complex
Since the client/authenticator is storing the private key, its important to ensure that they are doing it in a uniform and secure way. The authenticator implements a protocol called CTAP and they are supposed to conform to certain tests. The attestation is a means to ensure that the authenticator is doing the least minimum from security perspective.
Personally I do not like the idea of centralization, however as long as the path to attestation for different passkey providers is not locked I would say the attestation is a part of security.
At the same time the things I would worry about would be if the Authenticator provider starts generating a unique attestation for every user in customer identity space (its almost 0 cost in case of software based authenticators). A unique certificate for every authenticator instead of a batch one is where the privacy would be leaked, its akin to fingerprint. Some big companies are already doing it for their employees, thats a valid use case, employees unfortunately do not have a privacy when they are acting on behalf of the company
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.
You can put your passkey in another safe. I store mine in my vaultwarden. You can also do keepass with a plugin. You don't have to store it on your phone.
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...
26 replies →
> You can put your passkey in another safe.
This! Passkeys would have been tough for me to adopt without this ability. Now passkeys are significantly more convenient that any other MFA method.
Right, but... I can already store my credentials in a password manager and enable MFA. I understand the pitch, but Passkeys seem to buy me very little as a user and add significant brittleness.
1 reply →
> 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".
11 replies →
What if they meant a real safe? The big metal kind.
7 replies →
Same for me.. I don't want my login information to be tied to a particular device, or device vendor. TOTP is a clear winner in all of this. Minor inconvenience, but highly secure and portable.
A password manager solves this problem. I use 1password but there are others, including open source solutions. Passkeys for me are by far the most convenient form of MFA-based authentication.
5 replies →
Silicon Valley suffers an utter lack of comprehension of the concept of consent. As another commenter pointed out some time ago, if we were in a nightclub they'd be the creepy guy that keeps coming up to you asking:
Want to dance? Yes | Maybe Later
Silicon Valley suffers an utter lack of respect for the user, it's user-hostile.
I remember that comment, it's perfect.
1 reply →
It's not a lack of comprehension, it's late stage capitapism laser focused on the next quarter's earnings and nothing but that.
> I was forced to use a passkey implemented within the vendor's app
Sigh. It's OpenID (the original one) all over again? Everyone wants to be the auth provider, nobody wants to accept other auth providers.
> I want to be able to backup and lock my credentials in a safe.
I use passkeys all the time and absolutely have this on every account I care about.
> 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.
For any given Passkey-enabled service you use, you can have multiple Passkeys - ideally one per device, and it doesn't prevent you from also authenticating with another method, such as username and password.
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 sort of started skimming when the article was saying industry solved the problem with text messages and TOTP. I think there are several arguable problems with Passkeys as implemented, but to argue TOTP is equivalent is going to leave lots of people vulnerable.
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.
TOTP is this decade's "just have a better password", and we all know how well that went before.
1 reply →
> solved the problem with text messages
Especially considering how easy it still is to do a SIM swap.
5 replies →
It’s not just man in the middle.
If the credentials get stolen from a website database, they’re useless for every other website on earth. No matter how poorly they’re stored, it’s just a public key and is not useful. Hell, they can get code executing on the webserver that collects full login information, and it’s not useful.
Passwords always require full transmission. Hashing for storage requires a proper implementation, which we’ve seen does not happen. 100% of the time. There’s a reason hackers are still stealing passwords from websites after three decades.
Passkeys solve that. Nothing else available to the average user does.
>Passwords always require full transmission.
Into a hash algorithm not to a remote server.
>Nothing else available to the average user does.
Literally every person could use a unique password for each login.
7 replies →
>There's a lot of assuming bad faith on the part of the FIDO alliance
Yeah, it's just a bunch of "big company bad!"
Yes, Google and Twitter and Yahoo are just trying to get your data and sell ads, but I fail to see how Passkeys furthers that specific goal. Even if these companies have bad motivations in certain parts of their business, they all have an incentive to make accounts more secure (to reduce fraud) and improve the user experience (to increase engagement/happiness)
I noticed that too. This also seems like a bit of an insult to the intelligence level of the average person. It’s precisely because attestation is a nuclear weapon that I doubt one of the big three will try it outside of their own specialized credentials. If someone tries to change ecosystems and finds that they’re going to have to reset all their passkeys it’s not going to take long for them to tell all their friends that passkeys suck and not to use them. This instantly kills adoption.
Furthermore, the rest of us are the people at the companies implementing passkeys. I did an implementation recently, didn’t require attestation, and can’t imagine why I ever would.
If we’re at this level of trust for all of FIDO, why aren’t we at legislative centers doing something much more dramatic about it instead of navel gazing about how we’re the smart ones who have recognized FIDO’s next big trick? How is attestation the problem here?
1 reply →
Why is your grandpa or fictional billions users being MITM’d?
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.
There is a reason that banks send increasingly strident text messages that they will never ask for this code.
3 replies →
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.
10 replies →
Why are they being MITM'd? Because some people want money and don't mind breaking laws.
4 replies →
PKI already prevents man in the middle attacks.
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 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".
5 replies →
> 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.
Then why do we need all the stuff about attestation and data bits?
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.
2 replies →
We don't need attestation and most of the data bits. Apple consumer devices don't support attestation. Only Apple enterprise managed devices do. It's a paranoia tool for big enterprises with strict device management requirements. Apple has a lot of good reasons to believe attestation is a privacy violation for consumers and seems likely to keep up the good fight in making sure it remains an enterprise-only tool.
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.
So that our device vendors can say:
> I attest that this user's advertising ID is 12345, and for a fee I'll tell you all about what they've been up to.
Think of how much money they're just leaving on the table by letting us authenticate in ways that don't create such a side channel.
I think the real issue is that it's all about tracking. It's another level of spying on people, data being mined, people being locked in somehow someway so someone somewhere else can have an increased level of precision in some floating point number in some algorithm that is being used to grind the joy out of human existence in exchange for money being moved from one incredibly rich consortium to another, the animus of cpr on a dead god for a dying race.
> Stealing accounts is almost always done with phishing or social engineering
This only becomes real if you don't have e-mail fallback access to your account. Something which seems like a very bad idea.
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...
1Password suddenly offering to save passkeys without mentioning that they can't be exported to other apps (but are seamlessly synced between devices using 1Password) is what lost them "good guys" status in my mind.
It immediately creates a huge lock-in in a hard-to-notice way. Luckily, I did noticed early on and manually removed the 20 or so passkeys I had created.
Earlier this year, I lost my iPhone and restored from backup. I was shocked to see that I could log into my 1Password account using only the master-key, and that the secret-key was not required. 1Password clearly stated that the secret-key was required to setup a new device, but it turns out that they also (perhaps recently) configure it to upload to all devices in your iCloud account[1]. Ever since then, I've lost faith in 1Password's ability to communicate their security model to me and started looking for an off-ramp.
[1] https://support.1password.com/secret-key-security/
For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more:
https://rmondello.com/2026/09/07/switching-password-managers...
https://fidoalliance.org/download-credential-exchange-specif...
For the iCloud syncing, I believe they've done that since iCloud Keychain/Apple Passwords was first a thing; I've been aware of it since they introduced it, but perhaps that was more explicit when it was first added. The comment below from a now-defunct 1Password employee account describes the thinking there:
> Importantly, the entire role of the Secret Key is to protect you from us and anything that might happen on our end, like a breach of 1Password’s servers. It does not (and can not) protect you from a local attack. This is mentioned in 1Password’s Security Design white paper [ed: on page 74 of an old PDF; I've linked the newer HTML document below], which goes into detail about the locally exposed Secret Key.
https://www.reddit.com/r/1Password/comments/10iqhdp/comment/...
https://agilebits.github.io/security-design/index.html
I do get why that might be surprising. Without going through the whole onboarding process on a fresh device I can't say how well they highlight that or how easy it is to blow past. All I can say is 1) I've known about it for years and 2) having read through the white paper of how iCloud Keychain works I _personally_ trust iCloud Keychain/Passwords about as much as I trust 1Password, maybe _slightly_ more - but I am also not a security professional, so take my word with very little salt :)
6 replies →
Oh, also, the firefox extension recently rolled out this feature, I think it was default-enabled:
What the f does 'next-generation' mean? No link for more information. Obviously I have to turn it off, else for all I know it will start setting up passkeys (now or in a future update) or do something else anti-user. And it also means that I need to be careful about updates to 1password. Sad to watch my relationship with my password manager go downhill.
2 replies →
That's not a "not good guys" event. That's a "lifetime in prison for all people involved" event.
hmm, I'm sure with a model that is not restricted, one might be able to extract these locally.
They'll have to do this or they'll be blackballed using attestation and certification weapons the FIDO alliance possesses: https://github.com/keepassxreboot/keepassxc/issues/10406
You don't get to decide how to use your passkeys, some on else does.
The vibecoding part is probably because "userVerification: required" is essential to have it work somewhat-securely as your sole form of security - like Passkeys is heavily promoting. Without it anyone with physical access to the device can use it to log in. This might not be so bad for a password manager which already has strict session password requirements and short timeout periods of its own, but it is a completely different story with, say, a Yubikey.
If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.
> Without it anyone with physical access to the device can use it to log in
No, they would need to be able to log onto the device and have the password manager unlocked.
If your passkey is stored in a Yubikey and someone steals it, then how does this feature help you? When the thief plugs the stolen Yubikey into their own Windows account, what is Windows going to do? Ask the thief for the thief's own password? How does that help?
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.
Substitute the title for Passkeys Considered Harmful.
The change to 1Pass is annoying and I don't mention these to discount your valid concerns with it, only to make people aware of the options that can help with this and make it less taxing than continuously entering a password:
* On Windows you can enable Windows Hello for biometric authentication.
* On Mac, as shit as it is, you can buy Apple's magic keyboard with TouchID (for crazy money, but still) and use it while the notebook is shut.
I hope 1Password can eventually consider adding something like face recognition from a webcam as an alternative method.
Unfortunately, without this they are not compliant and it gives a false sense of security to claim it is multi-factor when it's actually only one factor. You'll find the same with other Passkey stores like Kevault that require biometrics as well.
Yeah I thought about getting a Magic Keyboard with TouchID for this, but ultimately decided against being strong armed into replacing my beloved keyboard for a decade plus with one I may not like. And I happen to like Apple’s keyboards (at least the early mid 2010s ones) and sport an old Magic Keyboard; it’s even less of an option for people who swear by loud mechanical keyboards with long key travel.
2 replies →
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.
1 reply →
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
9 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.
1 reply →
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.
3 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.
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'd go even further and say that secure boot and hardware roots of trust are the root of all evil.
Do you have any common examples of those?
1 reply →
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.
> such as Linux
Before anybody thinks "surely they can't ban all linux users", they don't need to. The systemd folks are also working on a startup that is building verifiable computing into Linux via systemd. So, we have no choice on the matter anyway. It could become of choice of approved distro vs non approved distro.
> So the bad timeline is the one in which the industry gradually transitions to
We have been on that timeline for every other tech transgression. There are no signs that this will be a different timeline.
They would have to start by banning Apple users. Apple does not support attestations from consumer devices. Apple has said multiple times they see it as a consumer privacy violation.
Oh great, another systemd conspiracy theory.
1 reply →
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.
The intended audience is people who are not yet using passkeys, or have just started (due to all the websites demanding them now) but don't really know what they are.
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.
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.
1 reply →
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.
6 replies →
You don't care, until you use the wrong apple pay card and apple nukes your account and you can no longer login to anywhere because all your keys are in your now remotely bricked iphone.
Substitute apple with google, pay card with youtube comment and iphone with android for the "open" experience.
> the wrong apple pay card
Expand on this? Haven't heard of this failure mode.
2 replies →
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.
Passkeys only give a random public key + some capability bits, whereas almost all password logins ask for your email or phone number, for the inevitable reset dance likely facilitated over antiquated email or SMS. Realistically the latter is much leakier.
My understanding is that TOTP and physical security keys both share very little information about you. Perhaps passkeys, being part of a standard that the FIDO Alliance keeps updating, may some day be expected to reveal considerably more information. And the limited number of remote-attestation-approved passkey managers might someday all start start volunteering such information regardless.
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.
"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.
> So many security articles just seem to be so far removed from the real world. Like, when is that ever going to happen?
Did you not read the previous paragraphs where they discussed someone leaking their password in a photo?
Yes. Leaking a password via a photo is completely different from leaking a 30-60 second TOTP.
Someone would need to:
1. Request the TOTP
2. Stand up and walk back
3. Take a photo of their desk with the TOTP visible
4. Send it to someone who can use it
All within 30-60 seconds. Just such an edge case it's not even worth thinking about.
1 reply →
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.
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.
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.
> Because passkeys usually sync and backup
And when they don't? What then?
One of the biggest issues with the implementation of passkeys that I've encountered is that I'm not offered the choice of where a passkey will be stored. It's just a fight between my password manager, my browser and my OS which all try to be "first" to intercept the passkey request, and if the "wrong one" gets it there's no way to say "actually no, I didn't want you to handle this passkey request".
> It's just a fight between my password manager, my browser and my OS which all try to be "first" to intercept the passkey request, and if the "wrong one" gets it there's no way to say "actually no, I didn't want you to handle this passkey request".
This is one of my biggest issues. My family full of normal people are nothing more than dark pattern victims. And if you teach them to avoid certain dark patterns, big tech is quick to update them.
The whole industry is turning into one big scam.
The author is clearly saying that the attestation feature is a trap. Typical consumer-oriented websites don’t use this feature. Therefore it is not a trap for your users. However there is no way for users to know and understand that.
No browser or consumer password manager implements attestation. There's no need for users to know something that's simply not relevant for them.
3 replies →
I dread the day my mom encounters a web app that only allows passkeys. She gets passwords, and importantly, the ability to log in from any PC just by knowing her password (which, yes, is written in a little notebook, baby steps). If she wants to log into her account on some shared PC, she understands that flow, the password is a key that is synced through her typing it in.
If I have to explain Passkeys syncing from her PC where she made the account, to her phone, then to the 3rd PC using some qr code or bluetooth, then we're both gonna lose it. There is value in passkeys, but there's also huge value in a stupid and slightly less secure password that we've just completely abandoned.
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.
Those are not passkeys then. The idea of passkeys is that they’re synchronizable, since having to manually manage multiple credentials per account is extremely tedious.
To avoid lockout, you want to have more than one key to open a door however you do it. At least, for accounts that are important to you. It might be that one is a passkey and one is something else, though.
If I can sync from phone (Android and also iOS), to Linux / browser (Firefox), that's fine. Or is it?
The problem here is not about them being copyable, it's about the "attested" keys which depend on a 3rd party.
> more than one password manager
I'm sorry, what? Who has more than one password manager (other than a personal/work split)? That's absurd and not something anyone I've heard of would put up with
Want to guess how many non-tech individuals save passwords in Chrome on desktop and in iOS on their iPhone?
3 replies →
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.
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.
I think you’re right. They won’t make it mandatory, but passkeys will increase the risk of account loss enough for them to convince a majority of people that using your real ID everywhere is the only way to make sure you’re secure and don’t lose access to your accounts.
Everything and everyone that tries to resist it will be labeled a bad actor.
> 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.
Knowing how big tech works this will get forced down throats desired or not
I'm in small tech saas and users having their accounts breached because they share a password with 100 other services is a constant. I have had to set forced 2FA on many products because we take the blame when the user has their account compromised.
Passkeys offer the same and more security but are less of a pain for the user.
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.
2 replies →
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.
Yes, but also: passkeys are a website to prevent you from sharing your password with friends (like the Neflix example in the article). It's just a new form of corporate controlling.
This
But also, right now giving a website a passkey basically means being technically savvy or using a sensible system like the browser/OS. TOTP used to be this way, but then people got annoyed at the process and put everything into 3rd party apps that synced across devices. The same will happen with passkeys, at which point "passkeys are a website..." will morph into "attested passkeys are a website..." and the rest will remain true.
Indeed.
But what was (is?) wrong with FIDO / webauthn?
passkeys _are_ fido/webauthn.
3 replies →
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.
The part unique to passkeys is that the ability to disallow use is already sitting dormant everywhere and literally just needs websites to flip a switch. The other things you mentioned would all take effort for websites to set up.
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...
I follow this person on Mastodon. They are a known advocate of passkeys. Working on the same thing for many years can certainly cloud one’s judgement. Here are their three points and my opinion:
> 1. Intentionally presenting things that are complicated as inherently suspicious. (Delivering security by design can be complicated, yes!)
This is a matter of opinion. Personally I think making a technology understandable is more important than incomprehensible but secure.
> 2. Describing TOTP as a “great solution” for adding security to a password-based account. When the most common threat model on the web is phishing (a word the post never mentions!), TOTP hardly buys you _anything_. TOTP is phishable.
Phishing isn’t a big threat to regular consumers. It’s a bigger threat to workers at corporations and government agencies. These places have IT departments. They have better solutions than passkeys, including using a Yubikey as a second factor. It may be based on WebAuthn but it’s not a passkey.
> 3. Seeming to be unbothered by how many logical leaps are being taken without actually understanding the topic being discussed.
Why are the logical leaps? I don’t see any. What I see is clearly delineated hypotheses for future scenarios. We can’t predict the future but the original author is predicting a particularly dire future, whereas rmondello is predicting a better future.
> Phishing isn’t a big threat to regular consumers.
Can you back that up with data? Anecdotally regular people get phished all the time, why do you think banks are sending out frequent reminders, show banners on their websites and apps about phishing attempts in the wild and mail providers explicitly showing if something is an official Google / Fastmail communication and when it's not.
When I see phishing mail they are always for banking, Google / iCloud accounts and not specifically targeted at "corporate" or government agencies.
2 replies →
This is a pretty unconvincing argument. It's just one guy saying "trust me, no one will abuse this." It's especially unconvincing when you've got this other Passkey dev directly contradicting it:
> To be very honest here, you risk having KeePassXC blocked by relying parties. ... I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
They need to remove attestation from the spec. Instead of promising no one will ever use it, just get rid of it and solve the problem.
What about Apple implementing TOTP codes sent via Apple Business messages (basically iMessage) but open the protocol to more devices ? Don't need to give everyone blue bubbles - just do it for TOTP codes only.
You could make it purple
elsewhere on Hacker: https://news.ycombinator.com/item?id=50061290
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.
Trusted computing without attestation is definitionally not trusted computing anymore.
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.
Has to be a significant majority or else they'll just turn the other methods off.
I don't have the choice to use a bank card online without 2FA - it's mandated. I can either use one of the options provided or I will go to my bank in person and close my account. Those are the possibilities. Nothing else.
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.
3 replies →
It's only a matter of time, and no correspondence shall be entered into.
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?
> The attestion part only serves to strengthen to Google/Apple duopoly
That's strange, since neither of them are a big player in the attestation enabled key manufacturer market. AFAIK Apple doesn't even make keys, and barely anyone uses Google's keys. You even mention Yubikey, yet somehow think Google and Apple have a duopoly here.
I have dedicated about 0 seconds to thinking about any of this: I store mine in Bitwarden, because it offered to do so. Is that a bad idea?
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.
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.
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.
Apple is the one major tech company not implementing attested passkeys, actually.
Well they built it, verified everything was in place, presumably got some tick from govt/banks/etc then removed it. I’d love to know what happened/what they are thinking. And what happens next and when.
Do you think they did that to keep us FOSS neckbeard hackers happy?
1 reply →
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?
I was confused also, I use my Yubikey a passkey, so I did not get the rant.
Yubikeys can be used as a device-bound passkey, that the FIDO2 thing.
Now software managed passkeys are also a thing and can be stored in a (good?) old password manager, of course this is less secure and could be disallowed in the future.
Thus the rant is about people without dedicated hardware keys that would have to use things like device-bound passkeys their OS instead of their password manager.
Yes it's very common on sites, and even somewhat forced to have these digital passkeys. It's almost automatic setup and there's a lot of skepticism about them.
1 reply →
Among
They forgot
(roughly: movable vs device-bound).
This is what e.g. PayPal uses to prevent you from using your Yubikey as a passkey, while it works perfectly as a passkey on other providers (e.g. Wise bank)
It's checkable in the browser with e.g.: `await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()`
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.
Eh, it’s alright. The spec is quite overengineered, but practically it’s very possible to achieve a good user experience.
And conversely, there are also many ways to make legacy password based auth break password managers and annoy users even though there’s no specification for that at all.
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>.
You have described, at a high level, passkeys.
Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.
7 replies →
Because you or someone needs to publish "<digital_signature>" in a way that cannot be forged, stolen, MiTM'd, or otherwise compromised. Basically the key generating that signature just becomes another password, far more difficult to use in practice, and sharing all the same disadvantages.
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.
> 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.
1 reply →
> 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.
1 reply →
Ok, I guess you also need a way to say "Oh, and next time I talk to you I'll use public key <public_key>."
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...
TOTP is susceptible to man in the middle attacks. Passkeys are not. That alone is a solid reason to favor Passkeys!
The objection is not against using keys for authentication, it's against the standard including attestation provisions, because there is an incredibly large space for abusing these to limit user freedom.
BigTech doesn't need attestations in the passkey spec to limit freedom.
Attestations were added so that highly specific domains where attestation is required (by law, a regulator etc.) can still use the same passkey spec as everyone else without having to invent their own thing.
If there was benefit to BigTech of locking in Auth to a specific device, they'd have done it long ago - it's not difficult.
2 replies →
sure, and some planes still crash, but that's still not reason why I will stop flying (using TOTP), it's about odds, I've never heard about TOTP MITM attack in few EU countries I read news from daily, it's unheard thing, only heard about it in US with crap identity verification
Related:
https://news.ycombinator.com/item?id=49753211
I don't like passkeys (hawksley.dev)
853 points by ethanhawksley 23 days ago | 832 comments
Microsoft logins are automatically taking us through "creating passkey" and "failed to create a passkey" without any prompt to user or consent from user
> 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 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.
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.
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 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.
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.
That's why the article calls it a "trap". Like any trap, you have positive experiences until it's too late to leave. In this case, adoption of passkeys reaches a threshold where they all start requiring attestation, and now your fallback option is unsupported.
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.
TFA is suggesting that, in the future, you won't be allowed to use passkeys with 1Password
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.
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.
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”.
> 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.
>> They can use passkeys to prevent you from running unapproved software.
The expression was wrong, but the real meaning was described further in the post. The author meant that sites with passkeys can render unapproved software useless, in contrast to TOTP where any client is compatible.
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.
Also, good luck logging back into your services if your device breaks down.
Especially if you have devices from different vendors, such as an Android phone and a Mac computer.
I think passkeys are just an additional form of vendor lock-in.
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.
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).
How? I've been using a password manager for probably nearly 15 years at this point already with zero issue?
You probably don't use a lot of different software like I do. For example my work computer is encrypted at boot in the BIOS and I need a password for that... There is no password manager available during BIOS boot up to fill in the password for me. Or I need to run a legacy application in a less popular browser or in the terminal/CLI where the password manager is not available and I don't want to open my vault and manually copy my plaintext password in front of my colleague who I'm currently screen-sharing with. I've had times when I was temporarily locked out of the password manager or I my laptop was wiped clean after a mandatory laptop swap/upgrade at my company (my work is confidential so there are a lot of security protocols I need to follow).
Once, I lost the master password of my password manager and the email to reset that master password was sent to my email inbox which required a password which was stored in my password manager which I was trying to regain access to... Catch 22... In the end, I got lucky that I didn't trust the entire security model and I had written down the password for my email on a sticky note on my desk!
The reason I lost the master password is because my company made me change the password every few months and didn't let me reuse old passwords and forced me to use a specific sequence of special characters. Eventually I couldn't remember which of the last 10 passwords I used was the latest one and which special characters were not allowed for which environment.
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?
You assume you will be able to stop using them.
If they will be popular, and made inconvenient, you could be forced to use them. Like 2FA in corporate environments; it's forced and you can't do anything else than to put a code every time you login somewhere.
If that’s the case, then there’s even less to be done, isn’t there?
Thinking about passkeys from this angle, how big is the danger of using them for fingerprinting?
The same as using a browser to visit a website. Depends entirely on what data your client sends to the server and how unique that data is.
Very informative. I do not currently use them. Existing solutions cover me.
> 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.
If you keep reading the article, you’ll see that the claim is current (unattested) passkeys are a stepping stone to “attested passkeys”. Attested passkeys would require remote attestation with OS, TPM, and password manager all working together, and would allow websites to require things like hardware backed non transferable passkeys that you don’t control. This has always been my suspicion and I do think it’s worth worrying about.
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.
2 replies →
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.
Not if the site requires attestation and hardware-based.
Ah! Are there any that require that?
13 replies →
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.
Phishing is a major problem, but it happens less than you think. Password managers are also checking the domain before supplying a saved password. A user who relies on autofilling the password every time will notice when their password manager suddenly does not autofill.
Yubikeys are a great second factor honestly. But do you want to use a Yubikey as a passkey? Sorry you are likely dissatisfied. Many websites and apps (especially apps) support passkeys but would prohibit using your Yubikey as a passkey.
> 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.
3 replies →
[dead]
My experience is that yubikeys have a tendency to get lost, get cleared, get mixed up (which of my 4 identical yubikeys has the right passkey?), stop working reliably from random USB issues, etc. And worse, yubikeys are awful to use. Like am I seriously supposed to take off my phone case every time I want to plug in a yubikey to the USB-C port (which may or may not be working depending on whether moisture has condensed in the port) so I can use the one mobile browser that supports them to retrieve a passkey every time I want to log in?
No, fuck that. Just let me use an SSH cert at that point. The existence of phishing is a comparatively minor evil.
Your "SSH cert" option, in a consumer package, is effectively the passkey.
3 replies →
Note that YubiKeys are not passkeys. But they are a great alternative to passkeys that are just as secure if not moreso.
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.
This is just completely unsubstantiated conspiracy.
As usual for an article critical of Passkeys, this one, too, is total nonsense.
The fear of passkeys is silly. It is the typical HN “Very Good is the enemy of Perfect”
> 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.
> Passkeys are _by_ _design_ representable as clear-text strings. You can export them and sync between devices.
That's not the intention of the relevant standards.[1]
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
> 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.
5 replies →
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!
Not everyone is a hacker privacy type, and passkeys are still considerably easier than TOTP codes.
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.
This is ridiculous. You can nullify basically any argument by bringing up abstract philosophy that has very little to do with the issue at hand. "I want the ability to choose between A and B" - oh, but can you choose? Are you saying you have free will? What's to say the choice wouldn't be the same every time? And so on.
The point is very simple - there was once a day when we had considerably more control over the way we use computers and the networks that connect them. That is slowly being taken away, piece by piece, until the only path to use them is to 'consent' to whatever demands the corporations put up. Not that this doesn't exist already, but today will seem like the wild west in comparison to what's coming.
"Big tech is coercive and evil" isn't a new view, but "passkeys are one of their tools and not just some agnostic technology-first nerd solution" is still not widely known.
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 viable value statements down to a finite subset of cause-effect. And I don't mean just flag waving holy book social conservatism. This community is clinging hard to social tropes the other 8 billion are moving on from
Run a trend analysis on the comments of HN going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth; don't speak too far outside the experience of readers or the inherent short term prediction engine in their brain will segfault from a biological memory overflow
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
I just got a LLM to write a user script that blocks pass key requests:
This disables more than just passkeys Also second factors and all of webauthn.
I just want to use passwords, so it's fine.
The LLM should have suggested where you find the browser setting to disable it - they all have one. Can you explain why you're leaving the setting enabled, and using a user-script to disable it instead? Most browsers even offer per-site permissions.
Because the setting in brave doesn't actually work.