> 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 (I attested) 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.
This is already in the spec. It's not some faraway hypothetical, they could start requiring this tomorrow if they wanted to. And if you're capable of seeing any trends wrt the 'attestation' and 'securing' everything that are already here, you will know that all they're waiting for is for a significant enough portion of users to get passkeys on their platforms naturally, and then just force everyone else.
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
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.
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.
Right. For clarity: the choices are "use a third party authentication mechanism (like passkeys)" or "roll your own". And among vendors that continue to roll their own authentication, even the largest and most capable (like Amazon) don't try to do crypto like the upthread commenter was suggesting. It's just not practical unless you control the hardware platform. Passwords and telephone-2FA remain the rule.
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.
Passkeys is just a new brand name and UX flow on top of Webauthn. If you've handled Webauthn keys before you have already seen the code to "implement" passkeys.
A passkey is webauthn you can use on another device, if you choose to store the key in a place that can be shared. Passkeys also include a protocol where you can log in over BLE from (for instance) your phone to your computer if you store your keys on a different device than the one you're logging into.
If you use webauthn, you're already using passkeys.
Because the various cloud providers want to lock you into their own proprietary ecosystem, of course. How else could they in the future force you to pay a subscription to be allowed to log in to any website?
Backwards compatibility. Webauthn is the same standard that has been used for physical security keys for decades. Passkeys are a simplification UX layer on top of decades of hardware support and a complex ecosystem of key providers and key types.
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.
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.
This "use a passcode from another device such as my phone" tech mentioned above is just Bluetooth LTE. Every phone and most laptops and desktops in the last decade or so has Bluetooth LTE support. Hardware support is very good.
Passkeys are built on Webauthn (and ultimately sort of synonymous with it) and that has always been the web standard for all physical key support such as Yubikey and is basically the same as it has been for decades when dealing with Passkeys only with updated UX on top. Hardware support here is pretty good, too.
Bluetooth is very hard to use. This just isn't about hardware support, it's about "how long does it actually take the average person to do a Bluetooth-mediated workflow, how consistent is it between devices, if someone is trying it with a new device, what is the learning curve?" If someone can't figure out how it's supposed to work between their iPhone and their Windows laptop, there might theoretically be support. Practically speaking it's broken most of the time.
The deeper problem is that the default behavior is storing a passkey directly on a specific device and hardware-locking it to that device. That's great if you're an enterprise or whatever and you've got SSO set up well. For the average person, "I lose my iPhone and it effectively resets all my passwords" is a hopelessly unusable workflow.
The other device has to respond "in nearby radio space" via Bluetooth LTE when using the QR code bootstrap, but that's about the only requirement and it can be just about any device.
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.
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.
Except that those "self-contained hardware modules" are actually rarely "self-contained" but usually an integral part of a smartphone running a huge bunch of mostly-untrusted code and that the containment keeps getting breached, of course.
I'm using a Yubikey that is permanently plugged into a USB-C port on my laptop and another one in my dock at home.
> Except that those "self-contained hardware modules" are actually rarely "self-contained" but usually an integral part of a smartphone running a huge bunch of mostly-untrusted code and that the containment keeps getting breached, of course.
And it actually doesn't matter if the secure device is designed correctly. Providing a secure channel over untrusted networks is something that we can do easily.
> And you still don't get to use Passkeys with banks, of course.
I can. I'm using US Bank and it supports my Yubikey-bound WebAuthn credential just fine.
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.
> 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...
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.
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.
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.
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.
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.
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.
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 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?
>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.
And every critic always attacks this same thing. TOTP isn’t so bad, my password manager can do it. 2FA is fine it’s automatically pulled from my phone.
It’s still phishable. The password is still sent. You haven’t solved anything, you just piled more complexity on top to make it harder. People can still use the same password at 12 websites.
Passkeys never get transmitted. If you hack into a server and steal my credentials, all you get is a public key. You can’t use it at another website. A bad developer can store my password or TOTP secret in a way that makes it useful to a thief. That’s not possible with Passkeys.
No one ever offers an alternative other than saying it’s irrelevant. Despite practical experience showing otherwise.
Passkeys work and make my life better. These constant rants remind me of seeing people argue that the GUIs are a waste of time and no one will ever use them and it’s a fad that will go away and the only reason everyone’s talking about them is companies want to sell graphics cards and mice.
Passkeys work because you always have the hardware for them.
Suppose I had only passkeys and Google Pay. I take a train into town and lose my phone. What then? I'm screwed.
I couldn't just go home because I'd need to buy a ticket using my phone. I couldn't buy a replacement phone. I wouldn't be able to online shop on a library computer. I can't even contact anyone unless I know their number and borrow a phone or find a way to send an email.
My preferred balance of risk vs convenience is: passwords in a password manager, hardware-based 2FA only for making account changes, and confirmation emails (My email password is not in my password vault.) any time a site successfully or unsuccessfully processes a login attempt.
There is no hardware element. If someone phishes my password, I'll know right away from the login email, unless they're so talented or lucky that they also accessed my email or found a way to spoof my 2FA. If I lose my phone, I'm not totally helpless. I don't see an overall downside to my strategy that isn't worse than passkeys.
Not the concern, it's whether it's worth the time and energy to expand passkeys as the default and getting normies using them. Some people will always surrender and say they have nothing to hide, so be it. I'm more thinking about the practical rough edges that user bases will cut themselves on once you expand past the extremely-online.
From my experience, it's a nonstarter. The expectation that normies will understand and maintain a password manager layer to store their digital keys in and understand that concepts end such as sharing passwords or logging in on a new device without fully bootstrapping the password manager is just too far.
I think sometime after Q-Day when the dust settles and we've had to reissue all the keys today, we'll have a better answer on whether the specter of remote attestation is truly manifesting and in any event I bet there'll probably be an updated passkey concept by then.
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.
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.
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'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.
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:
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.
Third parties manage nearly all my money, my future wealth, the quality of the water I drink, etc.
Yes you need to put thought into who you trust to provide password management but for most people having a professional third party help them improve how they use passwords will be a benefit to security overall.
You have the option of TOTP that gives you 100% of the control, privacy, and portability. Yet, for minor inconvenience, you are ready to sacrifice all of this. Why?
TOTP does not replace passwords, and frankly I’m sort of confused why you think they do. Doing passwords right across a multitude of websites is more than a minor inconvenience unless I am willing to simply give up on security.
> 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.
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.
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.
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.
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."
They don't care about how much older, more secure, more trustworthy and so on your domain is. That's not the issue they're having. The issue is that you are 'abnormal', and it is in the common interest of tech companies to make any signs of abnormality (read: not-total compliance to their whims) to be inherently suspicious and nefarious behavior that needs to be curtailed.
Vote with your wallet. I've only experienced two instances where systems wouldn't accept my custom email domain. One was a bank. I proceeded to close the account.
I started a typical registration process: enter e-mail, click on confirmation link, but the confirmation link showed a generic error the first time and then a "link expired" afterwards. I tried again a few hours later and then contacted support when the same thing happened. The response after a few days:
> BAND currently permits sign‑ups and linking only with certain email domains. If you want to create a BAND account using an email address, please use a more public domain such as Gmail, Hotmail, Yahoo, etc.
Strangest one still was the answer my mom got from Macy's. She is very persistent and was eventually told that Macy's does not support domains that have been registered with GoDaddy (note that the e-mail is not hosted by GoDaddy, just the domain is registered with them).
> 2. You can't sign up for accounts with an e-mail from a "custom domain"
I remember debugging apple account creation because of that for a few hours. It wouldn't even tell me that my email domain/host was the issue, simply fail at the last step.
The same thing exists for phone numbers. About 90% of my calls with US banks go like this:
"Ok, first, to verify you, what's your phone number?" (oh no, it's one of those, because why do they need to ask...) "<my phone number>" "Ok, you'll receive a te— oh. Oh no. This is not a real phone number. What's your REAL phone number?"
VoIP, in my case. Probably much more secure than the average big three carrier plan from a SIM swapping perspective, but try convincing banks or their “security” service providers.
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.
> 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."
> 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.
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.
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.
The concern you're raising here is that the government might secretly force big companies like Facebook or Google to require attested passkeys that restrict usage to only approved first-party keystores right?
Passkeys exist now and there's no taking them back. However, even if they did not, the government might well just develop its own authentication system and require that it be used under policies that require age verification for social media, for example. Hell, they might end up doing that anyway, and that would be no different. If the government wants to force tracking/verification on certain websites, it won't simply be something they walk away from if Passkeys don't exist. You can only fight this with your vote and by not using those services once they implement such controls.
> Passkeys exist now and there's no taking them back.
I mean, we can take them back. Everybody refuse to use them and cause as much trouble as possible for anyone who tries to make you. Use TOTP or similar instead.
> If the government wants to force tracking/verification on certain websites, it won't simply be something they walk away from if Passkeys don't exist.
The way you fight things like this is by making it so the current technology is incapable of doing it and then if they try to legislate it, you have more time to roll back the policy before the technology to support it can be developed and imposed on everyone.
Implementing support for the dystopian technology before the law even requires it is the opposite of that.
> 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 ?
The people don't care enough to bother, and that's fine - it's not your (or my) place to force other people to do anything.
My point was not about getting critical mass, it's that the service can already do anything they like to lock people into whatever they want and gatekeep their service. They can do it with Passkeys, or they can do it with a proprietary alternative and if they're big enough, they'll get away with it. Neither of us can sway them at all - I wasn't saying they should do this, only that they can.
Blaming Passkeys is aiming at the wrong target. Passkeys rightly offer features that have valid use-cases, even the attestation in the right context. Can they be abused? Probably, but so can just about anything. Passkeys do, on the other hand, offer some real tangible benefits that other mainstream solutions do not.
> The people don't care enough to bother, and that's fine - it's not your (or my) place to force other people to do anything.
Yeah it wasn't your place or anyone else's. Neither you nor I and most HN'ers want to or are in a position to force anyone. Why even assume that anybody is trying to do that here of all places.
> Can they be abused? Probably, but so can just about anything. Passkeys do, on the other hand, offer some real tangible benefits that other mainstream solutions do not.
Let the usecases that need passkeys use it.
Why can't there be a parallel standard with similar features that doesn't have the parts that can potentially be abused. If the difference between abuse and non-abuse is a vague promise and the good graces of corporate structures, it is better to err on the side of caution and demand solutions that make it impossible.
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.
What baby? Oh boy, a new authentication method just as secure as my unique per-site random password that I keep in my password manager already anyway, except I also completely lose access to it if I ever get locked out of my Google devices. The future is truly revolutionary.
I believe passkeys can be made phishing resistant, as they can be cryptographically bound to a given application, and the application has to attest itself to your system too.
You won't be able to use your google account passkey to log into the perfect clone of "gmail.com" where the 'a' is actually a greek or cyrillic letter or something, and neither will your ageing parents. You could still paste your password into the fake site from your password manager, or the spyware on your computer could still sniff it from your clipboard.
...until you login to, say, your Microsoft account on one of like 27 domains that use the same SSO and your autofill doesn't trigger so you just grumble to yourself "man I hate the modern web" and manually copy/paste it in.
Hopefully after thoroughly checking the URL but you only have two minutes before the Uber gets here and just need to get this one last thing done ASAP...
But users can and do override this decision. "Huh, why isn't 1Password autofilling my password on bank0f4merica.com? Let me quickly select 'autofill and remember'..."
I'm somewhat desensitized to this myself for non-bank use cases. It's unfortunately necessary with corporate merges and rebrands. After all, how is my password manager supposed to know that it's safe to fill my hulu.com password on disneyplus.com? The same applies to mobile apps providing some-outsourcing-vendor.com instead of my-actual-service-provider.com etc.
Being able to enter my Hulu password on disneyplus.com is a feature, being able to enter my Bank of America password on bank0famerica.com is a bug. The problem is that the same behavior causes both.
Name one password manager with an "autofill and remember..." action that fills passwords from unrelated domains.
You're spreading nothing more than FUD. This is a completely imaginary threat vector that doesn't exist. And even threats that do exist don't always justfity security at every cost. The optimum amount of security is never 100%.
Passkeys are stored in your password manager, too. You'll only lose access to your passkeys if Google is your password manager and you get locked out of your Google account. So, if you don't trust Google, use another password manager. (May I recommend Bitwarden?)
The advantage of passkeys is that no one can trick you into giving your passkeys to the wrong person. Every time this comes up, people say "I don't need that! I've got a password manager. I'm too smart to get tricked." But they are wrong.
The concern is that the site you're logging into can tell the difference between a passkey created by Google on a (recent, non-rooted, locked bootloader) Android device using its cryptoprocessor, and a passkey created by Bitwarden which you can sync/backup as you like. And Google, Apple & Microsoft are well positioned to encourage people towards the former over the latter.
The possibility that sites will require attested keys does seem pretty remote at the moment, but if passkeys take off and >95% of people use keys tied to their phone, I could totally see sites starting to prevent you using a key from Bitwarden. I don't think there's a conspiracy trying to achieve this, but the incentives of security & lock-in could push us there.
Exactly. We saw this with banking apps forcing use to use insecure but attested devices for their insurances. Fool me once... no thank you to passkeys for now.
> To suggest that people should stop using Passkeys over this is throwing the baby out with the bathwater.
Nah, it's fair to regard anything that supports remote attestation as toxic and aggressively thrust it into the biohazard waste incinerator. Any whiff of remote attestation, even being adjacent to it, and an angry mob should appear to burn your entire castle to the ground. Deters companies from wanting to be associated with it.
Also impedes the motte and bailey where they claim you can opt out of it until it's entrenched enough that you can't.
> no-one is forcing you to use said service in that case.
Until something with a monopoly or both halves of a duopoly or a strong network effect starts demanding it.
>> no-one is forcing you to use said service in that case
What remotely attested passkeys will really start being adopted for -- blocking consumer AI agent use.
Think about how many billable products are essentially convenience automation on top of a user's existing access in a platform?
What if consumers start using AI agents to interact with platforms in ways that skip those billing toll gates (because their agents are remixing actions / data on the user side)?
Both the intended (I'm skipping a premium charge) and unintended (I used a hacked agent and/or my agent went awry) are going to become major issues for companies in the next 5 years.
And the question will be asked "Can't we just ban user AI from using our app?"
Attested passkeys are going to be an awfully tempting option to reach for as an answer. Especially for banks. (Fuck banks' technology stacks)
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.
I've been menionting this a lot and it feels like no one is listening. These 3rd and 2nd party actors are expecting for you to pay for equipment for them. It's insane.
More context: I've been saying this a lot about this in the scan and go at sams club and how there are fanatics that act like it's a good thing and to be the only way to pay.
Just gotta hope that based on how economic theory is supposed to work, if doing these things result in saving costs during procurement of specialized equipment, the savings are passed on to the consumer… hopefully…
In this case it's not. It's removing employees, but there is no notice cost decrease in product. There's just re-enforcement of "you didn't rob us". (Checks at the end, etc).
You'll pay for their security measures either way. Does it really matter that much if you see the line item charge or if it's baked into your interest rate spread?
It does matter though. If the cost comes out of their budget they have different incentives than if the cost is born by the customers in some semi-hidden fashion.
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.
Just go into r/Magisk, about 9 of 10 posts is a user whose banking app fails attestation.
Fuck banks with a cactus for forcing us to relinquish our freedoms as a precondition of interacting with them, which is a precondition to exist in most societies.
Sure, mobile device app attestation is a big problem for openness, but it has nothing to do with passkeys, where attestation is effectively dead for non-enterprise uses.
Arguably, even passkeys with attestation would be a step forward compared to that, as banks could require an external authenticator tap on a rooted device, or signature of some sandboxed secure element that runs independently from the application OS.
> Sure, mobile device app attestation is a big problem for openness, but it has nothing to do with passkeys, where attestation is effectively dead for non-enterprise uses.
It’sead so far. Again, X.com could ask you to re-enroll your passkey next time you sign in, but this time requiring attestation.
> banks could require [...a] signature of some sandboxed secure element that runs independently from the application OS
> How? Almost none of their users own an authenticator capable of attestation (i.e., a Yubikey or similar).
I haven’t checked, but I suppose both Google and Apple have passkeys implementations capable of attestation? (If not, it should be fairly easy to add, and considering Google has been pushing for various “integrity” bullshit, this would be a no-brainer for them.)
> They can't, because open/neutral access secure elements do not exist yet, and nobody really wants to carry an external one.
Presumably, banks trust Google, so if Android doesn’t erase attestation information from the HSM when unlocking the bootloader, they could use this process to verify that the key they’ve generated is stored there, regardless of whatever other software the user is running. (If Android does erase attestation info then eh, it’s just as bad as relying on Play Integrity APIs.)
Apple used to support attestation but removed it. That alone makes it non-viable for sites to enforce attestation.
> I’m not 100% sure if this would work: [...]
I believe it might, but like you I'm not sure if they really don't measure some secure boot properties into that keystore these days.
It's also usually implemented in TEEs and attested by the device manufacturer, which means there's a high chance of getting either insecure implementations in the mix or ending up with a heterogeneous mess of supported and non-supported manufacturers varying from bank to bank.
FIDO at least has their manufacturer directory; not sure if Google has something similar for Android (and if it does, whether non Google certified Android OEMs may apply).
Fuck Play Integrity, which is what Google implements, with these drawbacks very much intentionally in place, and 'recommended' banks implement for security. Fuck Google for doing everything they can to make custom roms fail these API's ever more.
There is an alternative* of which I haven't heard in a while.
Fuck all of that. We don't need attestation. We have been handling money online without attestation for over 30 years. Sandboxes and operating system isolation is only getting better. Pwned devices is not the main problem, people getting phissed is the main problem. You don't need attestation to defend against that.
On my GrapheneOS phone, the only things that I came across that require (and thus fail) maximum level attestation are Google Pay and the app for McDonald's for some reason.
Yes, the same banks that simultaneously don't support 2FA, or only support it via SMS, while insisting that mobile devices pass attestation. Also the same banks that still accept swiped credit card transactions but god forbid you want to register a custom non-attested device for wireless payment transactions. Those banks. Lets not pretend that the policies of US banks are by and large either internally consistent or in the customer's best interests.
Don't they support swiped credit card transactions because they can pass the increased cost of fraud onto merchants in the form of increased transaction and chargeback fees?
Are merchants obligated to accept swipe transactions?
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 functionality that actually touches your money 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.
> 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.
Of course not, you still have some control over those FIDO2 hardware keys and they don't lock you to a limited set of devices. That's what the attestation is for, to allow banning the use of sign-in with anything but a couple megacorp providers. The few small time hangers on will be expelled in time. They're useful idiots for the adoption phase.
Notice that after lots of complaining about there being no way to transfer keys in the spec they developed some planned working group that will in the end only allow transferring from Google/Microsoft/Apple and maybe a few other dumpster companies. They aren't going to give that control up.
> 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.
Ah, yet another case of people being forced to use technology instead of being left alone doing things the old way where they understood all the risks.
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.
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.
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 th...
> Email OTPs, notably, aren't 2FA by definition, since your Email address might be only password-protected
What? 2FA is something I have, something I know. I know my password for your web app, and I have access to a separate account. It's not a recursive 2FA, "it's only 2FA if one of the factors has its own 2FA".
The "something you have" means "something you physically possess and can't be copied". Logging in with username, password and an email OTP is 2-step authentication, not 2-factor, as multiple people can have access to the email account from different places at the same time.
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).
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.
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?
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.
Why would they need to re-generate? Pretty much all websites are using copyable passkeys. The user just needs log in to their password manager on their new device. Which for most people just means logging in to their Apple or Google account. There is virtually no difference to storing generated passwords in a password manager or storing passkeys.
And the sad truth is: Most people have no password manager at all. They are used to re-generate new passwords every time they want to log in! I'd wager that on some websites the vast majority of people are loggin in by pressing "I forgot my password".
AFAIK the whole point of attested passkeys is that they are not copyable, which make it pointless to backup in apple cloud, which must be one of the main reason Apple decided to not go that route.
Backup and syncing has indeed been mentioned many times as a factor by Apple why they don't think supporting attestation for consumers makes sense. Consumers need easy/automatic backup and syncing for these keys to be used at all in the consumer world by non-technical users. It is the "it just works" of Passkey management.
Apple has also made it clear they have privacy concerns about attestation as well, which is also why they don't support it, but backup and syncing are clearly very important to Apple because that is very important to keeping consumers happy.
This is a generalized argument to be worried about anything, though. They did it before and then decided against it? Well, they could go back to doing it again! They've never done it? Well, they could decide to start doing it tomorrow!
More seriously, the fact that Apple previously implemented something and then removed that implementation gives us multiple pieces of information: they are technically capable of implementing it (not a huge surprise), at one point they thought that it was a good idea to implement it, at a later point they thought that it was not a good idea to implement it, they're willing to backtrack on implementation decisions in certain situations, etc... Depending on how you weight these different pieces of information, you can reach different conclusions about how likely reimplementation is in the future.
To fill out a bit more of the story, they also stopped supporting consumer attestation after arriving at a "good enough" compromise that they felt was more privacy supporting and better worked with backupable/syncable keys, the uvi and uvm extensions for Webauthn which they championed to standards. Once those standards were in place they especially saw no reason to support consumer attestation.
(Those extensions are for a Passkey manager to "solemnly swear" to an RP that a key was involved in some sort of MFA dance such as PIN unlock or biometric unlock and maybe a little bit of rough detail of what sort. Much more rough than Attestation details and not attested claims at all so a Passkey manager could lie about them, but that's enough for the sort of regulatory compliance or "due diligence" that many Banks might need from consumers to replace existing MFA logins with Passkeys. It is a relatively strong bulwark against attestation requirements for consumers.)
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.
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.
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
> 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.
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.
Because it prevents an attacker from stealing the password. It's both extremely hard to "steal" a passkey, and to phish a login from one. Neither of those are true for passwords, and TOTP only partially solves the stealing part.
Passkeys aren't solving for security nerds who like portability and have 30 character long passwords, they're solving for grandpa who will happily read their bank's 2FA SMS to the "bank" over the phone. The FIDO alliance has literally billions more of these users than they do users who know what hardware attestation is and how it impacts their auth workflows.
So companies can use passkeys and set policies around what hardware they're stored on. IMHO, not particularly useful or desirable for everyday Internet users, but really nice if you have specific requirements.
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.
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?
Passkeys are unphishable. It’s technically impossible for someone else to capture your passkey and use it themselves. It’s technically impossible for your passkey to be leaked from a website.
This is what makes Passkeys the superior solution - they bake the security into itself rather than throwing up its hands and hoping all the other weakest links do the right thing consistently.
> Especially considering how easy it still is to do a SIM swap.
Heh.
Several months ago, I found myself in need of a new phone. I even had the means to do an orderly transition, with the old one still in hand and mostly working.
My mobile provider was an MVNO that was also my home ISP. I had enabled "enhanced security" to prevent ev0l hackerz from swapping my SIM without authorization. It turns out that this mode is so secure that it prevented me and the support staff from a normal upgrade procedure.
There were various glitches along the way, and a conversation with certain LLMs indicated that the SIM->eSIM disparity was also causing trouble, and with the online system's rejection of authentication I decided it was expedient to walk into their nearby storefront location.
It turns out that the salespeople in the storefronts are not really empowered in any technical way, except they were quite capable of changing my password without any reason, and wasting my time, so leaving the store empty-handed after mind games from three haughty female STEM dropouts was rather infuriating.
The process eventually succeeded after giving it a little time, space, and grace, but it looks like I'm leaving "enhanced security" disabled if it's so customer-hostile.
That's been my experience, too. I don't remember the store worker's details, though. I'm curious how the gender of the STEM dropouts affected the process.
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.
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.
We have been trying to get users to use good passwords since passwords were invented, and still haven't managed to get them to use unique passwords. It clearly doesn't work.
You know what MITM is, yes? There are a ton of points between you and that hash algorithm, and any single one immediately and permanently compromises you.
>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?
If the spec doesn’t guarantee portability, they’ll boil the frog to make sure you don’t get any.
> 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.
And their friends won’t care until they’re personally affected.
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.
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.
That’s an out-of-date view. The number one attack vector these days is cookie stealing. The prevalence of 2FA even weak ones like SMS-based 2FA has made plain old phishing so much less effective.
That's not correct - more than 1/3 of initial access is by phishing at present, according to Cisco Talos (and others major security publications largely agree with this). Ref: https://blog.talosintelligence.com/ir-trends-q1-2026/
What you may be confusing with is the number of incidents involving token theft, which is often facilitated by phishing.
That publication is talking about phishing as a threat to workers inside corporations and government agencies and public administrations. It’s not a thing for regular consumers. Passkeys aren’t usually used in corporate environments with an IT department anyways.
> 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). ...
People say this, but is this scenario possible: user (foolishly) clicks an unsafe link to a look-alike bad site. Bad site requests new passkey and user is tricked into supplying one. Bad site agent, with proper passkey to real site, forwards traffic. Result is MitM.
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.
Sharing and phishing are on two different axis. You can have shareable credentials that are phishing-resistant when used.
You can have hardware-backed SSH keys that are not cloneable. You would need the browser to prevent phishing while still using SSH agent as its underlying signature mechanism (implied by my "in a consumer package").
Right, which is why Passkeys are consumer-minded enhancement to SSH keys in that browsers are asked to require that every domain gets a different passkey. I've seen SSH agents with that requirement, but yes very few users of SSH use more than one public key per device at a time, and many even use the same private key across multiple devices rather than enroll multiple SSH public keys.
I agree: from an usability perspective, passkeys are awful and TOTP are excellent.
But the problem is: most of the time, the people that choose what security system you should use are the system administrators, not the end users. And they like passkeys because they are the easier for them to implement.
They require no server to send confirmation codes and no need to trust in unknown applications and their ambiguous key formats.
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.
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.
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.
> 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 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.
If you have or acquire an Apple Watch - yes, I know, it's a _different_ several hundred dollar device - and enable the "unlock your Mac with your Apple Watch" feature, it will function in _just_ about every place that Touch ID is required, including the 1Password Touch ID prompts. Like some other Apple functionality, it does some sort of fancy Wi-Fi/Bluetooth time-in-flight calculations to ensure the watch is close by before it unlocks your Mac, with a tap on the wrist and a button to re-lock your Mac if needed; and it requires a double-tap on the side button for application authentication prompts.
Huh I didn’t realize that feature worked with Mac Studio & mini too, thought it’s MacBook only. Definitely a solution for some. I have one gathering dust since the benefit of feeling nothing on my wrist outweighs the value it provides, after wearing one for a couple years.
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.
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.
For all I can tell it simply moved the popup widget from below the actual input to the top middle of the page, and now preemptively prompts a lot more aggressively, sometimes not even on a sign-in page.
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 :)
To be explicit, 1password did not offer passkey export for more than a year after they were introduced. 4 years later, here is 1password's page on exporting your data[1]. It says:
You can only export passkeys in 1Password for iOS and Android at this time.
So that's not great. Let's look at their page on the 1pux export[2]:
Your data is yours. If you want to export your data from 1Password for any reason, you can.
And the word "passkey" does not appear on that page. Why are these docs still written like this after 4 years?
And for the record, this is not impossible. Bitwarden does it[3] via the magic of "ignoring the part of the specification that says not to give users their data." Any open source software would do the same. This is why 1Password is no longer the "good guys" despite having rationalizations for their actions.
This is where the attestation feature comes in, there's a reason it was part of the initial spec and key transfer was a "we'll get to it later". They will use it as a weapon to blacklist providers that don't play by their rules.
If you want to see an example of pro-user behavior, read the github thread where a FIDO developer asked keepassxc to disallow exports of passkeys[1] or to reprompt for the db password if the website requests it[2]. The conversation was roughly:
> keepassxc: no
> FIDO devs: but the spec
> keepassxc: that part of the spec is anti-user
> FIDO devs: do it or we might blacklist your app
> keepassxc: can't we just impersonate another password manager? also isn't bitwarden already doing this?
> FIDO devs: "Someone else is doing bad things too" isn't the greatest argument...
> FIDO devs: maybe we could hop on a phone call?
> 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.
Does (more) here include free software like keepassxc and friends which don't restrict what key owners do with their keys? Last I heard, FIDO was moving to ban them.
Regarding just the iCloud syncing, I appreciate the additional color.
Though, I do find it amusing that I commented about 1password's inability to communicate their security model, and your reply links a reddit post[1] in which everyone is disagreeing over whether or not iCloud secret key syncing actually occurs.
> 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:
Note who is excluded from this list: the End User. The protocol only allows exchange between password manager vendors who choose to interconnect.
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.
Where is it required? If the answer is "nowhere before, but now that passkeys support it, places are starting to", then that's an argument that it's bad, not that it's good. And being able to "use the same passkey spec as everyone else without having to invent their own thing" is bad. I want them to all have to invent their own, so that most of them will make mistakes that let the attestation be bypassed and freedom be restored.
Lots of places where you might have specific requirements about your authenticating users. E.g. to achieve FIPS compliance, or if your user population is low-single-digits because it's critical national infrastructure.
> I want them to all have to invent their own, so that most of them will make mistakes that let the attestation be bypassed and freedom be restored.
I most definitely do not want operators of CNI to be "inventing their own" that can trivially allow compromise or weakness. "User freedom" is not the prevailing value in a lot of authentication contexts.
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
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 value statements down to a finite subset of cause-effect
Take HN for example; run a trend analysis on the comments going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth
Religious people are not the only ones who live in rhetorical fantasy
End of day the provenance of any socialized idea is some rando I have no obligation to march in lockstep with; physically or philosophically
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.
As somebody that’s had to deal with US banks and their bizarre “authentication” schemes: I wish.
Many would actually rather you close their account with them than them making the tiniest compromise or offering any alternative to their SOP at all. That SOP strongly assumes things like “all customers have a mobile phone plan with the big three carriers”, “all customers own property or at least have car insurance” (that’s already their authentication fallback flow!) etc.
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.
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.
> 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]
> 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.
I literally provided a citation.
> Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended.
A syncable credential is by necessity representable in clear text at some point. In comparison, resident WebAuthn private keys NEVER leave the secure device.
WebAuthn is a _superset_ of Passkeys. Here's the citation from your own linked page:
> This use case illustrates how a consumer-centric Relying Party can leverage the authenticator built-in to a user’s devices to provide phishing-resistant sign in using multi-device credentials (commonly referred to as synced passkeys).
...
> A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.
> A syncable credential is by necessity representable in clear text at some point.
I never said this was wrong.
> WebAuthn is a _superset_ of Passkeys
I don't see how your quote illustrates this, and I've only heard them referred to as the same thing. Would you care to elaborate? And maybe provide an example?
> multi-device credentials (commonly referred to as synced passkeys).
> A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential.
The previous name for single-device credentials was "resident keys".
So yes, providing a way to export and back up the Passkeys was _literally_ the intention of the WebAuthn authors from the beginning. The ability to export and sync passkeys was not a temporary accident, it has always been intended functionality.
> 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.
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?
Apple also built remote attestation into their browser, I don't think they care much about FOSS neckbeard hackers. They probably see the same privacy and security risks and didn't see a reason to go along with the rest.
Apple is perfectly fine with taking control of your privacy if they're the ones in control, and in this case they would have to put third parties in control instead. I'm sure they'd much rather take control themselves and build these types of checks into their "Sign in with Apple ID" buttons instead, so they can put "if you want Human Proven Secure Attested devices (invented by Apple), let your users sign in with Apple ID" on their website.
426 comments
[ 0.28 ms ] story [ 43.3 ms ] threadUse 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.
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
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.
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.
While that is an option, I've been using passkeys on Amazon since 2023.
If you use webauthn, you're already using passkeys.
2. The complexity in the standard is there to ensure things are done securely (think: not doing password checking via comparison loop).
3. The unnecessarily complexity in individual implementations in websites and passkey stores is due to general baseline corporate "incompetence".
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.
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
Passkeys are built on Webauthn (and ultimately sort of synonymous with it) and that has always been the web standard for all physical key support such as Yubikey and is basically the same as it has been for decades when dealing with Passkeys only with updated UX on top. Hardware support here is pretty good, too.
The deeper problem is that the default behavior is storing a passkey directly on a specific device and hardware-locking it to that device. That's great if you're an enterprise or whatever and you've got SSO set up well. For the average person, "I lose my iPhone and it effectively resets all my passwords" is a hopelessly unusable workflow.
Its Bluetooth LE, not LTE!
LTE is 4g, LE is a Bluetooth spec (literally means Low Energy).
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.
> Except that those "self-contained hardware modules" are actually rarely "self-contained" but usually an integral part of a smartphone running a huge bunch of mostly-untrusted code and that the containment keeps getting breached, of course.
And it actually doesn't matter if the secure device is designed correctly. Providing a secure channel over untrusted networks is something that we can do easily.
> And you still don't get to use Passkeys with banks, of course.
I can. I'm using US Bank and it supports my Yubikey-bound WebAuthn credential just fine.
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...
"Once certification and attestation goes live, there will be a minimum functional and security bar for providers."
https://github.com/keepassxreboot/keepassxc/issues/10406
> TOTP is great, flexible, and keeps the user in control
TOTP is vulnerable to MITM attacks, so it's at best acceptable.
Passkeys offer the same and more security but are less of a pain for the user.
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.
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.
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.
And every critic always attacks this same thing. TOTP isn’t so bad, my password manager can do it. 2FA is fine it’s automatically pulled from my phone.
It’s still phishable. The password is still sent. You haven’t solved anything, you just piled more complexity on top to make it harder. People can still use the same password at 12 websites.
Passkeys never get transmitted. If you hack into a server and steal my credentials, all you get is a public key. You can’t use it at another website. A bad developer can store my password or TOTP secret in a way that makes it useful to a thief. That’s not possible with Passkeys.
No one ever offers an alternative other than saying it’s irrelevant. Despite practical experience showing otherwise.
Passkeys work and make my life better. These constant rants remind me of seeing people argue that the GUIs are a waste of time and no one will ever use them and it’s a fad that will go away and the only reason everyone’s talking about them is companies want to sell graphics cards and mice.
Suppose I had only passkeys and Google Pay. I take a train into town and lose my phone. What then? I'm screwed.
I couldn't just go home because I'd need to buy a ticket using my phone. I couldn't buy a replacement phone. I wouldn't be able to online shop on a library computer. I can't even contact anyone unless I know their number and borrow a phone or find a way to send an email.
My preferred balance of risk vs convenience is: passwords in a password manager, hardware-based 2FA only for making account changes, and confirmation emails (My email password is not in my password vault.) any time a site successfully or unsuccessfully processes a login attempt.
There is no hardware element. If someone phishes my password, I'll know right away from the login email, unless they're so talented or lucky that they also accessed my email or found a way to spoof my 2FA. If I lose my phone, I'm not totally helpless. I don't see an overall downside to my strategy that isn't worse than passkeys.
Not the concern, it's whether it's worth the time and energy to expand passkeys as the default and getting normies using them. Some people will always surrender and say they have nothing to hide, so be it. I'm more thinking about the practical rough edges that user bases will cut themselves on once you expand past the extremely-online.
From my experience, it's a nonstarter. The expectation that normies will understand and maintain a password manager layer to store their digital keys in and understand that concepts end such as sharing passwords or logging in on a new device without fully bootstrapping the password manager is just too far.
I think sometime after Q-Day when the dust settles and we've had to reissue all the keys today, we'll have a better answer on whether the specter of remote attestation is truly manifesting and in any event I bet there'll probably be an updated passkey concept by then.
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.
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.
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.
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.
Want to dance? Yes | Maybe Later
I remember that comment, it's perfect.
I use passkeys all the time and absolutely have this on every account I care about.
Yes you need to put thought into who you trust to provide password management but for most people having a professional third party help them improve how they use passwords will be a benefit to security overall.
And I am not.
You can self host an open-source solution if you do not trust 3rd parties. I put high value on convenience. TOTP solutions are not as convenient.
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.
Sigh. It's OpenID (the original one) all over again? Everyone wants to be the auth provider, nobody wants to accept other auth providers.
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.
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."
Incredible... if I ever get that I'll enjoy pointing out I've had my domain longer than gmail has existed.
I started a typical registration process: enter e-mail, click on confirmation link, but the confirmation link showed a generic error the first time and then a "link expired" afterwards. I tried again a few hours later and then contacted support when the same thing happened. The response after a few days:
> BAND currently permits sign‑ups and linking only with certain email domains. If you want to create a BAND account using an email address, please use a more public domain such as Gmail, Hotmail, Yahoo, etc.
Strangest one still was the answer my mom got from Macy's. She is very persistent and was eventually told that Macy's does not support domains that have been registered with GoDaddy (note that the e-mail is not hosted by GoDaddy, just the domain is registered with them).
I remember debugging apple account creation because of that for a few hours. It wouldn't even tell me that my email domain/host was the issue, simply fail at the last step.
"Ok, first, to verify you, what's your phone number?" (oh no, it's one of those, because why do they need to ask...) "<my phone number>" "Ok, you'll receive a te— oh. Oh no. This is not a real phone number. What's your REAL phone number?"
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.
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."
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.
Passkeys exist now and there's no taking them back. However, even if they did not, the government might well just develop its own authentication system and require that it be used under policies that require age verification for social media, for example. Hell, they might end up doing that anyway, and that would be no different. If the government wants to force tracking/verification on certain websites, it won't simply be something they walk away from if Passkeys don't exist. You can only fight this with your vote and by not using those services once they implement such controls.
I mean, we can take them back. Everybody refuse to use them and cause as much trouble as possible for anyone who tries to make you. Use TOTP or similar instead.
> If the government wants to force tracking/verification on certain websites, it won't simply be something they walk away from if Passkeys don't exist.
The way you fight things like this is by making it so the current technology is incapable of doing it and then if they try to legislate it, you have more time to roll back the policy before the technology to support it can be developed and imposed on everyone.
Implementing support for the dystopian technology before the law even requires it is the opposite of that.
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 ?
My point was not about getting critical mass, it's that the service can already do anything they like to lock people into whatever they want and gatekeep their service. They can do it with Passkeys, or they can do it with a proprietary alternative and if they're big enough, they'll get away with it. Neither of us can sway them at all - I wasn't saying they should do this, only that they can.
Blaming Passkeys is aiming at the wrong target. Passkeys rightly offer features that have valid use-cases, even the attestation in the right context. Can they be abused? Probably, but so can just about anything. Passkeys do, on the other hand, offer some real tangible benefits that other mainstream solutions do not.
Yeah it wasn't your place or anyone else's. Neither you nor I and most HN'ers want to or are in a position to force anyone. Why even assume that anybody is trying to do that here of all places.
> Can they be abused? Probably, but so can just about anything. Passkeys do, on the other hand, offer some real tangible benefits that other mainstream solutions do not.
Let the usecases that need passkeys use it.
Why can't there be a parallel standard with similar features that doesn't have the parts that can potentially be abused. If the difference between abuse and non-abuse is a vague promise and the good graces of corporate structures, it is better to err on the side of caution and demand solutions that make it impossible.
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.
You won't be able to use your google account passkey to log into the perfect clone of "gmail.com" where the 'a' is actually a greek or cyrillic letter or something, and neither will your ageing parents. You could still paste your password into the fake site from your password manager, or the spyware on your computer could still sniff it from your clipboard.
Hopefully after thoroughly checking the URL but you only have two minutes before the Uber gets here and just need to get this one last thing done ASAP...
I'm somewhat desensitized to this myself for non-bank use cases. It's unfortunately necessary with corporate merges and rebrands. After all, how is my password manager supposed to know that it's safe to fill my hulu.com password on disneyplus.com? The same applies to mobile apps providing some-outsourcing-vendor.com instead of my-actual-service-provider.com etc.
For passkeys, there's native support for that type of thing using "related origin requests": https://web.dev/articles/webauthn-related-origin-requests
Yes. That is a feature, not a bug.
Transferability and delegation of authority are features. Calling them "phishing vectors" only makes them seem like a bug.
Being able to give your Hulu or Bank of America password to your spouse is a feature, but giving it to a scammer is a bug.
Can't have one without the other, but I disagree making credentials non-transferrable is the right choice.
You're spreading nothing more than FUD. This is a completely imaginary threat vector that doesn't exist. And even threats that do exist don't always justfity security at every cost. The optimum amount of security is never 100%.
The advantage of passkeys is that no one can trick you into giving your passkeys to the wrong person. Every time this comes up, people say "I don't need that! I've got a password manager. I'm too smart to get tricked." But they are wrong.
The possibility that sites will require attested keys does seem pretty remote at the moment, but if passkeys take off and >95% of people use keys tied to their phone, I could totally see sites starting to prevent you using a key from Bitwarden. I don't think there's a conspiracy trying to achieve this, but the incentives of security & lock-in could push us there.
Nah, it's fair to regard anything that supports remote attestation as toxic and aggressively thrust it into the biohazard waste incinerator. Any whiff of remote attestation, even being adjacent to it, and an angry mob should appear to burn your entire castle to the ground. Deters companies from wanting to be associated with it.
Also impedes the motte and bailey where they claim you can opt out of it until it's entrenched enough that you can't.
> no-one is forcing you to use said service in that case.
Until something with a monopoly or both halves of a duopoly or a strong network effect starts demanding it.
What remotely attested passkeys will really start being adopted for -- blocking consumer AI agent use.
Think about how many billable products are essentially convenience automation on top of a user's existing access in a platform?
What if consumers start using AI agents to interact with platforms in ways that skip those billing toll gates (because their agents are remixing actions / data on the user side)?
Both the intended (I'm skipping a premium charge) and unintended (I used a hacked agent and/or my agent went awry) are going to become major issues for companies in the next 5 years.
And the question will be asked "Can't we just ban user AI from using our app?"
Attested passkeys are going to be an awfully tempting option to reach for as an answer. Especially for banks. (Fuck banks' technology stacks)
More context: I've been saying this a lot about this in the scan and go at sams club and how there are fanatics that act like it's a good thing and to be the only way to pay.
They could start doing it tomorrow. They just have to flip the switch.
What’s your point?
Attestation is already putting the screws onto open computing, and the frog is already on the boil.
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.
Fuck banks with a cactus for forcing us to relinquish our freedoms as a precondition of interacting with them, which is a precondition to exist in most societies.
Arguably, even passkeys with attestation would be a step forward compared to that, as banks could require an external authenticator tap on a rooted device, or signature of some sandboxed secure element that runs independently from the application OS.
It’sead so far. Again, X.com could ask you to re-enroll your passkey next time you sign in, but this time requiring attestation.
> banks could require [...a] signature of some sandboxed secure element that runs independently from the application OS
They can. Why don’t they?
How? Almost none of their users own an authenticator capable of attestation (i.e., a Yubikey or similar).
> They can. Why don’t they?
They can't, because open/neutral access secure elements do not exist yet, and nobody really wants to carry an external one.
I haven’t checked, but I suppose both Google and Apple have passkeys implementations capable of attestation? (If not, it should be fairly easy to add, and considering Google has been pushing for various “integrity” bullshit, this would be a no-brainer for them.)
> They can't, because open/neutral access secure elements do not exist yet, and nobody really wants to carry an external one.
I’m not 100% sure if this would work: https://developer.android.com/privacy-and-security/security-...
Presumably, banks trust Google, so if Android doesn’t erase attestation information from the HSM when unlocking the bootloader, they could use this process to verify that the key they’ve generated is stored there, regardless of whatever other software the user is running. (If Android does erase attestation info then eh, it’s just as bad as relying on Play Integrity APIs.)
> I’m not 100% sure if this would work: [...]
I believe it might, but like you I'm not sure if they really don't measure some secure boot properties into that keystore these days.
It's also usually implemented in TEEs and attested by the device manufacturer, which means there's a high chance of getting either insecure implementations in the mix or ending up with a heterogeneous mess of supported and non-supported manufacturers varying from bank to bank.
FIDO at least has their manufacturer directory; not sure if Google has something similar for Android (and if it does, whether non Google certified Android OEMs may apply).
There is an alternative* of which I haven't heard in a while.
* https://uattest.net
Are merchants obligated to accept swipe transactions?
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"
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 functionality that actually touches your money 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.
Of course not, you still have some control over those FIDO2 hardware keys and they don't lock you to a limited set of devices. That's what the attestation is for, to allow banning the use of sign-in with anything but a couple megacorp providers. The few small time hangers on will be expelled in time. They're useful idiots for the adoption phase.
Notice that after lots of complaining about there being no way to transfer keys in the spec they developed some planned working group that will in the end only allow transferring from Google/Microsoft/Apple and maybe a few other dumpster companies. They aren't going to give that control up.
Ah, yet another case of people being forced to use technology instead of being left alone doing things the old way where they understood all the risks.
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. 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 th...
What? 2FA is something I have, something I know. I know my password for your web app, and I have access to a separate account. It's not a recursive 2FA, "it's only 2FA if one of the factors has its own 2FA".
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).
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...
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.
And the sad truth is: Most people have no password manager at all. They are used to re-generate new passwords every time they want to log in! I'd wager that on some websites the vast majority of people are loggin in by pressing "I forgot my password".
Apple has also made it clear they have privacy concerns about attestation as well, which is also why they don't support it, but backup and syncing are clearly very important to Apple because that is very important to keeping consumers happy.
I don't get why this whole "they used to support it but removed it" is supposed to be an argument for anything.
More seriously, the fact that Apple previously implemented something and then removed that implementation gives us multiple pieces of information: they are technically capable of implementing it (not a huge surprise), at one point they thought that it was a good idea to implement it, at a later point they thought that it was not a good idea to implement it, they're willing to backtrack on implementation decisions in certain situations, etc... Depending on how you weight these different pieces of information, you can reach different conclusions about how likely reimplementation is in the future.
(Those extensions are for a Passkey manager to "solemnly swear" to an RP that a key was involved in some sort of MFA dance such as PIN unlock or biometric unlock and maybe a little bit of rough detail of what sort. Much more rough than Attestation details and not attested claims at all so a Passkey manager could lie about them, but that's enough for the sort of regulatory compliance or "due diligence" that many Banks might need from consumers to replace existing MFA logins with Passkeys. It is a relatively strong bulwark against attestation requirements for consumers.)
Do you have any argument for why they would add it back?
and the other is a laptop, capable of doing none of that
Attestation is necessary for corp use cases. Adding it as an option to WebAuthn is better than forcing more standards to be developed.
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...
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
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.
> Amazon (..) still requires TOTP when logging in with a passkey from an unrecognized device.
I noticed Amazon does that and it annoyed me greatly.
> 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.
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.
> 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.
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 are unphishable. It’s technically impossible for someone else to capture your passkey and use it themselves. It’s technically impossible for your passkey to be leaked from a website.
This is what makes Passkeys the superior solution - they bake the security into itself rather than throwing up its hands and hoping all the other weakest links do the right thing consistently.
Heh.
Several months ago, I found myself in need of a new phone. I even had the means to do an orderly transition, with the old one still in hand and mostly working.
My mobile provider was an MVNO that was also my home ISP. I had enabled "enhanced security" to prevent ev0l hackerz from swapping my SIM without authorization. It turns out that this mode is so secure that it prevented me and the support staff from a normal upgrade procedure.
There were various glitches along the way, and a conversation with certain LLMs indicated that the SIM->eSIM disparity was also causing trouble, and with the online system's rejection of authentication I decided it was expedient to walk into their nearby storefront location.
It turns out that the salespeople in the storefronts are not really empowered in any technical way, except they were quite capable of changing my password without any reason, and wasting my time, so leaving the store empty-handed after mind games from three haughty female STEM dropouts was rather infuriating.
The process eventually succeeded after giving it a little time, space, and grace, but it looks like I'm leaving "enhanced security" disabled if it's so customer-hostile.
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.
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".
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.
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.
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.
You know what MITM is, yes? There are a ton of points between you and that hash algorithm, and any single one immediately and permanently compromises you.
Meanwhile passkeys are completely invulnerable.
>Meanwhile passkeys are completely invulnerable.
Not according to the parent comment and the article.
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)
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?
> 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.
And their friends won’t care until they’re personally affected.
This only becomes real if you don't have e-mail fallback access to your account. Something which seems like a very bad idea.
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.
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.
That’s an out-of-date view. The number one attack vector these days is cookie stealing. The prevalence of 2FA even weak ones like SMS-based 2FA has made plain old phishing so much less effective.
What you may be confusing with is the number of incidents involving token theft, which is often facilitated by phishing.
People say this, but is this scenario possible: user (foolishly) clicks an unsafe link to a look-alike bad site. Bad site requests new passkey and user is tricked into supplying one. Bad site agent, with proper passkey to real site, forwards traffic. Result is MitM.
No, fuck that. Just let me use an SSH cert at that point. The existence of phishing is a comparatively minor evil.
Sharing and phishing are on two different axis. You can have shareable credentials that are phishing-resistant when used.
You can have hardware-backed SSH keys that are not cloneable. You would need the browser to prevent phishing while still using SSH agent as its underlying signature mechanism (implied by my "in a consumer package").
But the problem is: most of the time, the people that choose what security system you should use are the system administrators, not the end users. And they like passkeys because they are the easier for them to implement.
They require no server to send confirmation codes and no need to trust in unknown applications and their ambiguous key formats.
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.
[1] https://web.dev/articles/webauthn-user-verification
[2] https://www.1password.community/1password-at-home-31/user-ve...
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.
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?
* 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.
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/
It means "Just shut up and use it, someone's bonus and/or promotion packet is depending on the usage metrics.". :P
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 :)
And for the record, this is not impossible. Bitwarden does it[3] via the magic of "ignoring the part of the specification that says not to give users their data." Any open source software would do the same. This is why 1Password is no longer the "good guys" despite having rationalizations for their actions.
[1] https://support.1password.com/export/
[2] https://support.1password.com/1pux-format/
[3] https://bitwarden.com/help/export-your-data/
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
[2] https://github.com/keepassxreboot/keepassxc/issues/10406
Does (more) here include free software like keepassxc and friends which don't restrict what key owners do with their keys? Last I heard, FIDO was moving to ban them.
Though, I do find it amusing that I commented about 1password's inability to communicate their security model, and your reply links a reddit post[1] in which everyone is disagreeing over whether or not iCloud secret key syncing actually occurs.
[1] https://www.reddit.com/r/1Password/comments/10iqhdp/comment/...
Note who is excluded from this list: the End User. The protocol only allows exchange between password manager vendors who choose to interconnect.
You don't get to decide how to use your passkeys, some on else does.
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.
Lots of places where you might have specific requirements about your authenticating users. E.g. to achieve FIPS compliance, or if your user population is low-single-digits because it's critical national infrastructure.
> I want them to all have to invent their own, so that most of them will make mistakes that let the attestation be bypassed and freedom be restored.
I most definitely do not want operators of CNI to be "inventing their own" that can trivially allow compromise or weakness. "User freedom" is not the prevailing value in a lot of authentication contexts.
https://cphpost.dk/2026-10-10/news/round-up/123456-password-...
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.
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.
And our agreement doesn't stop there. No views I encounter anymore at my near ripe old age of 50 are new anymore
Social conservatism whittles value statements down to a finite subset of cause-effect
Take HN for example; run a trend analysis on the comments going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth
Religious people are not the only ones who live in rhetorical fantasy
End of day the provenance of any socialized idea is some rando I have no obligation to march in lockstep with; physically or philosophically
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.
Many would actually rather you close their account with them than them making the tiniest compromise or offering any alternative to their SOP at all. That SOP strongly assumes things like “all customers have a mobile phone plan with the big three carriers”, “all customers own property or at least have car insurance” (that’s already their authentication fallback flow!) etc.
I have also faced this issue with banks and their frustrating authentication issues. Not to mention proprietary app requirements.
> 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
I literally provided a citation.
> Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended.
A syncable credential is by necessity representable in clear text at some point. In comparison, resident WebAuthn private keys NEVER leave the secure device.
> [1] https://www.w3.org/TR/webauthn/
WebAuthn is a _superset_ of Passkeys. Here's the citation from your own linked page:
> This use case illustrates how a consumer-centric Relying Party can leverage the authenticator built-in to a user’s devices to provide phishing-resistant sign in using multi-device credentials (commonly referred to as synced passkeys). ... > A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.
That I said does not support your statement.
> A syncable credential is by necessity representable in clear text at some point.
I never said this was wrong.
> WebAuthn is a _superset_ of Passkeys
I don't see how your quote illustrates this, and I've only heard them referred to as the same thing. Would you care to elaborate? And maybe provide an example?
> multi-device credentials (commonly referred to as synced passkeys).
> A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential.
The previous name for single-device credentials was "resident keys".
So yes, providing a way to export and back up the Passkeys was _literally_ the intention of the WebAuthn authors from the beginning. The ability to export and sync passkeys was not a temporary accident, it has always been intended functionality.
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.
Do you think they did that to keep us FOSS neckbeard hackers happy?
Apple is perfectly fine with taking control of your privacy if they're the ones in control, and in this case they would have to put third parties in control instead. I'm sure they'd much rather take control themselves and build these types of checks into their "Sign in with Apple ID" buttons instead, so they can put "if you want Human Proven Secure Attested devices (invented by Apple), let your users sign in with Apple ID" on their website.