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.
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.
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.
> If the service does something inappropriate, you can stop using it and, if necessary, build a competing service that is not abusive.
Like how everyone stopped using Google/Gmail, Facebook/Instagram and Windows/Office365 and flocked to alternatives?
Let's flip your suggestion. What if someone says if you need "high security" build a competing service that enforces it, no one is forcing you to use a "low security" service ?
I kind of agree, the problem is not individual sites consuming passkeys.
The main problem in my mind is on the side of the vendors, attestation, secure hardware, etc is all an excuse to lock you in to their device/ecosystem.
Any government can spy on a few people, and we're generally fine with that. But when they build a robust network of surveillance devices but pinky promise that they're only being used to spy on those same few people, we bring out the electric saws. It's a very similar situation with normalizing passkeys.
For a lot of people Apple is the ecosystem they access everything through, including payment processing. That cuts both ways, but Apple has shown a clear preference for protecting user privacy when they could have chosen to do otherwise, presumably because it makes them more money in the long run.
Why would that suddenly change in Netflix or some other company's favor at Apple's direct expense?
It's not in Apples expense, it's actually in it's benefit, your keys would be in their system, and impossible for anyone (including you) to get them out of it.
So you are now locked in to the apple ecosystem forever. You now need Apple to watch Netflix from your Samsung TV.
You make it sound like Apple needs to lock the door instead of just opening it while everyone else shoots themselves in the foot. For people who want "it just works" as the highest function of their device, nothing comes close to Apple. It's only people with a technical inclination or specific needs who chaff at that, or people like me who are just cranky old bastards who don't want their own media collection apart from i/Apple/Everything.
But man... I cannot tell you how many people don't even notice the walls of the garden. Besides Apple is in competition with some huge players, more than capable of offering "Done with Apple literally trapping you? Follow this link and we'll transfer your passkeys."
> Done with Apple literally trapping you? Follow this link and we'll transfer your passkeys.
That's the whole point of the FIDO specs. This is now literally impossible to do. All the vendors are weirdly okay with this I believe it's because it cuts both ways.
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
Would a website want you to have to use Apple Passwords to guarantee that the account you're creating is connected to an Apple account, and thus making it more likely that you're a real, non-anonymous human?
edit: Why not just require "Sign in with Apple/Google" if that's the goal?
It's not a conspiracy theory when it's just another instance of the patterns big tech has overtly used against us for 20 years now. We see, every day, a frog being stung by a scorpion when crossing the river. So we don't let scorpions ride on our frogs any more. No conspiracy theory, just pattern recognition.
"I'm different!" says this particular scorpion - yeah yeah, I don't believe you.
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."
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.
Your choices affect how policies affect you. When the government starts receiving copies of all card transactions, the person who habitually uses cash is unaffected, as is the person who habitually uses Monero.
The number of places one can reasonably use cash anymore is rapidly shrinking. Some places it’s truly impossible.
I do believe this is a policy failure and that a law should exist mandating cash acceptance “for all debts public and private”, but there is nearly zero chance of such a law ever passing in the US.
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.
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".
I do not know the answer to your question but mine are in Vaultwarden. This probably means I have access to them. The method to get them out might end up not being pretty but it should be possible.
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:
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.
Highly economy specific. Ease varies by nation state. Social engineering attacks in Australia are far LESS common than they used to be and I believe other economies in Asia and Europe all have less than the USA.
If you aren't talking from a US perspective, where are you that SIM swap is a low bar?
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.
The security requirements are generally hidden from users. I have never noticed different behaviour between my passkeys.
But as I said, there are plenty of UX issues with passkeys, those UX issues however don't include getting your accounts hacked, phished, passwords lost in data breaches, etc, which I'd suggest are a lot worse.
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.
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".
PKI is already in place for domain verification. SSh with PKI is exactly what it sounds like, "passkeys" without attestation, hardware, corporate bullshit.
This is the entire usability/footgun issue with SSH public keys. For the tech savvy being able to copy and paste id_ed25519.pub into their online account settings would be a dream. But who will train the masses to do that? A lot of people would accidentally paste their private key. Just like how journalists learning OpenPGP emailed over their private key compromising it. For low tech savvy people having direct access to key material is an anti-feature. They can lose it. They can leak it or be phished into giving it up. They don't want to manually sync it between devices or generate per device keys and enroll all of them. Then companies exploit this need for user friendly design to create vendor lock in.
My point is your browser, password manager could do just that, all the attestation, hardware keys, required user confirmation etc, authorized clients etc are all a power ploy from FIDO to own peoples authentication.
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.
And if the bank implements the best form of Passkey (and implements it well) in this case it would require the user to biometrically authenticate before sending money (perhaps based on dollar amount or transaction volume) to a new account. The user would hopefully learn over time that the biometric requirement is aligned with money transfers and would grow suspicious if they were prompted for it during a scam session.
I'm not sure I follow this point? A trojan would fail to exfiltrate passkeys (assuming they're stored securely). It would be able to see a valid login and potentially use that session or exfiltrate the session, but wouldn't be able to get persistent account access. This seems better than stealing a password and getting persistent account access, or possibly stealing a TOTP code for the same. It's bad, but I think it's made better by passkeys? Unless I'm misunderstanding your point.
A trojan would succeed in using your session and potentially start sessions from your device in cases where your key does not require your confirmation or where they have found a bug to bypass that (it maybe as simple as providing simulated input events to the system).
My point is the gains are overstated the main weakness is almost always user action. Passkeys will not magically solve all our security problems.
You want corporations to get more into law enforcement? These things are already crimes, law enforcement agencies already go after them. Would I like more public funding for that? Absolutely. When we've solved crime then let's go back to using passwords, or even just usernames at that point, after all no one will hack them.
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.
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://news.ycombinator.com/item?id=50049311 about userVerification: required. Passkey in 1Password used to be on par or slightly more difficult than filling in TOTP codes (need to click to approve rather than browser extension autofill and even auto-submit on a large number of websites) but that’s no longer true with a good number of websites requiring userVerification. Now you have to type in your login password on desktops without biometrics. Forum thread: https://www.1password.community/1password-at-home-31/user-ve...
I 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 fine if you've got a couple of supported devices. The hardware support is however very bad. If my hardware is unsupported (and most hardware in the world is unsupported) that's not very helpful.
But you can be locked out if the provider decides you need to change your password after a breach, or you forget the password, or you enter the wrong password in too many times.
They’re both equally disposable. You can reset a password just like you can reset a passkey.
That's not really true, a QR code pops up, and you can use your other device to read it.
Even if your other device is a mainframe computer thousands of miles away, so long as you can photograph the QR code, you can decode it and send the data string for the passkey device needs to it.
The issue that many have with passkeys is that someone will tie a passkey to an ecosystem that they don't personally control like Apple's and then they can't get into their services without an apple device that's onboarded into Apple's ecosystem.
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.
> 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.
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.
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.
tldr from memory: Guy used 2 legitimately purchased gift cards that had been tampered and their codes were used by someone else. His account was locked with no recurse.
I think he could still use his phone, but all the online stuff were locked down. He only managed to get it back after his case reached this website(hn) and senior Apple people stepped in.
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.
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?
I really can't comprehend what the actual issue is here. The title isn't "shitting" on anything, it doesn't say "If you use passkeys, you are a horrible person". It literally is a summary of the article's point - Passkeys are a trap. It even offers a solution you long for - Do not use them, a perfectly fine recourse on an individual level unless you expect OP to overpower a massive tech alliance.
The tone hair-splitting makes it seem like you weren't going to be that receptive to the point anyway, no matter how many layers of subtext are inserted to abstract away the actual point, that being - Passkeys are a trap. Do not use them.
>Especially without offering any advice on how to improve things.
>And apparently it’s not even the point of the article.
It wasn't a pointless rant, you're seemingly primed for something that didn't happen here.
It's a good argument that passkeys are a trap while TOTPs offer the security you need but avoid the absolute control passkeys may hand over, so stick with those.
TOTP/SMS 2FA is a gigantic pain, I've probably lost multiple 24 hour days worth of time added up from entering TOTP and SMS 2FA codes dozens of times per day on websites that mandate it despite having nothing meaningful worth securing.
With passkeys I click once and I'm in like the golden age of using the web with a password manager in 2012. It's a huge quality of life improvement. If people want to avoid passkeys for whatever reason, that's fine but not interested in reading the same slippery slope argument that gets reposted every week.
A recurring issue with these critiques is how they seemingly presuppose passkeys are an all or nothing thing, and losing your passkey means losing access entirely. Which isn't how it works basically anywhere. It's just another auth method, if you can't use a passkey you fall back to whatever recovery method is offered. If passkeys became some user hostile trap overnight I'd just unenroll them and use TOTP, SMS 2FA, email 2FA, or whatever else is supported.
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're right, I didn't explain in much detail the motivation that will push websites to start requiring the remote attestation flag to be set. I will try to cover that in a future article.
But as for how it could "catch" you: if you use FOSS devices that are unattestable (as is the case for the LineageOS phone and Linux laptop I exclusively use), you may one day find you can't use many websites.
> 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
Admittedly, my experience comes from OAuth and Webauthn. I have yet to try to implement passkeys. My exposer to passkeys comes completely from long blog posts complaining about it.
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 guess I am envisioning the user agent doing all of this.
That's literally what a passkey is, that the linked article argues against. It relies on the platform vendor of your device hardware to validate the full stack of software. You can't just do it in a browser because anything that reads the browsers data (or attaches a debugger, or runs the browser in an instrumented VM, etc...) can exfiltrate the key.
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.
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.
> 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.
> 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.
This does not follow from my understanding of the word, and the words 'export' and 'exportable' don't appear on the page you've linked. Nor did I see anything indicating that was a core part of their design from a cursory reading of the page, although I might have missed something. Your quote certainly doesn't imply 'exportable'.
Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended. To quote Tim Cappalli, who's credited on the W3C spec as an editor[1] and maintains passkeys.dev,[2] so presumably knows what he's talking about: "Passkeys should never be allowed to be exported in clear text."[3]
> 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.
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.
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.
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.
Like how everyone stopped using Google/Gmail, Facebook/Instagram and Windows/Office365 and flocked to alternatives?
Let's flip your suggestion. What if someone says if you need "high security" build a competing service that enforces it, no one is forcing you to use a "low security" service ?
The main problem in my mind is on the side of the vendors, attestation, secure hardware, etc is all an excuse to lock you in to their device/ecosystem.
Why would that suddenly change in Netflix or some other company's favor at Apple's direct expense?
So you are now locked in to the apple ecosystem forever. You now need Apple to watch Netflix from your Samsung TV.
But man... I cannot tell you how many people don't even notice the walls of the garden. Besides Apple is in competition with some huge players, more than capable of offering "Done with Apple literally trapping you? Follow this link and we'll transfer your passkeys."
That's the whole point of the FIDO specs. This is now literally impossible to do. All the vendors are weirdly okay with this I believe it's because it cuts both ways.
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'm different!" says this particular scorpion - yeah yeah, I don't believe you.
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.
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."
I do believe this is a policy failure and that a law should exist mandating cash acceptance “for all debts public and private”, but there is nearly zero chance of such a law ever passing in the US.
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.
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".
Want to dance? Yes | Maybe Later
I remember that comment, it's perfect.
> Addendum: I feel I have made a compelling case for passkeys in this article. And I haven’t even pointed out one of their best security features: they are (in most use cases) domain-bound, meaning they are resistant to what are called Man-In-The-Middle attacks.
"I made a compelling case... but didn't point out the most important security feature that motivated passkeys in the first place"
Honestly I don't think this post did make a compelling case. There's a lot of assuming bad faith on the part of the FIDO alliance, while completely missing that preventing MITM attacks was a key design feature. The FIDO alliance members deal with stolen accounts all the time, and passkeys largely solve that. Stealing accounts is almost always done with phishing or social engineering, and passkeys solve the former and reduce the surface for the latter.
The 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.
Especially considering how easy it still is to do a SIM swap.
If you aren't talking from a US perspective, where are you that SIM swap is a low bar?
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.
And Grandpa will have fun if he has to juggle 20 passkeys with different security requirements on his devices.
But as I said, there are plenty of UX issues with passkeys, those UX issues however don't include getting your accounts hacked, phished, passwords lost in data breaches, etc, which I'd suggest are a lot worse.
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.
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".
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.
My point is the gains are overstated the main weakness is almost always user action. Passkeys will not magically solve all our security problems.
Instead we’re increasingly locked out of devices we buy and told/mandated this is how you’ll use them.
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...
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.
See my comment here https://news.ycombinator.com/item?id=50049311 about userVerification: required. Passkey in 1Password used to be on par or slightly more difficult than filling in TOTP codes (need to click to approve rather than browser extension autofill and even auto-submit on a large number of websites) but that’s no longer true with a good number of websites requiring userVerification. Now you have to type in your login password on desktops without biometrics. Forum thread: https://www.1password.community/1password-at-home-31/user-ve...
I think the bit about TOTP was mostly a joke, the problem with passkeys is that they're billed as a replacement for passwords but they mix lots of MFA concerns in and make interoperability essentially impossible a lot of the time.
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
They’re both equally disposable. You can reset a password just like you can reset a passkey.
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.
Yeah and neither will anyone else!
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.
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.
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.
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.
Substitute apple with google, pay card with youtube comment and iphone with android for the "open" experience.
Expand on this? Haven't heard of this failure mode.
tldr from memory: Guy used 2 legitimately purchased gift cards that had been tampered and their codes were used by someone else. His account was locked with no recurse.
I think he could still use his phone, but all the online stuff were locked down. He only managed to get it back after his case reached this website(hn) and senior Apple people stepped in.
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.
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.
The tone hair-splitting makes it seem like you weren't going to be that receptive to the point anyway, no matter how many layers of subtext are inserted to abstract away the actual point, that being - Passkeys are a trap. Do not use them.
It wasn't a pointless rant, you're seemingly primed for something that didn't happen here.
It's a good argument that passkeys are a trap while TOTPs offer the security you need but avoid the absolute control passkeys may hand over, so stick with those.
With passkeys I click once and I'm in like the golden age of using the web with a password manager in 2012. It's a huge quality of life improvement. If people want to avoid passkeys for whatever reason, that's fine but not interested in reading the same slippery slope argument that gets reposted every week.
A recurring issue with these critiques is how they seemingly presuppose passkeys are an all or nothing thing, and losing your passkey means losing access entirely. Which isn't how it works basically anywhere. It's just another auth method, if you can't use a passkey you fall back to whatever recovery method is offered. If passkeys became some user hostile trap overnight I'd just unenroll them and use TOTP, SMS 2FA, email 2FA, or whatever else is supported.
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.
But as for how it could "catch" you: if you use FOSS devices that are unattestable (as is the case for the LineageOS phone and Linux laptop I exclusively use), you may one day find you can't use many websites.
This (before they go on to describe actual passkeys) sounds like object capabilities to me. Capabilities combine designation and authorization so if you don't have it, you can't use it. It's the type of security that we should be moving to.
Passkey attestation sounds like a nightmare for user privacy and for anyone that doesn't use a major corporate operating system.
Passkeys 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'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
Although this isn't true because actually with a password you have to choose how to generate it and everyone chooses different ways.
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.
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.
Passkeys offer the same and more security but are less of a pain for the user.
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.
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.
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>.
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.
While that is an option, I've been using passkeys on Amazon since 2023.
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.
That's literally what a passkey is, that the linked article argues against. It relies on the platform vendor of your device hardware to validate the full stack of software. You can't just do it in a browser because anything that reads the browsers data (or attaches a debugger, or runs the browser in an instrumented VM, etc...) can exfiltrate the key.
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.
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.
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.
That’s an out-of-date view. The number one attack vector these days is cookie stealing.
No, fuck that. Just let me use an SSH cert at that point. The existence of phishing is a comparatively minor evil.
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.
> 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.
That's not the intention of the relevant standards.[1]
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
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.
> The name "passkeys" itself means "exportable keys":
> https://fidoalliance.org/passkeys/
This does not follow from my understanding of the word, and the words 'export' and 'exportable' don't appear on the page you've linked. Nor did I see anything indicating that was a core part of their design from a cursory reading of the page, although I might have missed something. Your quote certainly doesn't imply 'exportable'.
Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended. To quote Tim Cappalli, who's credited on the W3C spec as an editor[1] and maintains passkeys.dev,[2] so presumably knows what he's talking about: "Passkeys should never be allowed to be exported in clear text."[3]
[1] https://www.w3.org/TR/webauthn/
[2] https://passkeys.dev/about/
[3] https://github.com/keepassxreboot/keepassxc/issues/10407