scotthelme.co.uk
Back to storiesRanked by HN
Comments
801 total · 188 loaded
I don't know enough to argue about whether passkeys are a trap or not, but I do know as a user that they appear to be a confusing mess.
When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.
What happens when I go to the same site on a different platform? What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth? What if I want to consolidate them all in one platform just for the sake of being organised? What if I lose or simply don't have the device with a certain passkey near me?
I don't have the time or patience to work out any of that, which might absolutely be a 'me' problem, but TOTPs are pretty sodding frictionless in comparison. Scan QR in my chosen manager; type number into website; done. Why are passkeys better?
I thought "Passkeys are a trap" was going to be about this usability nightmare. Some sites, once connected via passkey, make it all but impossible to connect in another way. Some support multiple passkeys. Some do not. Some support passkey or something else. Some do not.
The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"
So far, it's about 30% of sites screwing it up...
Same. I don't understand it, and there is enough conflicting information (See this article pair as an example) that I suspect it's not something where I just need to do more reading. I suspect there's something fundamentally confusing, and subjectively-interpretable about this.
My suspicion: There is a significant chance I will lose access to one or more account by doing this, so I'm not going to until the air clears. I don't trust the motivations of the services pushing it.
The defining feature of passkeys is that they're stored in your password manager, and you can't read them, so you can't be tricked into typing them into the wrong web site.
Most password managers don't even allow you to export/backup the passkeys yourself. (Bitwarden is an exception.)
Instead, password managers support a finicky app-to-app transfer protocol called "Credential Exchange Protocol" (CXP), where you install two password managers at once, and they convey your passwords + passkeys, without ever generating a file that you can read. (And Microsoft's password manager doesn't even support CXP yet. As of today, you can only do it on Android and iOS.)
Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.
If you use the same cloud-sync password manager everywhere, passkeys just work. If you don't, you'll have to use Credential Exchange Protocol to transfer them, which is a hassle.
It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
Randomly generated strong passwords for all practical purposes are just as good as passkeys and keep you as the user in control. If you really need to copy/paste between a laptop and mobile or give it to a friend/family member, you can.
What do passkeys offer users that rand strong password + password managers don't?
My thoughts exactly.
Anything that randomly makes a Windows 8-style popup offer to keep my login credentials safe makes me want to run farrrrr away.
The vibe of the original criticism, even with its technical flaws was this: are passkeys - as a standard, and a user interface - vulnerable to corporate capture? I think passkey defenders are focusing far more on the theoretical technical superiority, and ignoring how instinctively alarming the average implementation is.
We face a lot a lot of attempts to capture our data, and passkey feels like a new frontier.
For me, I know exactly where I am with my password manager & TOTP. I think the current confusing interface of passkeys will make me less secure rather than more, so I've not invested the time to think about how to use them.
Definitely not wrong here. It is a confusing mess for most people. Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience. Everyone else? not so much.
I agree and I have a good example.
At my work we are forced to use passkeys internally and it's fine with me.
At some point in the past, due to the constant nagging I set up a passkey on my GitHub account.
I needed to sign in to work's GitHub account, so unknowingly (since there's no SSO option there) I just clicked on "Sign in with a pass key". It didn't ask for my username, just gave me an option to scan QR code. And I did because work's pass key is set up on my personal phone. Then I noticed that it's trying to sign in with my personal GitHub account. It's good that I don't have anything sensitive on there but I really wouldn't want to sign in on my personal account on my work's laptop.
This, I've been an engineer for 25 years and I hate passkeys. I have a work laptop and a home laptop and I connect to some websites from both and I... it's just a mess.
So far, I've had a hard time setting up an iCloud passkey on desktop Windows. Windows Hello keeps intercepting most attempts at a passkey, and 1Password will usually step in otherwise. The UX around it continues to be baffling to me.
At least there's a dedicated migration protocol for passkeys, but I'm not super stoked about how basic Apple's password management is, and how few fields there are for each profile.
But I also feel like it's time to retire my YubiKeys ...
TOTPs are already not that great in my opinion. It's like democracy: the least bad option. It's a decent trade-off between convenience and security, so I'll stick to unless there are good reasons not to. Passkeys have managed to make that experience worse, with a very large potential gotcha in the future, while not introducing any improved security I see why I should care about.
Also consider the case where you use Google password manager and your Google account gets locked for any (or no) reason. It's unclear whether you can even still use your passkeys, much less migrate them away.
> Why are passkeys better?
Passkeys provide perfect protection from phishing attacks, since it's impossible to send a passkey to the wrong domain. That's a huge improvement over TOTP.
Re: it being confusing where they're stored, I agree. The solution is to make sure you store your passkeys in your cross-platform password manager. The experience can be confusing though. In Chrome I've found that by default when creating a new Passkey Chrome offers to store it first. But if I click cancel, I'm then given the option to store it in 1Password where I want it.
Add to my frustrations the many domains of places that don’t share a passkey.
(I kinda understand it but not fully)
Amazon.com, UK, DE, JP, all need different passkeys. Yet my password and TOTP works across them all seamlessly.
And then some pass managers will only store ONE passkey for that login/password.
Its mighty frustrating and while I have been told and see the biometrics make it more secure…
It’s a pain in the arse to now have a stack of domains each in my password manager when searching.
:( In security, you forgo SO MUCH convenience.
> but I do know as a user that they appear to be a confusing mess.
I'm a very tech savvy person, and understanding the ins and outs of passkeys has been a time investment, and that's the problem. Technical and security merits notwithstanding, they're a confusing mess. I understand how they work, but what I don't really understand, is how to recover when they don't work.
Selfishly, I end up being tech support for my extended family, and I don't have the stamina to try to explain to them how this works.
They give me OpenID vibes, and non-tech people can't understand what they are.
Heck, as an engineer even I don't get them. What ever happened to password + yubikey?
Still amazed that on HN of all places people are confused by or having problems with passkeys. I have yet to see any of the issues people are guesstimating could become problems and adopted on day one.
I have had two poor experiences, where passkeys I set up at one point stopped working and I had to generate a replacement, but this was not a problem because I have yet to come across a site that didn’t continue to offer other means of logins.
I don’t see anybody complaining about the login-via-emailed-link which seems to be the much more common trend these days and which I really dislike because it introduces an unwanted delay in login (and I have come across many sites for which this is the only means of logging in).
I've been working on passkey-adjacent systems recently (including systems integrating the physical passkeys developed by a team in the same open-space) and I don't feel like the passkey industry has answers to that, in terms of ease of use/usability. Right now I'd say between an OTP on a phone and physical passkey is that it might just be quicker to plug in the passkey and push the button (if applicable) than fishing my phone out of my jacket, unlocking it, launching the app and typing the code...
> When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.
This is the same problem we've had for 20 years with password managers, though.
The solutions are mostly the same as well (with the change to a QR + BLE based mechanism over manual transcription to go cross-device, and a protocol to support moving passwords and passkeys over to different software rather than using a plaintext password CSV export).
Many password managers also manage passkeys (and were managing TOTP before).
So in my own experience, the same tool I use for TOTP is the one I use for passkeys, suggesting it’s at least possible for passkeys to be as frictionless as TOTP.
On the rare occasion I’m logging into a device that isn’t mine, that doesn’t have my password manager on it, scanning a QR code from a device that does have my password manager on it has been enough to get me in. Without sharing any secrets with the foreign device, incidentally
So I’d wager your concerns are valid and are likely to be addressed over time, as this stuff develops rapidly. It might even be better in your scenarios already
Lately it has been a tap-tap operation to enroll a passkey. Sweetwater.com surprised me with it the other day. I was done in seconds, and now I can log in without even having to enter a code. Face ID handles it for both iCloud Keychain and Bitwarden
It almost seems like instead of passkeys in their current state we just need SSH keys but with added website verification.
> What happens when I go to the same site on a different platform?
You click the "log in with QR code" button, scan the QR code, and authenticate using your phone.
Unfortunately that only works from phone (and watch) to computer. If you don't have the passkey available, you click "forgot password" and set a new one, same as with a password.
I’m not necessarily a security expert, but my understanding is that passkeys are better in two (or more?) fundamental ways.
- it is linked to a domain, as the article states, which makes it less likely to “exposed” in phishing attempts - it is a challenge system, essentially a public private key system, so the private key never leaves your device. Kind of like tls/https. Which means that even if bearer/login token is lost, your “password”(private key) isn’t lost. - also, an obvious bonus is that you get a really long “password” which is practically impossible to guess
Sorry if any of my terminology is wrong here.
Initially I've also struggled with this, and the mental model I found most useful is that a passkey is used to log in into that account from that device.
If the website doesn't allow you to add multiple passkeys then that's bad ux and that's on them.
Passkeys only make sense if every user has a open source Fido 2 hardware based USB passkey (like yubikey but opensource).
Then the user still controls the passkey using a password and then everything else flows from that.
I think the core problem is they’re called passkeys and evangelized as a replacement for passwords, which makes people think they’re like passwords or like keys—secrets we’re responsible for not losing—whereas actually they’re like session cookies. They’re a fast path in that you’re meant to be able to create, delete, and even clear all of at will, with no penalty but that you’ll have a fussier login next time. They sure do suck as an only way in, they’re not even meant to be able to do that.
Sites should support multiple passkeys, and allow you to select between them if more than one are available.
I've seen this work on both Windows and iOS, where I have sites set up to use passkeys from multiple sources (Yubikey, Windows Hello, Apple Passwords, Microsoft Authenticator app), but I've also seen it not work, so there must be something the site has to do to make this possible.
It's not even clear what happens with Google Password Manager. It might go into your Google account or your local device. I somehow ended up with a mix of both.
This is more an indictment of the current state of password managers and the tension between them at OS-level and browser level
I also don't understand why this was the only real downside off TOTPs brought up. "What if you input it in the wrong site?". Surely the exact same thing can happen with passkeys?
Yeah, there needs to be a way to link password managers to share passkeys, and also to share passkeys between people. There are also a lot of great features that could be implemented with passkey sharing too, like revocation, time limits, or capability limits.
Bitwarden[0] can store and supply passkeys (and passwords of course) across macOS, iOS, Windows and linux seamlessly.
I don't think I have seen a case where using a passkey stops me from using my password on another device/platform that doesn't have access to the passkey.
TOTPs are infinitely more preferrable to me than passkeys or any other kind of 2FA.
> it could end up going to Google password manager, Samsung passWord manager, iCloud Keychain, or Windows Somethingorother.
Using all that is just asking for trouble. Turn all off except one.
Every time I've used a passkey with a site was in addition to the regular user password. So like a cached auth saved in the phone secure storage, protected by my PIN/fingerpring.
If it gets lost for whatever reason, I don't care, I will login again with regular username/password.
So as long as you also have a regular username/password login, phone passkeys are great time savers.
Get nordpass
TOTP is phishable. The push to get away from TOTP is driven by phishing.
I've done authentication projects for financial institutions that were actively targeted by phishing attacks, and it is difficult to mitigate TOTP phishing. Defeating TOTP is very much in the standard playbook for high-dollar scam operations.
>What happens when I go to the same site on a different platform?
Scan the QR code with your phone.
>What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth?
Most devices today ship with Bluetooth and even locked down machines support using your personal phone to authenticate.
>What if I want to consolidate them all in one platform just for the sake of being organised?
Then do that. Use whatever your phone uses.
>What if I lose or simply don't have the device with a certain passkey near me?
Then you will need to use a fallback authentication mechanism or will need to wait until you can get the device. TOTPs have the same issue.
[deleted]
[deleted]
Security matters, users who want choice have to take responsibility, users that don't can just use Apple.
"What happens when I go to the same site on a different platform?" = "If you meant device, then Chrome has a feature to allow you to use a different device such as a NFC YubiKey"
"What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth?" = "Good, Passkeys are doing their job correctly and you cannot export credentials"
"What if I want to consolidate them all in one platform just for the sake of being organised?" = "Then log in and add more passkeys to things rather than copy-pasting passwords everywhere"
"What if I lose or simply don't have the device with a certain passkey near me?" = "You should have multiple passkey's or use the various cloud versions that exist"
"...if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!"
It is plainly obvious that the worry isn't attestation per se, it's the restrictions that attestation may in the future require when they turn the dial on restrictiveness up, that was extremely clear to me from reading the first article. If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions. Most of this article makes sense, but this particular line makes me wonder how the author got it so far off the mark.
They also did nothing to quell my fears that they will in the future use passkeys to prevent people from using software they can modify themselves by saying "...the guidance for consumer sites has been to not even request attestation for years now." as if everyone always followed the guidance, and as if there aren't tens of thousands of managers that think their case is special and they really do need the extra control because they're a bank or handle copyrighted content or have PII or PCI and feel extra risk-averse today.
I don't know if they failed to do so because they can't (and this is a valid fear of the original author) or if they just are bad at reading the room at what the concern is and vastly overestimate how much people trust companies to always have their best interests at heart.
What I am getting from this, though, is "If you authenticate with a yubikey then that's attested, so they can't use attestation through passkeys to make sure your OS and browser aren't modified", and I'm not sure if that's the correct take away or even a correct statement.
> If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions.
Remote attestation is never to your advantage. To do it at all, they have to restrict you to a specific set of device manufacturers and yours may not be on the list.
Then, what does it get you? Google-approved Android phones are allowed, but any attacker can trivially get one of those so knowing it's that type of device is completely worthless. All it does is prevent you from using some other type of device.
Notice that this is different from keeping the key in a HSM, which you can do without remote attestation and without the other side having to do anything at all.
Worse, the "approved" devices often have worse security than the one you want to use, e.g. using a Yubikey as your HSM will generally be better than using a phone which has orders of magnitude more attack surface and is constantly connected to the internet, but the phone is way more likely to be on the approved list than the Yubikey.
Yeah this article is confusing for me. The one a few days ago was basically saying "this is a slippery slope", which the post today acknowledges, then goes on to say "These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none" as though it invalidates the post a few days ago.
The whole point is that once everyone is accustomed to passkeys, they ARE going to ratchet it up to "you need attestation".
This is the browser wars all over again. Google spent something like 20 years winning the browser wars, and once they felt snug and secure, slowly started eroding users' abilities to control the content they see (making features adblock relies on increasingly ineffective).
At the same time the current authentication horseshit of the internet in 2026 is awful. I routinely spend 3+ minutes trying to log into a site - first it blocks logins because of my VPN, then it requires a password reset, then it requires me to login with new password, but then it needs email verification, but then I don't get the email so I have to click resend, then I type in the verification and then it asks for blah blah blah.
I am grateful that LLMs are going to be doing 95% of my browser usage very soon.
Do not handover your identity, or verification of it (as the current case is) to anyone else, irrespective of the benefits, including the security aspect.
---
The author has strong incentives for the success of passkeys.
1. Scott Helme is founder and CEO of Report URI, and Companies House records his ownership at over 25% and up to 50%. Report URI markets a "Passkeys Protection" offering, giving him a commercial interest in services for passkey adopters.
2. His WhyNoPasskeys.com campaign pushes websites to adopt passkeys, is sponsored by Report URI, and promotes its passkey protection services. The "Passkeys Are Not a Trap" article also carries a Report URI sponsor banner.
3. Troy Hunt, Helme’s Report URI business partner and investor, joined 1Password’s advisory board in 2020; Helme has also appeared in Hunt’s 1Password-sponsored content. That establishes an indirect vendor connection.
Virtually every authority on passkeys is going to have an industry connection. Just like how most climate change authorities receive funding to do climate research, how SEC investigators typically have backgrounds in banking, open source military analysts are veterans, etc.
It's not because people are bought by the powers that be, it's the way the world works. People enter the fields they have expertise in.
Thank you!
> [Attestation] say nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.
Also, I think you can deduce the device color from [1] on Android.
So, in conclusion: https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b...
[1] https://source.android.com/docs/security/features/keystore/a...
"When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up"
Was going to say, GrapheneOS must not have the same AAGUID as whatever Google Play approved type they want to whitelist.
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
Am I missing something? "Attestation tells websites what the authenticator is but it doesn't tell the website what the authenticator is".
The entire argument in this blogpost amounts to "nobody would ever turn on passkey attestation because it would require migration of people who already setup passkeys" which is a questionable argument- you could trivially imagine allowing unattested passkeys for existing users, but require it for new users. Most websites don't yet support passkeys to begin with, so this argument doesn't hold for the majority of websites.
The "biggest providers" bit at the end is odd too because the biggest providers are apple/google- who, as far as I know, do support attestation.
Apple does not support Passkey attestation on consumer devices. They've said between user privacy concerns and user experience concerns (syncing and backup are critical requirements to non-technical users) they will not support attestation on consumer passkeys. They worked through the standards process to push compromise standards that are not attested but help with some of the "compliance issues" that might have come to require consumer passkey attestation (these are the uvi and uvm extensions which are not attested and essentially are "I solemnly swear a biometric unlock was used to access this key" for basic 2FA/MFA CYA).
So the "biggest providers" very much have some champions against attestation.
The author is really missing the forest for the trees here
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
So if I was Netflix or a bank or w/ever I'd only allow new registrations from "trusted" authenticators, which would incidentally only run on iOS and play-protected Android.
The next paragraph states that Yubikeys are a registered authenticator. Yubikeys are platform-agnostic.
"Password manager you trust..."
Not so easy.
I've worked at places where we use a password manager to manage lots of passwords for random services that we subscribe to. The engineering manager always says "you can put your own passwords in for free" and I say "no thanks, they're going to get hacked" and then six months later... they get hacked.
I use the password manager on my iPhone because it seems pretty secure and it is so miserable to type passwords in on a phone but my other solution for passwords has used cryptographic generation with the database playing only a secondary role and it is fine for passwords but does nothing for passkeys.
The idea of keeping my passwords in my work-sponsored password manager just sounds absurd. Who thinks that's a good idea? What happens when you leave the job?
What you describe is a different attack surface than the much more problematic on that password managers solve well: password re-use across websites where the blast radius is super high.
If I had to trade off the risk of a password manager being hacked versus password re-use, I'm going to strongly recommend to people generally to use a password manager. Yeah there's a lots of "if this, if that"--but that's almost a universally better risk for most people.
I think this part is where TOTP's 2FA/MFA model is "safer": you do not need to trust the TOTP manager. Even if the app sends all your TOTP secret keys to the server, they cannot hack your account because your password is stored elsewhere, and TOTP code alone is useless.
which password manager were you using that it got hacked?
KeepassXC now supports passkeys as well.
>I've worked at places where we use a password manager to manage lots of passwords for random services that we subscribe to. The engineering manager always says "you can put your own passwords in for free" and I say "no thanks, they're going to get hacked" and then six months later... they get hacked.
There is heaps of context missing from this. Did the password manager itself get hacked, or did an employee leak a password for a single site that didn't use 2FA ?? The former strongly solidifies your point, the latter undermines it, and to be clear I don't think it's a good idea to use an employer sponsored password vault either.
Aren't password managers like Bitwarden essentially zero trust? Even if they hacked the entire database, what would they do with that?
[deleted]
The trap is already here for me. When I make a passkey for my corporate microsoft account, I'm only allowed to use Microsoft Authenticator on an approved device (it's not a work provided phone. Microsoft Authenticator doesn't work with rooted phones). This is not some mythical change that will happen tomorrow. It's already here for me and has made me dedicate a device, just for using passkeys for work.
Two reasons why orgs restrict the AAGUIDs down to MS Authenticator:
1. Verification of the legitimacy of the passkey. 2. Passkeys are a support nightmare if you don't restrict what can be used, and the only way to restrict is by using attestation.
If you don't restrict down, there is nothing stopping someone from setting up a passkey in Edge or Chrome or Windows Hello (not Windows Hello for business), and depending on what device or profile they are signed into, when they go onto another device, no passkey.
If someone is a single device user and only uses their corp device to access, and the corp only cares about phishing resistant MFA from an Entra perspective, as part of the auth strength configuration, Windows Hello for Business is enabled by default.
This blog post is the perfect example of someone rationalizing away the bigger picture.
It's true that passkeys do not require hardware and OS attestation today, so all of the specific examples you cite are true. But the point remains that that passkeys can be EASILY extended to require hardware and OS attestation, and this will happen.
Banks have already done this. Before using an app was optional. Play protect was optional. It's like my uncle ted used to say, techonolgy is not optional.
When my state introduced seatbelt laws they assured the public that they would only be a secondary offense, never the primary basis for getting pulled over and issued a ticket.
Now they run "Officers are watching! Click it or ticket!" as an advertising campaign.
And I'm not arguing that seatbelt laws are bad per se, just that any time there is a pathway for more control, it will eventually be taken, even if assurances are made that it will not happen.
I think it's more that attestation can require a specific "approved" authenticator, and that authenticator is what would enforce all of the required OS/Software/Hardware requirements, even if it didn't get included in the attestation standard.
And passwords could easily be extended to requiring photo ID...
That's a good thing?
Most consumer websites won't use attestation.
Places where additional security is required (bank, employer, etc) can.
I accidentally set up a passkey for one application, a certain accounting software. Now when I login, I'm required to give both the passkey from my password manager and usually my password, too. It's a usability mess and basically makes it impossible for me to share my login with e.g. my wife when she might need to login to that account. That's the practical trap.
The real trap is when Google decides in a few years that third party passkey managers will no longer be granted an ability to use the Chrome extension APIs, and Google Sync and other pay-to-play vendors are the only supported ways to handle passkeys. uBlock was just the beginning.
I'm sticking with my passwords for now. Some providers ::cough:: Meta ::cough:: have become openly hostile to allowing anyone to login to their services, but most haven't made it too cumbersome yet.
So: currently, the cauldron is cold, therefore ignore the fire below it and hop right in.
The cauldron is already warm. I encourage people to read these issue trackers.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations)."
"This implementation is not spec compliant and has the potential to be blocked by relying parties."
Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.
Just make sure you trust the cauldron you choose.
[deleted]
Counterexample: the swisspass. It's a private service from the swisspost, and they whitelist webauthn providers. For example, you can't use bitwarden https://community.bitwarden.com/t/follow-up-on-bitwarden-pas...
So the danger is there today, not in the future, since I'm already cut out today from the service, unless I use some hack
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
Practical experience from Austria where attestation is used to limit which hardware tokens can be used for the EU digital identity: it sucks. You're limited to a very limited number of keys: https://www.id-austria.gv.at/de/hilfe/hilfe-zu-ida/authentif...
Now: will more people do this? I don't know. But I fault the standard for enabling it in the first place.
> it sucks
Exactly. From the page about the requirements for the app under 1) in your link:
> System requirements
> Android 12 or iOS 16
So one of four methods is, by default, already completely dependent on having an account with $american_megacorp.
4) is another app where it doesn’t outright say, but I’m guessing the requirements are also a mainstream OS, mobile at that as well since they seem to use biometrics.
That leaves 2) dedicated hardware and 3) dedicated hardware. Great. (see the “my house burned down” article/thought experiment as to why I’m against that.)
I actually spoke up about this at a local chamber meeting today during my 30 second elevator pitch. I decided to give a brief cybersecurity awareness month pitch about having backups for your 2FA and to be wary of passkeys because you will be locked out on device changes.
I think they are a trap. A usability nightmare. So, I acquiesce to a passkey to a site while on my iPhone and now I cannot log onto it from my work desktop in Firefox. An older person sets it up on his or her Google account, gets a new phone (iPhone to Android) or Android to iPhone doesn't matter and loses access. We know that Google won't help a regular consumer with anything.
Syncing may be a thing in theory but the friction is huge.
I still don't use passkeys because I don't know what advantage it has over my existing method of generating random passwords in my passport manager and using that. My password manager generally autofills it anyway.
I know where my password manager syncs, it's on all my devices. Passkey prompts always seem confusing, I don't know if it's going to save to my browser, or my OS, or if those are gonna sync on what devices. It's just more confusing.
What would I gain from using a passkey?
>What would I gain from using a passkey?
The number one gain I see with passkeys is that they are phishing resistant. The biggest issue I've had with TOTP keys is they aren't phishing resistant.
Forcing people to use passkeys gives the authentication layer a stronger means to ensure that people are logging into the correct domain. A password manager accomplishes this, but it's very difficult to enforce. (I've heard a number of variants of "John Smith sent me an important document and when I went to open it, the password manager didn't work so I just copied password")
I’ve seen tech-savvy people getting phished into entering their password on a fraudulent site, despite the password manager blaring alarms that the login looked fishy.
This cannot happen with passkeys at all because crypto magic.
What's the difference between using a really good password vs. public key authentication in SSH?
> What would I gain from using a passkey?
The correct question is What did others gain?
- Phishing free press fingerprint or faceID or Windows Hello for login into many important sites
- many people don't have time to type password, then otp. If most of the world did that then this would not be needed.
- And finally, YOU are not OBLIGED to use it. Let the rest of population use it.
- It is like SOME pay with phone/NFC-Watch etc. MANY still use card or cash...
You’d gain forced lock-in to client operating systems and hardware that someone else picks for you.
I got quite recently turned off from passkeys. I used it on my gitlab. Stored in my password manager and was unable to log in via my phone.
Turns out, my Android version is too old. I can only use pass keys stored in google. It doesn't support using them from another provider. Need a newer version.
The argument that TOTP could be entered in the wrong domain... Nope, my password manager wouldn't propose my TOTP on the wrong domain. Hence, that is solvable. But if I wanted, I could still do it. Sure, I can be phished. That's my risk. But I can also log into a domain who has moved, or far more likely, use the password manager to fill out the 3rd party android app for that service.
Yea, that article did not convince me a single bit, the original article convinced me a whole lot.
What I'd like to understand is why the majority of sites that allegedly supoprt passkeys do not let me store them on Yubikey hardware but instead are pushing into "cloud" passkeys. That's what is triggering my spidey sense about the whole scheme. If they are so great all around and vendor neutral why is everyone pushing me to store my keys in some "cloud" password manager? If I'm going to the trouble of setting up passkeys I want to be in control of them across all my accounts. That means my own hardware dongle. Not some cloud vendor's pinky swear that they'll take care of them and let me use them on my terms.
Passkeys are a trap and are awful. And before someone says they are "more secure", meaningfully more secure than a unique email and unique incredibly long password for each account? Because multiple password managers can set that up now in a few seconds with 1/100 the friction of a passkey.
I hope anyone who is promoting these things has to help and elderly relative do something in an account they are having trouble accessing where they had to use a passkey to set it up. Or try giving your spouse access to a health account they need to access in a hurry. Or make a physical backup that a family member can use in case something happens to you and or your computer.
Look, at best, Passkeys shift your logins from your head to OS-supplied keychain management. Whether they do attestation today or not, they big, industry-wide effort to move away from "what you know" (i.e. username/password) + "what you have" (2FA) towards "platform-authenticates-you-to-website automatically" has both security benefits and lock-in risks.
Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.
TFA's author has also explicitly precluded the "platform-authenticates-you-to-website automatically" workflow, in a separate blog post [0]:
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
[0]: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
> OS-supplied keychain management
That is your choice as the user. You can use the default credential manager that is offered out of box, or you can use your own.
Passkeys are the wet dream of the IP industry. They don't want you account secured from hackers, they want you to be unable to pass your password along to friends and family, so they use it to watch your netflix or play your licensed video games.
I use GeforceNow, and everytime I start a new session to play Battlefield 6, EA makes me enter my password and sends me an OTP via email before I can play the game (due to GeforceNow, they don't save it for future sessions). It is horrible UX, and I would want turn that off. You know what, the whole world can use my account to play BF6, I don't care. THEY care so I don't share my GeforceNow+BF6 credentials with other people. An attested passkey, bound to a fixed device cannot be passed on. Add 24h cooldown on passkey changes, and you effectively stop account sharing.
Recent and related:
Passkeys are a trap - https://news.ycombinator.com/item?id=50048312 - Oct 2026 (571 comments)
Ricky Mondello responds to "Passkeys are a trap. Do not use them." - https://news.ycombinator.com/item?id=50061290 - Oct 2026 (14 comments)
I recently had the displeasure of using Passkeys:
- trying to sign in to Okta on my personal Linux desktop computer. It has bluetooth and I had my phone right next to me, also with bluetooth turned on. But Firefox simply refuses to even show the option for "connect to your phone" or to give a QR code... it just said "tap your security key or biometric device". I had neither; my passkey is on my phone. Then it timed out and I gave up trying to log in.
- trying to sign in on my work Macbook using Google Chrome (enterprise managed one). For some reason, upon scanning the QR code, my phone was stuck on "Connecting..." and timed out. I had bluetooth turned on on both devices, they were five centimeters apart, both were connected to internet with a great gigabit connection. It turns out, I had to quit and restart Chrome and it magically started working.
- trying to sign in on my work desktop using a physical Yubikey remotely using VNC. It's not possible by design. I had to get my coworker to press my Yubikey in the office.
- trying to get Muse and OpenAI Dot to sign in using a passkey. It's not possible by design.
Generally, the user experience is really horrible with passkeys. It is also ironic that it trusts my phone (used for shitposting; easily lost or stolen) instantly, but simply refuses to trust my personal Linux desktop computer, which is fully encrypted, securely stored in my house, and contains all my life's work and everything that is dear to me.
Let us consider the average user. The one who manages to lose their iPhone and has no idea what their iCloud account login is because they were aware of having to log into it once when they created the account at phone purchase 3 years previously.
That's where the trap is.
I think the passkey standard included attestation for good reasons, but it is obviously also possibly a trap in the sense that I'm sure there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.
I have to admit I don't worry too much about the entire internet flicking attestation=true anytime though, because the resulting support nightmare would be ferociously expensive. I wouldn't be surprised that, on its own, it would be more expensive than the cases that the companies flipping the switch are trying to avoid. Which means it isn't going to happen.
The simple truth is metaphorical-Grandma can't handle the degree of responsibility put on the user that strict hardware attestation implies. Netflix et al are more likely to want metaphorical-Grandma's money more than an incremental improvement in their ability to be sure it's an attested login, and won't want metaphorical-Grandma to call Netflix every other week trying to figure out how to log in again. There is no way around the fact that strict attestation implies more user responsibility to make sure they don't lose their token, and at scale, they absolutely will. Work environments can get away with this because work environments have a scalable mechanism to re-verify identity to the extent the business cares about it personally, and reissue tokens. At scale the big companies do not have this for individuals. You can't use hardware attestation without this infrastructure for reverification, and any infrastructure for reverification a large corporation tries to create will have exploitable holes in it.
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly.
The argument of the site hinges on the fact that attestation cannot be activated for an already generated passkey. But that is a BS argument. Right now, the industry tries to get the user used to the workflow of passkeys, the tools, how to use them etc.
Once a critical mass of users uses passkey, you CAN switch on attestation overnight: You simply prompt the user that he needs to create a new passkey because the old one is no longer valid. The user knows the procedure and will simply create that new passkey to be able to login, this time with attestation enabled. Hell, we even have those "You were logged out of your account for security reasons" flow everywhere (looking at you, Google). Make it a dark pattern and require that regenerating when the user needs to login the most, and voila you bait-and-switched your critical userbase.
The fact that passkeys are not expected to be backed up and freely be exported between password managers and wallets is not helping here (you are by the standard not supposed to be able to do that, but user-friendly wallet today simply ignore that part of the standard).
I don't use passkeys but the thing that raised a red flag for me while reading the article that the OP is responding to is the "non-copyable" property. It's not possible to prohibit delegation[0], so the idea that a key can only be used on one specific device necessarily involves a form of DRM/wishful thinking.
If they are not a trap, then the standard should be amended to allow third party implementations to forge attestations.
Otherwise, it is a trap. The story of the last 25 years of the internet is user hostile ratcheting away of the open web. Passkeys are obviously another step in the process.
Ok, but passkeys have prevented me from being able to do something remotely before.
Like, the far away computer tries to check if my phone is nearby, and it's not, therefore I must not be authorizing the login.
If anyone knows how to fix this I would be happy to learn.
I feel like every time I have added a passkey to an account I've been forced into it, and I didn't fully understand the implications.
I don't find this post convincing.
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
This isn't a rebuttal to the claim that they're a hidden dial. It's just saying that it's too early to crank the dial.
>Attestation Isn't What You Think It Is
>The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.
>When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
This point is bypassed by websites only supporting specific authenticators and then those specific authenticators only supporting specific devices/OSs/browsers/etc via other attestation frameworks.
I'm a happy user of 1Password myself, but warning that they only allow export of passkeys through a specific protocol, and it has to be done on the mobile app. [0]
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
> To be very honest here, you risk having KeePassXC blocked by relying parties
This threat, because someone dared to give users control, is completely unacceptable to me.
I have to say the messaging around passkeys is bad. So many providers show modals with big friendly lock logos superimposed on a smartphone to announce the change without offering any explanation about why the change is happening, why the change is happening now, or how the technology works.
I don't know when it started, I don't know who is to blame, but we've definitely arrived at a conceptualization of "the user" that is passive, uncurious, and incapable of being talked to like an adult.
Let’s assume passkeys are the greatest thing since sliced bread.
Passkeys face the same problem as the USB-C rollout. Lots of different incompatible implementations and standards rolled under one name that are almost impossible to distinguish between. Very little education on how to use it and be prepared for it.
The difference is that the consequences of getting passkeys wrong for the user is significantly greater than getting the wrong cable, and while the latter can easily be fixed, the former may be irreversible.
Passkeys are such a flaming disaster from a UX standpoint. I can't recommend anyone use them.
I'm not an expert, but it's frustrating to read these threads about passkeys.
The common objection I see here is "But if I lose my device I'm locked out!"
A lost passkey should be treated the same as a lost password.
Sites that implement passkeys need to have an account recovery mechanism. Granted, not every site does this correctly. Don't use passkeys on sites that don't have a recovery mechanism!
Secondly, the site you're authenticating to must allow you to have multiple passkeys. You either have a cloud-synced password manager so that all of your devices get the same passkey, or you have a passkey per device that you use to access the site. Again, not every site allows multiple passkeys. Don't use passkeys on sites that don't allow you to have multiple passkeys.
For a site implements both of these properties correctly, if you lose your device, you just connect to the site with your new device, perform whatever account recovery procedure (TOTP, email verification, phone verification, ...), create a new passkey, and, ideally, disable the passkey from your lost device.
Passkeys can be tied to a root of trust, like those owned by google, microsoft, apple.
Currently they aren't tied to that root of trust.
Most of those organizations have shown that they don't want people owning their own devices or being able to run their own software, and they use developer attestations, IE a revocable programming license to accomplish that.
Tools like android's safetynet makes it so that you can't run banking apps on a phone running your own software. One that bypasses developer attestations.
Passkeys are currently an open standard, but attestation is built in such a way as that it could be only usable on n approved operating system with programmer licenses.
Big websites like amazon, or websites you need to exist in society, could gradually start requiring the usage of attested passkeys.
---
There is a clear path from passkeys to the death of general purpose computing for 99% of people. Don't be a useful idiot, don't assume these corporations have your best interest in heart. See this for what it is, a path towards killing people's ability to run unlicensed software on their own devices.
I have seen an exception to this with Microsoft Entra. I was not able to store and use the passkey in my password manager of choice, I had to save it in Microsoft Authenticator. I haven't tried again lately since that was for a previous job, and I didn't look into the underlying reason it failed, whether it was attestation of some sort or something else about how they set it up.
I'm generally pro-passkeys, but also acknowledge they are a hot mess for the average non-techy consumer. And there does seem to be room for the screws to tighten, and we definitely need to resist that.
Passkeys are FINE. The implementations suck.
The entire thing where some websites let you set them up, some force them on you, and some just surprise you.... sucks.
The fact that Passkeys don't have an easy migration path between secret storage tools is also a problem.
But if you know what you're doing they are not only perfectly safe, but REALLY safe. Much safer than any other option we have. And seriously way more convenient as well.
Based on all the passkey threads I am going to hold out for 40 to 80 years before testing passkeys to see if companies can resist the temptation of vendor lock-in shenanigans. In the mean time my focus will be on cellular age reset so I can last long enough to see how passkeys play out.
I don't want passkeys. I want to stop being bothered with setting up passkeys, especially if I already have 2FA setup, and definitely if I already have a hardware fido key on the account.
> If you want to be able to move your credentials around, pick a provider that supports that
The fact that passkeys are not required to be portable is the entire trap
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up.
Me: The person who posted this post critical of The King on Facebook was totally not me!
Police: Here's "a WebAuthn attestation" that told Facebook "the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up" and it fits Evidence A.
No thanks.
Not sure if this mentioned, but I setup a new Gmail account and it wouldn't let me add my yubikey for MFA. I could only add a passkey to my yubikey for MFA.
Last time I tried using Firefox on Linux with Keepass's passkey implementation it worked on the test page and a couple other sites but Facebook refused to add it, so I definitely believe that e.g. banks and various other important sites won't balk at restricting passkeys to Android, iOS/MacOS, and Windows. I am curious what other people's practical experience is with these kinds of sites.
I've set up a few passkeys to see what it's like and the experience is wildly different between sites.
State Farm is the only place I've actually liked it. I don't have to type ANYTHING in.
Open browser, open password manager, click the "sign in with existing passkey", browser and password manager talk, prompt me to confirm the passkey choice, and I'm in.
Most sites I've messed with insist on you entering a username first.
I find the following has the right combination of mental model and security for me:
1. A password manager that generates my passwords stored on an external USB key (which is itself encrypted). I use KeepPassXC.
2. More than one Yubikey doing U2F.
I know how to backup #1 and I have more than one of #2 to handle losing a Yubikey. #2 gives me phishing protection.
For me, randomly generated passwords(via proton pass) combined with remembering to check the URL stops phishing and is easier to share.
I was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.
I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.
And yes, passkeys absolutely ARE a trap.
[0]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
I put a reply to this article in the comment section of "Passkeys are a trap. Do not use them."
https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...
I simply was not convinced there was a tangible benefit over password + 2fa when using a password manager. And the inability to move the passkeys is not acceptable.
Similarly the failure modes of the passkeys vs password + 2FA were never clear.
I don't know man. We use the Microsoft thingy at work and every time I sso somewhere, it nags me to create a passkey, and when I say "ok fine" it wants me to also add a PIN or something, so even more to remember.
No thanks, I'll keep using the MS authenticator on my phone for 2FA instead.
Btw: sites cannot phish my passwords if only the browser remembers passwords and ... drumroll... binds them by site, just like passkeys.
A lot of (good) debate about the usability, etc when using passkeys for all/many of your "everyday" sites.
Setting that aside, I would suggest people strongly consider them for their 2-3 most critical sites. You primary email, your main bank/investment account, and any cloud infra / dns registrations you have.
IMO, for these the trade-off between usability and security is strongly in favor of passkeys. I use 4 hardware keys for these accounts (USB-A and USB-C on my keychain, USB-C in the laptop, and a USB-C backup locked away).
There is still one reason I still do not use passkeys when I can't use my TOTP with it:
I was using TOTP with passwords as additional security if my password manager were to be ever hacked. Passkeys are an enhancement over passwords, but they won't replace my 2FA with TOTP.
Some context I think is missing: TFA's author claims to use passkeys for 2FA (and so, not as a password replacement as I think is often implicitly assumed in discussion):
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
Source: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
Passkeys are still a trap even if consumer passkey implementations don't currently support attestation. They are still ridiculously anti-consumer, overrated, and definitely still a risk for the open web because the door to attestation is right there.
Why does my bank (Chase) allow iCloud but not KeePass XC? Imagine if my bank got to choose what password managers I was allowed to use to write my password into. That is literally Passkeys, with optional cryptographic enforcement that people promise won't be used for anti-consumer reasons. (People. Not Microsoft or Google or Apple, but people.)
Secure Boot and TPM were also billed somewhat similarly in different times and now Windows 11 requires it and a lot of software and games require remote attestation with secure boot.
This cover story has already been used before, we already saw where it leads. Will people be foolish enough to believe it wouldn't happen twice?
As far as I've read here before, device attestation is definitely there, it's just not being used (one of the big tech namely Apple is balking... maybe they have their own means or plans in their ecosystem).
My main reason for not using it is I'm not interested participating in a scheme where I do not own/access the private keys and being able to use them and store them the way I want to.
I'm fine with TOTP and sure, I understand it's not phishing resistant by itself.
I use ProtonPass on every device I own (religiously) and have never had an issue. But it's because I'm very careful to only deal with any credential ever via ProtonPass.
I can imagine it gets annoying very fast if you accidentally put a passkey in the wrong place, ie because Chrome proposes it's own credentials store.
ProtonPass also lets me export the private parts so I'm not stuck as with some passkey managers.
Passkeys are great but require you to understand some things about them, and you need discipline in dealing with them.
I do not understand how people have issues with passkeys. I have used them on my iPhone, my Android phone, on windows, on Linux, and on macOS without issues.
Every point in that post has been discussed at length other places, some of which is in the HN thread the author mentions. And the discussions make it clear that the points being made are not seeing the problem - not that there isn't a problem.
Passkeys have benefits - but they also have problems. Many people just don't think the benefits are worth the problems. And many people are afraid that sites will just stop accepting passwords in favor of passkeys, leaving people worse off.
Question for passkey advocates, Is there is conformance test and is it comprehensive for all of a user's use cases (multiple devices, multiple passkey service providers, multiple accounts with the same service on the same device)
It the answer is "no" and you can ship an passkey implementation without passing a comprehensive conformance test then basically passkeys will always have issues. You can not get a million devs to do anything correctly unless you have a way to force them to do it. Given Google/Apple/MS are effectively gatekeepers (I know people will hate this idea) but, you could make it a requirement to pass a conformance test before the gatekeepers will issue a passkey. Same as cert authorities.
Anything else IMO is doomed to fail. More sites than not can't be bothered to use input type="email" or type="number" when all they accept is numbers or email. What hope do we have they'll use passkeys correctly?
So we have one article that contains factually questionable info and one article is written by a biased source.
Can’t wait for episode 3! Hopefully someone knowledgable pulls it all together into a season finale
Passkeys are great for developers who are into cryptography and security, and who understand the idea and implementation behind it. For the rest of us it's something to avoid.
I don't use passkeys anywhere for fear of losing access. I just don't care enough to study how it really works. With passwords, I occasionally print out all my important passwords and store them in a safe and I know there's no way I could lose access.
Saying "attestation can't hurt you, your password manager returns `none` today so it's not a concern" is avoiding the entire point of the original article which was that that can change at any time! I'm already seeing in a corporate context, IT departments forcing hardware attestation as required everywhere. Justifiable, but also clear evidence that it's no longer in your control as the person authenticating. That's the point, passkeys are marginally more secure for you, while handing huge amounts of control to centralized platforms.
The og article talks about future concerns even though things are fine today. This article claims things are fine today.
True, but doesn’t actually refute the original.
I introduced Passkeys in my company.
Every single IT person thought it would be an extreme mess, too complicated for regular users. In my company we work on the (gas) grid so lot's of blue collar types.
We went there, gave the pilot group a Yubikey and said: This is like the company pass you already have. Without the company pass you cannot enter any buildings. Without the Passkey you cannot enter a computer or app.
If you lose it report to the same people (service desk).
The response has been EXTREMELY POSITIVE. People fucking LOVE getting rid of passwords, password requirements and taking off their gloves to enter it every time.
We are now rolling it out to everyone and next year when we stop our silly "phishing game" contract we will actually save money while reducing a massive cyber security risk for our company: (voice) phishing.
I truly believe pass keys are a way for yo to eventually lose access, or give someone or something else, access to your logins.
I think it's a bad sign when someone immediately resorts to strawmen and argument from incredulity in their counter-argument:
>If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
The original didn't argue that, nor has absolutely anyone else concerned, nor has that been what has happened in historical examples people were concerned about. Because yeah of course that's ridiculous, it's "boiling a frog" by throwing it in already boiling water, that's not how it works. If anyone has freedom-reducing longer term plans for use of passkey attestation, the emphasis is on "longer term", being malicious doesn't mean being stupid. Step 1 is obviously getting people into the passkey ecosystem and out of passwords at all, which could well take years. And importantly as much as possible into closed passkey ecosystems. This is indeed one of the initial danger signs, because the author:
>iCloud Keychain, Google Password Manager, 1Password, Bitwarden
Is mixing together things that aren't like the other. Quick author, what's the EXPORT story for each of these ecosystems? Of those, Bitwarden can export a passkey into a plain JSON if you want. Do the others support that too, or at best only "app to app" encrypted transfer, creating a closed ecosystem? Already, can I get passkeys from iCloud/Google/1Pass into KeePass? Or is this restricted """for my protection :^)"""?
Author doesn't even touch on the lock-in that's already beginning. And right now everyone can technically claim "oh no of course you're not locked in! You just have to use an official option, or you can merely visit hundreds of sites individually and register new passkeys in all of them". Is it hard to see how players like Bitwarden would be pressured on continuing to offer plain export?
Then when most of the population is using passkeys everywhere in a closed ecosystem, now what is the response if friction slowly starts getting added. OK, you can still use what you like, but only export to other approved players. OK, you can still use unattested, but it's off by default now, "advanced users" can go enable it with this checkbox in the settings. OK, manual is still an option, but now it's buried deep and behind dark patterns and requires a text command. Hi everyone, we have statistics to show that only 0.85% of our users still use unattested keys. The support burden and security risk is now too high."
Like, we've seen this movie before.
The counter-argument he makes against people's concerns about attestation is laughable, all he says is that it hasn't happened yet.
Passkeys are not designed just for security, there are other corporate interests involved. It's impossible to share logins for example. He even mentioned this concern and didn't address it.
The device/app lockdowns are already real for TOTP - Microsoft and others insist on using their snowflake authenticator instead of using the standard protocol. So it's not unlikely that they will extend that kind of lock-in to all passkeys.
As a user if you push something too hard I immediately think what the angle is. That is how i feel about passkeys.
> The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing
Sorry but this is the whole problem with passkey: you are forced to rely on a 3rd party to take care of your credientials, on their computers, with their software. This is like a text book example of a trap: someone set up something that looks harmless/invisible, you walk into it, and that someone now has some leverage over you.
I'd expect a passkey to work like SSH keys except stored in a password manager. I should be able to copy that key like a password if I really want to. It's apparently so much more complicated than that. Unless someone can tell me why exactly the other stuff like attestation is needed, rather than just saying it's not that bad, I don't trust it.
Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.
Contributions and feedback are welcome! GitHub link is at the bottom of the page.
I'm moving my HSA because the company moved to passkeys.
I use unique email addresses and passwords, stored only on my devices(Linux, Windows, Android) using open source software (KeepassXC, KeepassDX). Passkeys add new friction I don't need.
> If you want to be able to move your credentials around, pick a provider that supports that.
Example providers?
Almost every complaint I see about passkeys seems to be based on behavior and configurations I just do not see in the real world.
“Once I set up a passkey I can’t log in from another device” - have never seen this to be the case. Existing password / OTP codes have always worked as a fallback if syncing somehow breaks.
“I don’t want to trust Apple/MS/Google with my logins” - so don’t. Use bitwarden or 1Password or lastpass or whatever you want to store your passkeys.
“If I lose my phone I’m screwed” - see #1 and enable sync maybe?
Boils down to I believe a lot of folks looked at passkey implementation at a high level, saw some potential pitfalls, and never actually used them to discover those pitfalls have all been accounted for.
Go ahead and skip passkeys if you want, but stop preaching about evils that don’t exist.
[deleted]
Passkeys are a trap in that they're a fairly confusing implementation that ends up tying you to a specific device or device ecosystem.
Biometrics is my main concern around this, and in that the government can compel you to provide them for device unlock, unlike a pin or password.
Until we change our laws in the US on this front, I will continue to use passwords and hardware keys separate from my phone box.
Wouldn't web browsers themselves be the ultimate passkey managers like they already do with passwords? They'd need a way to export the passkeys to another passkey manager though.
That's what the passkey industrial complex wants you to believe.
Its a solution not made in mind multiplatform people.
domain binding requires browser participation.
you can have a TOTP variant which has the browser display a challenge string & QR code, authenticator generates a 5-6 digit response. include more entropy in the response if you want to do away with the password entirely.
passkeys are trash, I would never opt for dedicated hardware (or a cloud service) and using them with a password manager is extremely messy when you want the password manager to be properly isolated from the rest of your system.
[deleted]
Thank you for posting on this. The last post on passkeys was utterly confusing and I have been thinking about this until yesterday. I had done some research for a client and had referenced your blog. This whole FIDO2 cryptography-based passkeys system is confusing even to a technical person, let alone convincing the general audience. After bringing together all the different types of passkeys, I had categorized them into three main categories:
1> Synced Software Passkeys (e.g., Google Password Manager, Apple iCloud Keychain): Encrypted locally but synchronized across a cloud account.
2> Device-Bound Software Passkeys (e.g., Microsoft Authenticator app on a phone): Only inside the physical device's secure hardware chip.
3> Device-Bound Hardware Passkeys (e.g., YubiKey, RSA iShield Key): Permanently burned into a dedicated physical USB/NFC chip.
I advocate for "Device-Bound Hardware Passkeys," but not many websites support them. Keeping a duplicate hardware passkey is important in case the original hardware key is lost.
I figured they weren't. People smarter than me made them.
I think they've been implemented well in some cases. I think they've been implemented poorly in others.
So it goes.
I mean the desire to trap seems to be among the big corporations already.
I keep seeing major players promoting their own apps over standard TOTP, which I guess could be seen as a sort of proprietary passkey. Shopify, Google, Microsoft, and more, they all want you to download their app for MFA, instead of using a very open format.
As someone who works in IT, I just can't even imagine myself doing this. I have probably around 60 codes in my Aegis, how would it look if I had just a quarter of those in apps instead?
But the main issue I have with passkeys is the simple issue of backups. I can backup my Aegis keys, I can't backup an app, or a hw passkey. I have to get a second one, and keep signing for it or something, not sure of the details, I just know it would be a major hassle. And there is no way I'm trusting a little usb device to not break.
Right now I see no compelling reason to switch from regular OTP codes, change my mind.
I would like passkeys if they had an ssh key option (something I can store on my device and transfer).
Anything that's tied to hardware is one accident away from locking you out forever unless you set of "2 of 3" or some other "let's make life even worse when it comes to authentication" solution.
These guys are so dedicated to protecting us from ourselves that they won’t provide any mechanism to export passkeys and port them between devices because it might be used for phishing. It’s just fucking annoying and presumptuous. No im not going to fall for phishing, i need to have some escape hatch to get the data.
Attestation lock down is also ALREADY a real thing. Microsoft sites (and others) frequently require you to use their bespoke 2FA app instead of using the open TOTP protocol. They will do the same thing when it comes to deciding which devices and software are allowed to login, and everything outside the corporate slop safety bubble will be denied.
"Is not a trap" does not follow from "Is currently good".
A defining feature of traps is that they start out good.
There are a lot of good points in this article, but it fundamentally missed the point of the word trap. The most it said on that topic is:
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
I try to avoid passkeys as the UX is just not good.
But what is the solution here does anyone know how to make this good?
This author is astoundingly trusting.
> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?
Any of them? All of them?
"Starting next year, only Google Authenticator and Google Chome passkeys will be valid for gmail logins. Help us keep your account safe by limiting access so ONLY YOU can read your emails"
"Good news! Your Instagram account is getting safer from hackers and spammers. As of next month, you'll use your Meta Metaverse token for all logins to Instagram, Facebook, Theads and WhatsApp"
Google already forced OAuth2 on Thunderbird [0] and the rest of the email-client universe.
[0] https://support.mozilla.org/en-US/kb/automatic-conversion-go...
When a website forces a passkey into my password manager without even asking me (fucking Amazon), it is pretty unambiguously something that is not good for me.
QED, a trap.
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
This is grade A horseshit. The end goal is for enterprise passkey managers to not boot up at all and not unlock their encrypted stores if hardware attestation isn't available. There's no use in attesting a certain password manager vendor if the platform isn't helping to avoid impersonation.
Passkeys seem like a damn good way for me to end up losing my various account/history because it suddenly decides that it's expired or invalid or not available from that password manager anymore.
The various implementations have a huge "trust me bro" feel to them, and I don't feel like spending 3 hours on the phone to Amazon talking to an AI in order to not get my account back to bother with them. And the underhanded way they keep trying to slip them by me bothers the shit out of me. Something sketchy is going on, and it isn't in my best interests is the feeling I get every time it pops up.
I hate passkeys because they're always tied to a specific account or a device like a phone. I hate being dependent on phones/devices. That being said I know they solve a lot of problems so....
I still prefer a good password written down in a paper book, with multiple methods of 2FA. But I know there are attack vectors for that.
I absolutely love them now that I have a Mac. They're shared between my phone and my Mac automatically so I can just sign in to anything with my fingerprint.
Passwords just suck. If we're all going to use password managers anyway, what is the point? Might as well use a randomly generated passkey.
What's annoying about passkeys (and not talked about enough, including in this article) is that passkeys seem to be a boon for the targeted-advertising industrial complex.
Since passkeys are tied to verified devices, they guarantee absolute de-anonymization -- and further spread that advertising "wealth" by seamlessly linking across devices, and therefore to their respective corporate stakeholders (i.e. via bluetooth to conveniently login on a laptop via a phone-domiciled passkey).
Username + password at least requires circumstantial marketing analysis to "verify" whether a user is who marketers think they are. But with passkeys, your login confirms your Windows account ID, cell phone MAC address, home address, what have you.
This dude doesn’t get it at all, but like some kind of virtual Karen he’s actively making the web noticeably worse and more annoying for the rest of us.
I can’t get phished if I use autofill. It’s that simple.
They don't solve a problem I have. So I am not eager to adapt them
Thats what a trap would say...
"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com."
What happens if a service you use loses its domain? For example, if I run a marxist online forum, it could happen at any time that the US regime sanctions my site and seizes my domain. Would my comrades still be able to log in with their passkeys?
Nope. The point of the original argument was the path to autocracy, not the current state of things. This article focuses on the here and now. The point is the trap is in front of us, we are not in it yet. Stop talking about how nice the bait looks everyone!
What I despise about passkeys is their opacity. Maybe it's skill issue, but I can't open my Bitwarden vault and just "see" them. I guess it's by design. Still, this makes me feel not exactly in control.
If it looks like a duck...
I don’t understand why the sites I’ve already set up with TOTP are trying to force passkeys down my throat, using dark patterns to try to trick me into it, and making me click extra times just to log in!
Makes me think there is some sort of conspiracy, even if this is reasonably argued and seems true.
"The post makes what appears to be one central claim: Passkeys support something called attestation, which lets a website ask for cryptographic proof of what made the passkey."
The Substack blog post focuses on "control", specifically the control that users might sacrifice by using passkeys:
"What's important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys. "
"With passwords, you can choose where to write them down; with authenticator apps, you can decide for yourself which ones to use (they're pretty interchangeable); and with physical security keys you can hand them to your colleague if you really trust them."
https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...
According to the Substack post, passkeys, per the specification, carry the potential for requiring specific hardware or software
Whether any company is using them this way yet is not the point
"If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now."
This is addressed in the Substack post:
"This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch - perhaps not all at once, perhaps just for ten thousand users at a time so as not to cause a fuss - and start rejecting non-attested passkeys."
The point is that a website _could_ do that. It's possible and there's a pathway set up to do it via the specification
The first step is getting users, a majority of them, to switch to passkeys
The "security researcher" does not say (a) this cannot happen, he claims (b) it will not happen
The (b) response conveniently sidesteps the point
When HN readers see the term "attestation" they might think of Google's scheme for remote attestation
1781305131 | Google's new remote attestation scheme is as terrible as old scheme | https://pluralistic.net/2026/06/12/compelled-speech/ | https://news.ycombinator.com/item?id=48510372 | 0 comments
1783608717 | Google's new remote attestation scheme is every bit as terrible as its old one | https://www.eff.org/deeplinks/2026/07/googles-new-remote-att... | https://news.ycombinator.com/item?id=48846883 | 1 comment
"Attestation Isn't What You Think It Is"
"YubiKeys are the authenticators that do attestation."
Of course Yubico recommends against attestation
https://developers.yubico.com/Passkeys/Passkey_relying_party...
However whether any website is requiring attestation via passkeys yet, or recommending it, is not the point
The point is that this possibility is contemplated in the specification; using passkeys opens the door to the possibility of requiring attestation
There is nothing inherently wrong with attestation
What matters is who would be doing it, e.g., Big Tech, and how they might use it to further their goals
Alas, that's outside the control of the user
That is the point: loss of control
https://fidoalliance.org/metadata/
"MDS acts as a global registry of passkey capabilities and equips your FIDO server with the intelligence needed to make data-driven decisions about which devices are allowed to access your systems."
Some users may be concerned about websites requiring them to use particular hardware and/or software
There is nothing inherently wrong with MDS
But it could be used to exclude users with "unacceptable" computers and/or "unacceptable" software
Will it. Who knows. That's not the point
"TOTP Is a Step Backwards"
"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com. "
"This is the problem that passkeys solve."
This seems like a relatively small step; tradeoff for TOTP users seems worth it
> WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up.
How's that not just a terrible idea that leads to all of the aforementioned scenarios?
By adopting this you give the site ability to require a specific app and/or hardware for keeping your keys.
recently I've gotten back into the BBS scene, particularly those accessible via ssh. its refreshing to have auth become simple again, and to often have the option of using the same kind of pub/priv key pairs to access BBS as I have any other Unixy host online, for decades. The UX is simpler, theres more privacy and personal control.
> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
"Model of the authenticator" could say almost everything about these if the model was let's say "Google Pixel 10". TEE would refuse to sign the attestation if the bootloader was unlocked / AVB didn't verify.
YubiKey attestation is not a problem because the device doesn't work against me in such a way it would require installing custom software on it. And even if YubiKey went crazy, they're not a monopoly.
Situation with smartphones is very much different..
Passkeys are confusing, fragmented, awkward, and annoyingly implemented. They aren't a trap, but they are far less efficient and less proven than a password and app-based MFA.
"AAGUIDs are unique identifiers assigned to FIDO authenticators (including passkeys and security keys) and are used to identify authenticator models for attestation and metadata purposes."
If there is any unique id that can track you, then it's a trap. No security system should be leaking unique ids that can be used to track users.
They're better than passwords but just as annoying when I have to sign into Outlook every 5 days
lmao. they are a trap. have you even used one? they are tying you into icloud or google or microsoft ecosystem. can't sign in on places once you have passkeys. no 2fa or anything is available except waiting for some support. this is such hot garbage, it doesn't even deserve a read
Trap or not I don't want them and the UX is shit and user-hostile.
It's like with iso 8601.
- we support iso 8601
- really?! Like P1Y2M3DT4H5M6S?
- err, no, I mean 2026-12-31
At the end of the day, I just don't really want them. I already have passwords and I already have to put up with 2FA. Passkeys are just one more damn thing to understand in an ecosystem I already want to spend as little time in as possible.
I don't like them, they offer no advantages to logins with random passwords. They would only be more secure if they were forced to be stored on hardware devices like Yubikeys, which almost never happens in practice. In reality it's true that they can be dangerous because they can be set up in a way that doesn't allow storing them in software and using them on multiple devices, and such device-bound passkeys will eventually lock you out or be reset in the same way as password+login (usually just by email).
The standard and implementations are also unnecessarily complex and obtuse. IMHO passkeys are not a good technology.
A usability dumpster fire. At least it gives university professors something to make into a "how not to do usability" class.
>here’s why you should use XYZ!!
Few weeks later
>let me tell you why you should NOT use XYZ!!
Classic HN.
That being said, password and 2FA is the best combo, where you control the token of the 2FA and it’s on a separate app/platform/etc than where you have your passwords.
[deleted]
[deleted]
[deleted]
[deleted]
[deleted]
[deleted]
Thankfully someone with some sense. I saw that post title and didn't even bother to read it. It sounded like someone having argued with me a decade ago that IPv6 is a mechanism for the government to track you because you have no more privacy anymore because you don't have NAT...
100% correct takedown of the "Trap" article
Do passkeys have issues? Sure. Most of them are UX and are being worked on. As a user, I 1000% immediately register a passkey when a site or app offers it as at least on iOS and macOS, it is a superior user experience IMO and more secure. I never worry if I'm getting prompted for a Passkey, am I on the right site?
Also the remote connect functionality of modern browsers and mobile operating systems makes it trival if I need or want to sign into a personal account on my work PC where my personal passwords are not sync'd. Need to get into my personal GMail in an incognito window at work? No problem at all.
Anti-Passkey folks are just people who want to be against something to be against it
Showing the first 188 comments to keep this page fast. Continue on Hacker News.