Passkeys and Modern Authentication
Posted4 months agoActive4 months ago
lucumr.pocoo.orgTechstoryHigh profile
heatedmixed
Debate
80/100
PasskeysAuthenticationSecurity
Key topics
Passkeys
Authentication
Security
The article discusses the limitations and concerns surrounding passkeys, a modern authentication method, sparking a debate among commenters about their security, usability, and vendor lock-in.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3h
Peak period
73
3-6h
Avg / period
11.4
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 2, 2025 at 9:47 AM EDT
4 months ago
Step 01 - 02First comment
Sep 2, 2025 at 12:50 PM EDT
3h after posting
Step 02 - 03Peak activity
73 comments in 3-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 4, 2025 at 10:39 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45103065Type: storyLast synced: 11/20/2025, 7:35:46 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The name of the issue reveals the actual problem: "should never be exported in clear text". If the export was encrypted with a passphrase in a standard format, then there would be no issue. It's specifically doing it in plain text that causes consternation. Of course, in practice it doesn't make much of a difference when users are incapable of choosing secure passwords, let alone passphrases. But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.
> For many years already, people lose access to their Google account every day and can never regain it. Google is well known for terminating accounts without stating any reasons. With that comes the loss of access to your data. In this case, you also lose your credentials for third-party websites.
In practice this is frequently already true. Many sites require an email to sign up. Whenever you attempt to log in on a new device, they require you to type in a code sent to your email. Without access to your email, you cannot sign in.
I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.
If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).
I don't think they could blacklist the entire password manager. They can't prevent it from giving you a username/password...
Refusing some passkeys is, to me, similar to refusing passwords that are too short. It may make sense to only accept passkeys backed by a secure element. Companies already force their employees to use a specific MFA app, because they don't want to trust any app out there.
If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft software. Banks have their own systems, etc.
Now, if a service allows you to use a passkey instead of their own 2FA app, I'd say it's a win. I'm happier using a security key than a Microsoft authenticator. But if they give up on using their own app, they may well set conditions on the passkey you use. And that condition may be "it has to be backed by a trusted secure element".
You won't be able to use a passkey that's deemed unsecure just like right now, you already are not able to just use a weak password with some services.
Again, I'm not saying that being forced to depend on TooBigTech is not a problem: it very much is. But nothing says that services have to do it with passkeys: they could (and should) also accept secure passkeys that don't come from TooBigTech. But they still have a say in what they find secure or not, and that part is okay.
The discussion about what happens in big companies is completely unrelated to this discussion. In that case the company is the user. They can do/enforce whatever they want and nobody is having any freedoms infringed.
It's not, in that they have plenty of technological solutions to address their security concerns. Passkeys don't make it easier.
> I don’t think we should create standards that make it easier for companies to erode user freedoms
We want some degree of security in many services (typically our bank). And we generally can't have it all. Security is a compromise.
To spell out the quote I allude to above, "give me liberty, or give me death!" We could eliminate a lot of bad things in the world if we were willing to give up freedoms.
Well intentioned but naive security researchers are constructing the very tools that will be used to by governments and corporations to restrict the rights and freedoms of users and I don't think we should stand for it.
Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.
There is no such guarantee if credential-stealing malware can export your private key material in plaintext!
No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today.
You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on google and add it! This is effectively how you’re meant to move passkeys around. Create a new and register that with the same services as the old one.
The real hassle right now is remembering all the services you attached your current passkey to so you can register a new passkey with them and it’d be nice if there was something similar to ninite installer for passkey registration. But still it's not a huge blocker. You can absolutely use multiple passkeys and login with any one of them.
Passkeys mean that most people can just FaceID or their fingerprint everywhere and they are happy. They are happy to be locked in if it just works.
For those of us who don't want to be locked in, we still have the possibility to not be locked in because we understand how it works.
I don't think we can do better: try to explain to normies how they should enjoy using a CLI and see how they react.
Yeah, because people are stupid.
Heading towards a future where you need to use government-approved devices which are tied to your real identity to access the internet is a recipe for disaster.
That's unrelated to passkeys. When you use your credit card to pay online, it's tied to your real identity. Many countries offered to do a lot of official stuff online (like taxes) long before passkeys.
The reality is that many passkey implementations right now come with attestation and are closed off. That's simply not possible with passwords.
Passwords, as a concept, just can't be abused in that way. Because they're just strings of text. Passkeys, however, CAN be - and we're already seeing that happen.
It could reverse course, but then it would need to reverse course and stay reversed. Forever. Even though there's lots of money and control being left on the table.
That's a big problem.
Well, not with only the password, but with the mandatory 2FA app that comes with it, it's definitely possible. Source: my company does that.
And you can most definitely request the real ID before you let someone create an account, password or passkey.
I don't see a difference.
Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?
Nope, it's exactly that: tricking people into believing that they are exporting their passkey securely where actually they are sharing it with the attacker.
> I don't see how phishing would be applicable to passkey exports.
Phishing is applicable to everything humans can do: if you can ask a human to do it, you can phish a human to do it.
For anyone who is confused:
https://www.cloudflare.com/learning/access-management/phishi...
You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want.
But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Perhaps I'm reading things in a worse light than you but I believe the potential for abuse is so high and the value of user freedom is so high that these comments shouldn't be taken lightly. I say this a user and huge fan of Yubikeys (I use them precisely because of the feature of not being able to export the private key for security). But I think users have the right to build/use software that works how they see fit.
They have, I don't think anyone denies that. But the other side has the right to refuse working with them if they find them insecure.
I don't think it is limited to passkeys... I have always been forced to use the authentication chosen by the IT at work, it's not like I can come and say "You know what? Instead of your SSO coupled with your second factor app, I would like to use my own password manager with email and password".
I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own.
Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.
The standard provides the means for the relying party to choose what password managers it will accept, so you may very well have to use the Google password manager.
They already do select the security they want. And it does make sense when security matters to them!
Say you managed to put into the law that "it's illegal to discriminate passkeys, either you accept all implementations or none of them". What would happen then? Those services would just not use passkeys, because they already have a solution they control today (with their own authenticator apps).
What the standard provides is a way to have certified/audited passkeys. So that instead of using the authenticator app of my bank to log into my bank and the Microsoft authenticator to log into my company SSO, maybe (just maybe) I will someday be able to use a passkey. Not any passkey, that's very clear, and it actually does make sense in terms of security. But maybe instead of using Apple or Google, you will be able to use a security key like Yubikey.
And the fight should be to give a fair chance to those third-party systems for getting certified. Not to refuse the passkey technology because instead of being forced to use the Microsoft passkey, we really like it better when we are forced to use the Microsoft authenticator app.
I'd rather have the possibility of being "tricked" than get locked into another walled garden. Maybe I'm wrong for feeling that way, but there are literally dozens of us.
On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech.
[1]: https://blog.codinghorror.com/the-magpie-developer/
What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?
Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.
I think passkeys resolve that, even though it's more of a human issue than a technical issue :-).
If github can't make it right, nobody can.
Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?
git remote add ... git+ssh://user@github.com/... comes to mind as a counterexample, although I admit there aren't many of these examples and GitHub also supports authenticated https:// with git. GitHub don't publish SSHFP DNS records either it seems, but the feature is there in the client.
I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?
Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).
I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.
No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party.
> let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service)
This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.
And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.
Sure, we are being abused by TooBigTech and surveillance capitalism. It doesn't mean that all security is bad. Security is a compromise. Yet many people go "this added security comes from a governement/TooBigTech so it proves that it is a lie". Which is wrong: it doesn't prove it. Sometimes there are good things coming from governments/TooBigTech.
The world is more nuanced than people seem to realise.
Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.
How do I sign in from multiple computers?
With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment.
This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).
You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).
Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.
Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.
It also applies to SSH keys. I never said that passkeys couldn't do everything SSH keys can do. My criticism is that they are more complicated to do the same thing.
This is exactly what not valuing simplicity looks like.
WebAuthn just adds a few things like the relying party and a counter (that nobody seems to use). And the relying party helps preventing phishing, which SSH doesn't do really well in practice (most people don't use SSH certificates and don't check the server fingerprints).
So it's just not true that passkeys are more complicated to do the same thing.
This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.
Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.
The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us.
The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.
Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?
Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)
WebAuthn helps prevent just that.
Of course they can: that's precisely the meaning of MITM.
They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server.
WebAuthn prevents that MitM part.
If we are simply talking about ssh users ignoring fingerprint warnings then I don't see how this is an ssh weakness. A fingerprint change warning is basically saying "you're connecting to a phishing site" as I see it.
I didn't say it was an SSH weakness. I said that it was not "solved" problem in that most users I have seen completely ignore those warnings from SSH. So the problem persists even though SSH does it right.
With WebAuthn, the problem disappears. So that's an improvement for the users.
Don't get me wrong: I love SSH. I just think it's wrong to say that WebAuthn doesn't bring any kind of security to users.
So yeah, you can have whichever you want, nothing prevents it!
I have 50 terabytes of data breaches on a NAS with lots of plain text or badly encrypted passwords, and that's just a small subset of what's out there.
Ditto
My kids use prepaid numbers, once I changed one and forgot to tell Apple, when I realized that I needed the old number later, it took me a month at least to get it back.
I really like passwords, the security risks are well known and really easy to handle compared to 2FA and all that crap, specially when 99% of your accounts are not sensitive enough to merit anything fancy.
(customer identity and access management is a component of my work at a fintech)
The reality is that TOTP has been obsolete for awhile now. It's a net negative for ordinary users that is kept front-of-mind for everyone because nerds like us are attached to it.
Even for phishing, doesn't it count for something that TOTP prevents asynchronous phishing (collect credentials on a fake site, try them in batches later)?
IME as a customer/user, financial institutions are some of the worst culprits for doing appalling things in the name of security (theatre) anyway.
yeah i will not be taking advice from the majority of people in Fintech on this topic. thank you.
For example https://shamir.securitytools.io/
Everything else is a security theatre and an UX pain.
1. It forces the use of keys with a reasonable amount of entropy, and the use of a password manager to access them. 2. They will not make it easy to use a key with the wrong site (also true of a good password manager). 3. Uses public/private keypair so key itself is never sent over the wire (even encrypted).
The real question is whether these properties are worth all the costs (enumerated in this article).
ALL of account permissions, relations to other accounts, and authentication should be an exposed api that rolls up into a single dashboard. I should be able to go into one single control panel to control exactly what accounts are allowed to do what on what devices for all services for all family members. That includes lockouts, auth resets, push of auth to a device I dont have physical access to (kid is on a trip, I need to sign him into something).
I could go on and on and on about all the different ways this paradigm is so broken, it actually breaks our imagination of what it should look like in a functioning world. We are so used to doing it completely wrong, its hard to see right.
Anyways, 1Password completely solves this problem for me with me & my wife.
It also doesn’t begin to cover notifications. For some reason most services seem to think only one parent is in charge and both don’t need equal access and equal notice.
Try 1Password Family and store your passkeys in there?
This argument was made in the context of moving out of the Apple ecosystem (are there other ecosystems one would want to leave where the only option is paying for something like 1password?). I don’t really buy it because I can’t work out a situation where one is switching from some expensive ecosystem but unable to pay a low fee for 1password. But maybe I’m missing an example.
Bitwardens free tier is also generous enough that a lot of people won't have to pay
Author here. Insert your favorite ecosystem in that people currently have. If you have a windows 11 computer you end up with Windows Hello passkeys for free. If you have a Chromebook then it will be something else.
Apple devices show up in low income households somewhat regularly where I live because of subsidized iPads for education.
You lose your job.
Just now, at least in Europe, there is a huge push to force users to authenticate themselves with their actual identity, even for ordinary Internet services. This is happening simultaneously in many countries (including non-EU countries like Switzerland). It almost has to be a coordinated effort....driven by whom? Passkeys play into this.
Call me paranoid...
Yes, it's awful during the transition period while the tech matures, but there is a path towards a great future.
The last time I tried to use passkeys, the desktop was easy. What about mobile? There wasn't a local third-party password manager that could work with passkeys on Android.
sounds like you found yourself a market opportunity…
https://bitwarden.com/blog/bitwarden-passkeys-mobile/
https://vaultwarden.discourse.group/t/passkeys-in-bitwarden-...
44 more comments available on Hacker News