I expect the same is happening with passkeys. Many are just trying to make their customers more secure, but I don't for a second think that companies who are constantly looking for more ways to lock in users don't see any potential for that here.
By "secure" understand "from the user escaping big corpos", and one that the most used open source project was already rejected from because open source is just not compatible with it.
Whatever the “most used open source project” you’re referring to is, all they need to do* is issue a 100%-reproducible binary that they then sign with their usual signing key. Once they submit that build for an independent audit and have it verified as not secretly backdoored, then the other password managers can trust it when secure boot attestation chains all the way down to their signature. This maintains the key benefits of open source — inspectability, pull requests, and so on — while adhering the specifications of PassKeys that protect them against expert users.
The password manager, whoever they are, would have likely figured this opportunity out on their own and then rejected it. I can’t be sure, though. Perhaps they didn’t realize it was possible! Or perhaps they opted out of participating.
Whatever the case, that’s not any fault of open source. It’s the fault of signatures: no binary is going to be permitted to exchange PassKeys unless it's signed by a trusted party adhering to the PassKeys ‘HSM only’ agreements. Whether their signed binary is reproducible open source or pure binary closed source is irrelevant in an attested environment.
No user-modifiable solution will ever be acceptable. But that’s not an open source problem. I have extensive Ghidra experience and source code is certainly no significant obstacle to extracting passwords. Source code is irrelevant to the problem; signatures, attestation, and secure boot are the key.
It would be perfectly reasonable for a consortium of no-cost, no-profit, open source password managers to jointly accept each other’s PassKeys for transfer under attested conditions — and if they did so genuinely without it being backdoored, then that would be a convincing argument both as an alternative to the ‘corporate’ passkeys system, as well as a convincing argument for W3C and the corporations to accept interop with their signed binaries under attested conditions rather than see the PassKeys ecosystem to splinter. Certainly the W3C would pressure for their acceptance if their intentions were genuine :)
* Assuming that they want to pass at all, as opposed to taking some sort of hard stance against the core precept of PassKeys: i.e. “the user can’t be trusted, even if they’re an expert”. But, again, that’s nothing to do with open source.
Feels like there are some more thematic underpinnings as well like security at the cost of user freedom or at the cost of tinker-ability.
But. The silent looming threat I predict that few others seem to see, is that Valve will guaranteed enable TPM w/ secure boot attestation in a future Steam Deck hardware update after everyone bails from Windows 10 to Valve Linux, giving it true standing as a console and overcoming today’s multiplayer lockouts by AAA games (unattested Linux is a godsend for software cheaters compared to Windows), while having captured that market on the pretense of tinkerability with full intentions to betray that unstated assumption in favor of regaining AAA multiplayer support in games.
Similarly, that’s why so many AMD gaming processors already ship with Microsoft’s secure attestation Proton chip from the Xbox inside: if Microsoft wants to end kernel-rootkit anticheat, they have to offer another solution, or else competitive PC multiplayer online gaming dies when Microsoft slams the door on Crowdstrike. Secure attestation, coming to a Steam instance near you. (And not to single out Valve — Epic will go there too!)
Console-grade attestation is coming to computers everywhere, because just as with password theft, it uniformly prevents virtually all software-based cheating. It won’t stop hardware-based cheating, but doi:10.1109/SERE-C.2012.43 and Apple mFI already demonstrated that peripheral attestation can arrive at any time — there just isn’t any point in doing so for Win/Lin gaming when most users aren’t using attestation. Yet.
Sometimes I feel like Chicken Little trying to convey the threat to repurposeability here, but, like, this is what’s coming, because after the Crowdstrike worldwide outage, kernel rootkits are on the way out - and the side effects are going to be devastating. This is why I don’t just say, as one comment below does, “fuck you” to attestation: that approach has no effect and it’s coming for everyone unless more people than I start confronting it and understanding it.
So we don't use passkeys? OK, fine, in 2025 that's possible. But for how long? How many sites and services are going to start requiring this? Will they care if a few HN readers are blocked out?
The only way to prevent this nightmare is to convince tech illiterate people to also avoid passkeys, but good luck! This kind of convenience is too attractive and the downsides are too hard to communicate to them.
The standards body did a really excellent job solving the problem. Is outrage deserved? Is this better or worse than our freedom? I would watch that debate if someone posted a video of a panel discussing the contradictions! Because I’m not sure where I stand, either.
But I just cannot stand the obliviousness that everyone has over attestation. It’s not a done deal yet. I just haven’t seen tech suggest anything to do about it, and that continues to worry.
In the absolute best-case scenario, the user gets to choose which third party to trust and could even switch to a different one later - but the general dependence on a third party will always stay.
It's DRM for passwords.
Is killing off password theft worth the tradeoff of restricting the legitimate user’s rights, or is this a step too far towards authoritarian overreach, no matter how significant the harm done to humanity by password theft?
Societal-level ethics are incredibly interesting to me, so I’m glad that the broader tech community is catching on to the ethical dilemma and engaging with it. PassKeys are a ‘good first bug’ for evaluating large-scale ethical tradeoffs of technology: the benefit and tradeoff are clear and obvious to everyone once explained, unlike so many other ethical dilemmas in tech.
1: Replace passwords with classic public key auth. The benefits of that are uncontroversial and the tech has been successfully in use for decades (e.g. with SSH keys).
2: Lock away the private key in a HSM and introduce some complicated set of rules and protocols to ensure that no one, not even the user, ever gets to see it.
Seems to me, most of the security benefit comes from the first part (no confidential data is sent, no password guessing, etc) while most of the problems come with the second part.
So why not unbundle the two parts and add public-key crypto to the web that allows the user to store their private key themselves?
Again, this is how it's done for SSH for decades, and so far I haven't heard of any large-scale SSH phishing campaigns, even though there would be enough attractive targets.
The one benefit that's advertised everywhere is "bullet proof phishing protection", because each key is tied to a domain and the HSM can refuse to sign anything with the key that's not from this domain.
But you could implement an 80% version of that with accessible private keys as well: Just add the domain (or a hash of the domain's TLS cert) to the key's metadata and have the browser refuse to use the key if it doesn't match. A user could spend some effort and change the metadata, but the bar is MUCH higher than just typing in your password somewhere.
A phisher could also try and make the user run some tool that automatically switches the metadata (or just sends off the key directly). But at that point, the phisher would be forced to trip some classic red flags like getting the user to download a tool. Also, if the user did install the tool, they'd have a huge problem even with HSM keys: The tool couldn't access the keys directly, but it could impersonate the user and use the keys.
So I don't see why we have to go from plain passwords to "opaque walled garden" with no step in between.
The only way to close the social engineering attack vector is to design a system where users cannot upload a key even if they’re conned, which is why passkeys implement both #1 (to stop transmitting the secret) and #2 (to deny all human beings the footgun). And the only way that we know of in tech today, to technically deny humans their footgun when they have physical access to the device, is to build the OS around an HSM with secure boot and attestation so that the user can’t naively or expertly bypass the footgun safety by installing software.
So, today, we have to choose as an industry between denying users the right to extract private keys from the HSM, and allowing attackers to exploit users to extract private keys from the HSM. There is no known middle ground. Should we prioritize liberty over safety, or safety over liberty? That is the core contention of Passkeys, and ultimately of attestation.
Yeah, I know that Passkeys takes that view. I'm questioning that view.
We have precedent in form of SSH, PGP, S/MIME, TLS client certificates (or actually even just regular TLS certificates) and all kinds of crypto wallets. Have there been any actual studies how many private keys in those systems were sucessfully exfiltrated through phishing?
Because this justification sounds an awful lot like an excuse for lock-in and control creep - like the mandatory auto-updates that were also promoted in the name of security and now are frequently used to push through anti-features that go against the interests of the users.
https://news.ycombinator.com/item?id=44791058 is the most recent post (yesterday) I can find, suggesting 200,000 impacted in a single malware instance. On average there are hundreds to thousands a year, but I don’t know their theft volume.
How many need to be impacted before the interests of user security should be given precedence over the interests of user liberties? Is there a hard line amount or is it fuzzy? Is it in the thousands, millions, or billions?
You’re definitely asking an excellent line of questioning, in my view. IS all of this Passkeys crap worth it? Will it make a significant and meaningful difference? That has to be a set of questions that the W3C has presumably studied, and if you’re lacking for sources to begin research, I would check their drafts and discussions first.
I’m not the right person to look for studies pro/con to your viewpoint, though: this topic, as with most social morality topics, is essentially academic to me — which is one of the great joys of being asocial, as I love that academia, but also means that I can’t construct a working theory of mind to support someone else’s viewpoint, pro or con, without it being uncanny valley broken and weird. I see a lot of people upset about this topic and it’s transparent enough for me to lay it out plainly, and I care about people en masse and I want to see these discussions progress beyond “this sucks” reflexive disregard and towards - for examples - “is there any better way technically”, “what led to the sacrifice of liberty deemed acceptable”, and “is it appropriate to be so cynical about human beings when they’re their own biggest enemy”.
If your government can order your password manager to lock you out of your passwords with no more trouble than locking you out of your bank account, then that lowers the cost of tyranny down to what the Chinese Communist Party enjoys.
https://www.newsweek.com/banks-have-begun-freezing-accounts-...
A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
Also, having a single cert shared across multiple hardware tokens is a security risk, as it becomes impossible to distinguish the tokens or revoke only a single one of them.
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
you:
> A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
reply:
> Having a single certificate makes it trivial to implement cross-website tracking.
you:
> Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
well, indeed! perhaps designing a system to support multiple certificates with synchronisation, so that we're not forcing ever user to be trackable by every single website, would be a good idea.
some sort of keys to enable one's passage in to a website?
this is a cancer on this website, and certainly one I'm also suffering from, despite being quite aware of it - real life things are usually pretty complicated and just because I know enough to make a random guess at a solution, it doesn't mean people who have put way thought in to the problem have done a bad job or missed by brilliant insight.
For example, a service that you register an account on can issue a certificate to you; you could use it directly or you could use that certificate to issue another certificate to yourself, with a different key, and storing the private key of the original certificate on a separate computer that is not connected to the internet, making it less likely to compromise (if the certificate actually used is compromised, it could be revoked and you can issue a new one to yourself).
If the service defines an extension for the authorization granted by the certificate, then you could issue a certificate to yourself that has an extension to restrict the authorization, therefore allowing partial delegation of authorization. (Some operation would be authorized only if all of the certificates in the chain authorize that operation.)
The partial delegation of authorization can also be used to issue certificates to others, perhaps for a limited time (by setting the expiry date). For example, if one service can access another service to do some operation on your behalf, you can issue a certificate to the first service (this is one case where a client issues a certificate to a server), with the limited authorization that is required, and then that first service will use that certificate to authenticate with the second service, to do the operation.
A service that wants someone to be able to use their account from another service to log in to their own one can also do so (although usually this should not be required, since someone might not want the other service).
The private keys can optionally be passworded for additional security, and the server doesn't know nor care about this. (Passworded private keys is probably not useful for server certificates, but it is useful for client certificates.)
The use of mutual TLS authentication has other security benefit as well.
Until you do that it's corpo malware and I will live in a tent in the woods before I use it.
It is nice to just have a one click login for things.
Passkeys replace passwords and also render basic TOTP/HOTP-based 2FA unnecessary. However, they do not replace modern, push-based 2FA, which may still be needed in higher-assurance or enterprise scenarios.
Regardless personally I am waiting for full FIDO Alliance interoperability/sync, so I'm not locked into a single password manager. I've already had to migrate password managers after my choice was taken over by Private Equity.
Push notification based 2FA can never obtain that level of security.
https://www.darkreading.com/cyberattacks-data-breaches/uber-...
do you remember which one? hope it wasn't bitwarden :/
You can require Google IDP to still have 2FA with passkeys.
And 1Password will still let me export my crazy-long password and TOTP code to a plain text file if I want to switch to a different password manager (of course, I’ll have to do some planning beforehand to make sure that the export destination doesn’t get picked up by my backup software).
It might actually be net positive across the Internet, especially for the most vulnerable people. But at the same time, it could also easily become yet another source of sweet behavioral data ripe for abuse by big tech and government
I do not agree. I think it (and some related things) is a grand plot, and mostly seems to benefit Google and Cloudflare, for lock in. (They might also want to actually improve security in some ways, but that is minor, and there are better ways to do that anyways.)
I think X.509 would be better (and does not require a web browser to use, nor does it hide stuff from the user, and also does not require a new different incompatible specification to be made for everything). (Unfortunately, the way X.509 is often used (for server authentication) is also in bad ways, but it can be used better, both for server side and client side.)
There's plenty enough of shitty things Google actually does and did, no point in inventing easily disprovable ones.
Mind you, the fact Google could change APIs further to actually prevent adblocking is on its own a sufficient reason to foster competing browsers, so let's perhaps focus on that.
The fact they can do this without pushback is pretty clear sign this will only continue.
Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
Bitwarden even now supports passkeys on mobile browsers and apps. As a happy user for over 5 years it's been great being able to configure something less theatrical than push/codes without needing to plug in my YubiKey every time.
Passwords have their faults, but they do have a zero-technology backup option that your heirs can execute. (A printed dump of the password vault in a locked fire safe.)
I prepared the fire-safe paper, but I can imagine my family getting stuck at the institutions who demand 2FA and probably won't have access to my phone or email at the time.
This is a GOOD thing.
I have had an HSM for years. I thought "Passkey" was that stupid Windows thing where they want you to use a 4-digit or 5-digit PIN.
If a "passkey" means an HSM, I'm already onboard. If it means PINs and TPMs, I'm not onboard
Everything else about them, such as HSM, is industry overlay motivated by their own motivations and aspirations.
I can answer that.
Disk encryption is a risk factor. If my desktop fails and it is unencrypted, I can take the disk and put it into another desktop and it will work.
With encryption, I am less sure. I do encrypt my desktop with LUKS but I vaguely remember that setting up an encrypted disk in Linux is tricky, there is a loop device involved for the decryption layer, some LVM config. And the kernel has to support all that, which it probably does, but again. It's been a long time since I tried.
So while my desktop and my laptops have encrypted partitions, the server running my archives and backup is not, because I value simplicity and access more than the extra security.
People using Windows or Apple hardware should be even more afraid of disk encryption, as they understand it way less than me.
If you are using non-discoverable keys, the type where you input your username to login and then it asks for the passkey, there is no limit because they are calculated from a single master key and seeded with the url.
If you are using discoverable keys when you don't even input a username to login, the latest Yubikey has a limit of 100 but other vendors hold more.
Physical hardware keys work across most devices and browsers as long as you have the key with you.
Please note that there are 2 types of passkeys:
- resident keys: Actually stored on the hardware key
- non-resident keys: Keys that are recalculated on the fly based on a secret seed value, the domain that the service is for and the username. The advantage is that these don't take up any storage space
Resident keys have the advantage that they remember the username. But there is only a limited number of keys (about 100 on new YubiKeys but there are still a lot of older hardware tokens being used) that you can store on a hardware token. Non-resident keys have the advantage that you can "store" an infinite number of them on your hardware token.
See https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
This is not really correct. Non-resident keys are not passkeys.
The two types of passkeys are synced and device-bound. Synced passkeys are typically stored in software-based credential managers, while device-bound passkeys are typically stored in hardware security keys or hardware-based credential managers.
you're deluding yourself. yubikey will be only for Enterprise when deployment hits the larger public.
- in the typical mundane case, its prescriptive about a PIN with the well-known bad outcomes on that
- in the limit case, a bad guy who has already demonstrated a willingness to steal your credential now needs to threaten harm to get what he wants
There's a reason bank tellers can't open the vault and a reason everyone knows that.
Physical custody (U2F) is intuitive, maps extremely well onto existing infrastructure (everyone has keys for their car and home), scalable in security (safes are common, well understood, and can be made arbitrarily secure).
So by the time you're at FIDO2 / demand a pin? Already user hostile. Strictly lockout increasing, strictly violence incentivizing.
Moving right along, Webauthn could mandate trivial portability as a QR code, TOTP style seed, a zillion ways. Nope: vendor lock in battle (FireFox overlays its password thing on the same pixrls that the Proton or BitWarden one does that I turned on!).
None of this is about security, none of it is about safety, none of it is about welfare.
It's about money.
Guess what their password was: solarwinds123
So yes, I am in favor of passkeys everywhere because humans are bad at realizing their operational risks when they start creating an account and haven't even used it yet.
Without password managers, humans tend to reuse their passwords, which makes one breach a breach of all accounts. Humans are also bad at remembering passwords, so time based recreation of passwords will always lead to the month or week or iteration as a suffix.
And that's the actual problem that can be prevented with passkeys (or MFA that is not based on sending SMS or emails which are unencrypted as a transport channel).
But I agree with the author's implied sentiment: export/import should work between password managers and be required by law, because currently Microsoft's authenticator workflow is pretty useless if you can reset the passkeys via email ownership anyways.
This is a niche case that is already handled more or less properly by the BigTech.
Are you suggesting that people will change their passwords after they created an account and realize that it needs a better level of security?
Because I would argue that Collection #1-#6 proved the exact opposite: Humans reuse passwords, and invent sequences or suffixes when forced to change it.
So I get to be punished because of incompetent military contractors?
Opsec is about reducing risk from one potential breach to not affect other parts of your life.
Assuming you never made a mistake in your online life is a foolish assumption.
Which, you have to admit, is the most secure option. All security measures represent a tradeoff, and sometimes that tradeoff is not worth it.
That to me is the problem with Passkeys. They are not an unambiguous win.
Or Bing/Microsoft?
Or the new trendy thing where you have to put in your email before password field is shown (because it may require 2-auth).
All of these platforms made authentication less secure because a) due to so many differen domains handling authentication I no longer can know if I am at the one I should trust b) since there's often no password shown password mamagers no longer automatically fill in username fields
These idiots broke the system that worked so well before with a password manager and it no longer works. For very little reason.
Don't say it's users who are to blame, it is as much the big companies who are making it worse because they are dysfunctional.
What happened to actually educating users instead?
(And not undermining your own security advices by making legitimate sites look like phishing sites)
I’m against passkeys for all the usual reasons, but people have been trying to educate end users for decades now. The lessons don’t always stick, and new users are being made every year.
I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting. If a sophisticated attacker wanted to target an organiztion with passwords/push auth, it'd be trivial to get some subset of members to copy-paste passwords from managers and accept prompts. I think far more likely than lock-in is that FIDO members genuinely want to make their customers more secure, something that passkeys very much do accomplish for the average user.
That being said, I'm not rushing to enable passkeys on every site. If you already use a good password that enforces origin binding (the key strength of WebAuthn) and you extend that security perimeter through good OpSec (i.e., being careful when copy-pasting passwords), you're not getting much benefit.