Passkeys are just passwords that require a password manager(danfabulich.medium.com)
danfabulich.medium.com
Passkeys are just passwords that require a password manager
https://danfabulich.medium.com/passkeys-are-just-passwords-that-require-a-password-manager-ebb7f2fdcadf
225 comments
Big tech initiatives can, and often do, have more than one motivation. I'm sure many folks working on AMP only cared about serving web pages faster to users, just like I'm sure many other folks involved loved the lockin potential.
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.
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.
They're working on a secure exchange format between managers: https://fidoalliance.org/specifications-credential-exchange-...
It has been on the HN frontpage before.
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.
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.
Open source isn’t compatible if it isn’t running in a secure attestation environment, because 1) people will modify it to be more convenient and less secure; and then 2) they’ll transfer keys from their HSM into plaintext. I’ve watched extremely competent developers spend months figuring out how to bypass second-device factors in order to have a more convenient workflow with their auth key stored in cleartext in a dot file. I know without a shadow of a doubt that if unattested open source was allowed to interop with passkeys, they’d abuse that just as readily in order to be free of the restrictions that HSM-mandatory storage carries.
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? Unless reproducible builds and audited modifications. 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 splinter. Certainly the W3C would pressure for their acceptance if their intentions were genuine :)
A useful analogy is blackhat badges. Whether the badge is open source or not has no impact on that blackhat requires an attestation from someone other than you that you’re welcome at the conference. Having source code is like having a badge schematic in this analogy: there are lots of good outcomes from it, but gatecrashing without agreeing to their rules isn’t welcome.
* 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.
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? Unless reproducible builds and audited modifications. 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 splinter. Certainly the W3C would pressure for their acceptance if their intentions were genuine :)
A useful analogy is blackhat badges. Whether the badge is open source or not has no impact on that blackhat requires an attestation from someone other than you that you’re welcome at the conference. Having source code is like having a badge schematic in this analogy: there are lots of good outcomes from it, but gatecrashing without agreeing to their rules isn’t welcome.
* 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.
But this is exactly the problem: Passkeys as a core principle require that there is a third party that manages access between the user and a service. That's the entire idea.
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.
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.
Yes, precisely! That’s what I’m hoping to raise awareness of here. It’s DRM for passwords, that effectively blocks malicious attackers from exporting credentials, basically without exception.
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.
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.
I think passkeys are packaging up two different "innovations" into one system:
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.
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.
> ensure that no one, not even the user, ever gets to see it
One small correction: this should read, “especially not the user”, reflecting the research and evidence collected over decades showing that authorized users are an apex threat to their own security.
The problem solved by passkeys is not addressed by #1, or else it would just be S/MIME-like certificates in password managers as we had for twenty years already in browsers only with better UI. If the user has the ability to access to private key underlying the public certificate, then an attacker can convince the user to extract and upload the private key and password, and an expert user can remove the password altogether. Passkeys takes the view that social engineering and malware attacks cannot be prevented so long as the secret is retrievable from the HSM into an unmanaged file, clipboard, etc.
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.
One small correction: this should read, “especially not the user”, reflecting the research and evidence collected over decades showing that authorized users are an apex threat to their own security.
The problem solved by passkeys is not addressed by #1, or else it would just be S/MIME-like certificates in password managers as we had for twenty years already in browsers only with better UI. If the user has the ability to access to private key underlying the public certificate, then an attacker can convince the user to extract and upload the private key and password, and an expert user can remove the password altogether. Passkeys takes the view that social engineering and malware attacks cannot be prevented so long as the secret is retrievable from the HSM into an unmanaged file, clipboard, etc.
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.
> Passkeys takes the view that social engineering and malware attacks cannot be prevented so long as the secret is retrievable from the HSM into an unmanaged file, clipboard, etc.
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.
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.
Crypto wallet malware is widespread, SSH and AWS key theft is a regular and successful target of Python module malware, etc.
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”.
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”.
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.
The amount of cryptocurrency stolen due to exposed keys on the filesystem is likely staggering
This is one of the aspects of passkeys that make them unacceptable for me to use. They're just a nonstarter. If they're forced on us, it's just yet another thing that is making the web smaller and smaller for me.
> 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?
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-...
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-...
I'm sorry, this is an absolute monstrous attitude towards user freedom in the name of security. There is no way I'm using passkeys if this is what they're about.
No need to apologize to me. Raising awareness is my mission goal for discussing attestation at HN. Not to promote it — there’s one specific use case for it that I think is firmly appropriate and PassKeys isn’t that! — but to ensure that people are informed about what’s going on so that it can be evaluated face-on.
Believe this is the goal of pushing towards secure compute like Google’s SafetyNet or Windows 11 with tpm.
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.
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.
The Windows 11 TPM push parallels macOS and the T2 chip, except years later. Once Win11 is in the majority, I imagine web attestation will start to go live in web banking, because they hate paying for fraud investigations.
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.
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.
The walls really are closing in though. There's basically no way we can avoid this scenario.
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.
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.
It’s still possible to avoid this scenario. For example, imagine how conservative tech-hostile politicians would react if they understood how passkeys gives big tech authority over their money. Or when police discover that they no longer have the ability to extract passwords with a wrench. Or how parents won’t be able to access some accounts because the kid stored a passkey outside of iCloud and now it’s parent-proof. Massive outrage is due to tech over this, considering historical trends, but either no one realizes the benefits of them — or everyone doesn’t care because it’s worth not having their password stolen.
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.
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.
The key is to lie. Most tech illiterate people get their approximate knowledge from more tech literate people, who get their knowledge from the technical folk. Tech illiterate people don't know how passkeys work, if we start saying that it's just a way for scammy companies to steal your passwords, that'll eventually become truth.
To any third party that claims to need to come between me and any of my auth keys, I have only one thing to say: "Fuck off".
This looks entirely optional and at the discretion of the provider, and not part of the spec itself. Please correct it that's wrong.
Passkeys seem like a kludge.
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.
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.
I also think client certificates is a better solution. However, it does not have to be single per-user.
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.
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.
Having a single certificate makes it trivial to implement cross-website tracking. FIDO2 (and by extension Passkeys) prevent this by having a unique key for every (origin, username) combination.
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.
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.
The vast majority of users treat their set of passkeys as a unit anyway, so there’s no scenario when a single token would need to be revoked in isolation. A breach of one passkey can only occur from breaching the password manager itself, in which case all passkeys are exposed, so there’s no security benefit to having per site passkeys.
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
perhaps this a good moment for you to engage in some reflection and consider that perhaps some people have put more thought in to "how do we replace passwords" than you did in making a single hacker news comment?
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.
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.
Get rid of the CA-style provider certification and let me implement the API directly, myself, with just Python or a C compiler.
Until you do that it's corpo malware and I will live in a tent in the woods before I use it.
Until you do that it's corpo malware and I will live in a tent in the woods before I use it.
This is exactly what exists today. There is no "CA-style provider certification" in the synced passkey ecosystem. It is completely open.
Remember when the internet of military contractors got exfiltrated because the CI/CD pipeline of a firewall vendor got breached?
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.
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.
> Remember when the internet of military contractors got exfiltrated because the CI/CD pipeline of a firewall vendor got breached? Guess what their password was: solarwinds123
So I get to be punished because of incompetent military contractors?
So I get to be punished because of incompetent military contractors?
You seem to not even read my argument.
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.
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.
I read it. My point isn't that this is bad. My point is that it's a solution that imposes a large enough burden on at least some people that it's not automatically an unambiguous win. For me, it represents a large enough burden that if it were forced on me, I'd just stop using the web sites doing so.
Which, you have to admit, is the most secure option. All security measures represent a tradeoff, and sometimes that tradeoff is not worth it.
Which, you have to admit, is the most secure option. All security measures represent a tradeoff, and sometimes that tradeoff is not worth it.
> My point is that it's a solution that imposes a large enough burden on at least some people that it's not automatically an unambiguous win.
That to me is the problem with Passkeys. They are not an unambiguous win.
That to me is the problem with Passkeys. They are not an unambiguous win.
> when they start creating an account and haven't even used it yet.
This is a niche case that is already handled more or less properly by the BigTech.
This is a niche case that is already handled more or less properly by the BigTech.
Why is this a niche use case?
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.
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.
It's probably not a grand plot at this moment. But yeah, it seems like I'm going to eventually be forced to involve a third party in my login processes, and it will come with not much benefit to me, and will come with a bunch of risks and downsides.
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
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
Have you tried to log in AWS account using corporate identity? How many redirects it takes?
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.
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.
> I have a hard time believing that WebAuthn is some grand plot by Big Tech to lock people into their walled gardens.
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.)
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.)
>I think people on HN overestimate the security literacy of the average computer user in a personal/corporate setting.
Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
Here's your escape hatch: https://bitwarden.com/help/export-your-data/
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.
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.
Sadly, right now, bitwarden is the only provider that will dump your passkeys into a JSON. No one else offers it, and there is no functionality from any provider to import and adopt the JSON that bitwarden exports.
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.)
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'm surprised that especially financial service providers don't have a very clear "in the event of death/emergency" flow. I know you can sometimes label an account payable-on-death/joint-ownership/trust/other weird tax-dodge shaped things, but that doesn't solve the technical problem of "how do I log in and initiate my claim when Grandpa kicks the bucket."
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.
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.
The whole point is that you aren't supposed to be able to login and continue business as usual. You need to call or write to the financial institution and provide proper legal documentation (death certificate) before you can assume control of the account.
This is a GOOD thing.
This is a GOOD thing.
That's fine for financial accounts, but people have hundreds of accounts, and you don't know which ones are the ones that matter beforehand. Is it your family member's AO3 stories that you want? Or maybe the login to the web forum that was their primary social outlet in old age? This assumes that those non-financial sites even have a process to let you in.
KeepassXC also has the option to export passkeys
Happy user of Bitwarden and use their passkey support when I can. But generally I've been underwhelmed with the passkey UX, likely no fault of Bitwarden or similar. With extensions installed, Android configured to use Bitwarden for passkeys, etc, it feels like a 10% chance or so Bitwarden will be checked for a passkey and otherwise it's randomly either the browser or phone. Without being able to reliably read a passkey, I always need to set up password + OTP as a backup. While there's some benefit to passkeys when available, having to set up multiple auths anyways just makes it feel like too much of a hassle...
And how long until the attestation feature is used to ban their implementation? The threats have already been made to keepass.
The main benefit you get is that you don't have to type in 2FA codes anymore since 2FA was built to solve credential stuffing / password reuse which isn't a problem on Passkeys.
It is nice to just have a one click login for things.
It is nice to just have a one click login for things.
First-generation 2FA solved basic credential compromise issues using code-based methods (e.g. TOTP/HOTP). Modern 2FA (e.g. push notifications) adds authentication integrity, phishing resistance, and user validation through real-time, context-aware approvals.
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.
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 notifications are vulnerable to MFA fatigue/"bombing" attacks, that are used in the real world, cf. this breach on Uber:
https://www.darkreading.com/cyberattacks-data-breaches/uber-...
https://www.darkreading.com/cyberattacks-data-breaches/uber-...
The main benefit of FIDO2 is origin verification: it is literally impossible to authenticate on a phishing website, as on a phishing website the browser won't send valid origin data to your token.
Push notification based 2FA can never obtain that level of security.
Push notification based 2FA can never obtain that level of security.
What happens if the origin changes? Suppose I have a passkey for Twitter.com, and now the site is named X.com? Is there some way to migrate the passkey?
Pushed based is also insecure, why would you want that if you have a passkey unlocked by a pin+touch? That's context aware, requires something you have and something you know.
Push notifications don't protect against realtime phishing attacks
> I've already had to migrate password managers after my choice was taken over by Private Equity.
do you remember which one? hope it wasn't bitwarden :/
do you remember which one? hope it wasn't bitwarden :/
I have one-click login with 2FA codes stored in 1Password.
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).
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).
Yes but also depends on how the end system is configured.
You can require Google IDP to still have 2FA with passkeys.
You can require Google IDP to still have 2FA with passkeys.
Google banned ad blockers from Chrome by claiming it secured non-technical users.
No they didn't. Ublock Origin Lite works fine in Chrome. Certainly they took strong adblocking capabilities away, but I can still browse the web on Chrome fairly ad free.
So… they took away Ublock Origin (and other “strong adblocking”) for the reason I said…?
You said they banned adblockers. This is provably wrong, as there are still many working adblockers in the Chrome Store. They certainly reigned in what Adblockers are capable of doing and made it much easier for websites to bypass them etc in the future, but ban them they did not.
No they didn't. Adguard works fine. Ublock has been dragging its feet, but that's on Ublock. Yes, I know, there were all those clickbait headlines. I saw them too, and people got super upset when you pointed out the clickbait and that adblockers would in fact still work. Well here we are, and lo, adblockers still work.
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.
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 “strong capabilities” means tracking/fingerprinting prevention. So yeah you might not see ads but the ads see you.
The fact they can do this without pushback is pretty clear sign this will only continue.
The fact they can do this without pushback is pretty clear sign this will only continue.
I'm fine with ad people knowing that. I think people can overact a bit. I mean do you feel the need to wear a mask and disguise when going to shops and cafes in case the shops and cafes see where you go?
I'm not fine with that data collection at all. It's not even just about ad people, it's about the larger accumulation and sharing of data.
it is a big tech plot to tie people verification to a device they control. there's no way you can sugar coat it.
Get a Yubikey.
[deleted]
It's called Fido Hardware tokens
Can I store a passkey on a YubiKey?
Yes. That's one of the primary use cases of a YubiKey (or other FIDO 2 hardware keys).
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...
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...
> Please note that there are 2 types of passkeys
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.
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.
That's all it does.
This "passkey" business has been so confusing.
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
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
HSM can store a passkey that you optionally can use a touch + pin/password to unlock.
Passkey is a catchy but vague name for ssh keys used for website auth.
Everything else about them, such as HSM, is industry overlay motivated by their own motivations and aspirations.
Everything else about them, such as HSM, is industry overlay motivated by their own motivations and aspirations.
A TPM is an HSM.
Nope, TPM secures your computer from you. HSM offloads sensitive tasks to a trusted device while letting you fiddle with the computer any way you want.
An HSM stores private keys securely. A TPM does this to implement secure boot and disk encryption. And for some reason a lot of people are afraid of disk encryption.
> And for some reason a lot of people are afraid of disk encryption.
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.
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.
Not one that works across devices/browsers.
A Yubikey is a "device".
Not one that can store an arbitrary number of passkeys that work across different browsers/computers.
I don't think you understand how FIDO2 works.
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.
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.
[deleted]
Passkey is literally a software emulation of a yubikey.
Passkey is a security key used as password. Yubikey implements security key in hardware, it can store passkeys. Password managers implement security key in software, they can store passkeys.
fido already have ways to say a site only accepts google and apple keys.
you're deluding yourself. yubikey will be only for Enterprise when deployment hits the larger public.
you're deluding yourself. yubikey will be only for Enterprise when deployment hits the larger public.
how do you figure? It is a completely open ecosystem. You can choose whichever credential manager you want.
What? I'm quite sure I can login with passkeys stored i 1Password from my Linux laptop.
for now. the passkey provider is part of the attestation choices.
> The design of passkeys is pretty solidly based around the idea that users are the weakest link the system and need to be protected from themselves.
What happened to actually educating users instead?
(And not undermining your own security advices by making legitimate sites look like phishing sites)
What happened to actually educating users instead?
(And not undermining your own security advices by making legitimate sites look like phishing sites)
> What happened to actually educating users instead?
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’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.
how can I "use a good password that enforces origin binding"? Is this accomplished on the user side or by the provider?
Yes - title should be "Passkeys are just passwords your granddad and the websites he visits can't stuff up". Passkeys will do for authentication what TLS did for transport.
Until he messes something up and loses all his passkeys.
FIDO2 is already a mess: it takes an excellent model (U2F / physical custody) and makes it worse in ways ranging from annoying to dangerous:
- 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.
- 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.
> If a sophisticated attacker wanted to target an organiztion with passwords/push auth,
... it can target the Remote Code Executor: the web browser. /s
... it can target the Remote Code Executor: the web browser. /s
To present a passkey, you have to use a password manager. This provides some anti-phishing protection.
The lock-in issue is more complex:
- I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less.
- There is an exchange protocol in the works for data migration: https://fidoalliance.org/specifications-credential-exchange-...
> - I write a VS Code extension for plain text passkey storage for simplicity. Do you allow servers to reject this? What should they reject? To oversimplify, the corporate folks argue for more control, the open source folks for less.
Irrelevant, servers can never control what clients do. The only way to control passkeys is using attestation CAs, which is insanely restrictive (not (just) for the users, but for the implementors), e.g., you only allow Yubikeys, Yubico provisions a TPM guarded endorsement key on the valid keys, and you send an additional challenge that must be signed by the endorsement key and validated by Yubico servers. This is completely, absolutely impractical outside of a closed org that supplies all of its own keys.
Irrelevant, servers can never control what clients do. The only way to control passkeys is using attestation CAs, which is insanely restrictive (not (just) for the users, but for the implementors), e.g., you only allow Yubikeys, Yubico provisions a TPM guarded endorsement key on the valid keys, and you send an additional challenge that must be signed by the endorsement key and validated by Yubico servers. This is completely, absolutely impractical outside of a closed org that supplies all of its own keys.
How is it "completely, absolutely impractical outside of a closed org" when I thought Google attests every passkey created on Android?
https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestati...
Apple would too, if it were not for iCloud Keychain syncing:
https://news.ycombinator.com/item?id=43988852
My understanding is that servers can block passkeys from insecure Android devices today if they wanted to.
https://www.w3.org/TR/webauthn-3/#sctn-android-key-attestati...
Apple would too, if it were not for iCloud Keychain syncing:
https://news.ycombinator.com/item?id=43988852
My understanding is that servers can block passkeys from insecure Android devices today if they wanted to.
> How is it "completely, absolutely impractical outside of a closed org" when I thought Google attests every passkey created on Android?
Passkeys in Google Password Manager are not attested. There is no known synced passkey credential manager that creates attested passkeys.
Passkeys in Google Password Manager are not attested. There is no known synced passkey credential manager that creates attested passkeys.
> This completely breaks phishing.
It pushes phishing back to the passkey recovery/reset interface, which is out of scope for passkeys. Saying passkeys provide "some anti-phishing protection" is accurate.
It pushes phishing back to the passkey recovery/reset interface, which is out of scope for passkeys. Saying passkeys provide "some anti-phishing protection" is accurate.
Passkeys are the easiest way to lose access to your account.
It’s no big deal. Just contact Google’s helpful customer service. I’m sure you’ll get a response.
If you have paid for google one, as I have, the help desk is real people and they are nice and responsive.
I appreciate the corner case catch-22 "you need to be logged on to prove your status" but please, don't perpetuate the meme there is no google help desk.
If you want google help desk, pay Google for support.
I appreciate the corner case catch-22 "you need to be logged on to prove your status" but please, don't perpetuate the meme there is no google help desk.
If you want google help desk, pay Google for support.
Ah, excellent. Every website I visit, at Google's behest, has added a Google support contract as an unwritten requirement for doing business with them.
I'm glad that's fully resolved and indicates that the new world order is no worse than the old, and it definitely proves that Google doesn't have ulterior motives in this initiative.
I'm glad that's fully resolved and indicates that the new world order is no worse than the old, and it definitely proves that Google doesn't have ulterior motives in this initiative.
If you use a google passkey, who do you think is your support channel when that passkey doesn't work or you lose contact with it?
I'm struggling to see what the issue is.
I'm struggling to see what the issue is.
There are two huge problems with that.
(1) Google "strongly encourages"/tricks you to create a passkey even when you don't know what that is or want one and doesn't explain the downsides like having to suddenly pay for support.
(2) The status quo is that I can create any password I dang well please for any website, but the new world order is that Google gets to snoop on my affairs and intervene on the website's behalf, and since nobody will implement anything more than the bare minimum I'm going to be beholden to Google for normal day-to-day activities where I wasn't before. Maybe I could buy an iPhone or three and be beholden to Apple and/or Google. Either way, it's not a good world.
Yes, it's perfectly reasonable absent any other facts that if Google owns my passkey then they're the people I should pay for support. What's happening instead though is:
- They're lobbying websites, apps, and developers, trying to push passkeys as more secure and the future of the web.
- All the "getting started" guides only have enough details to actually implement Google and maybe one or two other big actors as providers.
- When people have the audacity to sign in with their usernames and passwords, Google interrupts their flow to tell them about how great passkeys are and how it's critical they make one. They don't mention a thing about how irreversible the process is or how it has zero benefit to the user. The UI is slow and janky, so the accept button is likely to accidentally appear over other things the user planned to click. 100k software engineers somehow can't figure out how to debounce on redraw, so that misclick will permanently infect that person's account.
And so on. I don't want to use Google for passkeys. At all. The near future doesn't, however, look like one which is amenable to me owning my own signing credentials. I won't have a choice in the matter. My choices are to pay Google (and/or some other megacorp with a direct, by order of the courts nondisclosed, line to DOGE and friends) or GTFO.
In the early 1900s this had names like "protection money." More recently we've seen terms like "regulatory capture." Whatever the exact nomenclature, it's terrible. Google is force-feeding a bad solution into the ecosystem and using their clout to ensure that they own a big, steaming piece of the bullshit pie we're cooking.
That's the issue. If I buy a support contract from you and complain that GGM is the worst acronym in the world then that's one thing. If you beat my colleagues and I with a wrench till I fork over my hard-earned dollars and loudly proclaim your sainthood whenever I've healed enough from the attack to speak my mind then I don't think I'm the problem, and those saintly/googley claims will hopefully fall on deaf ears.
The world isn't as black and white as just looking at who has control of the passkey.
(1) Google "strongly encourages"/tricks you to create a passkey even when you don't know what that is or want one and doesn't explain the downsides like having to suddenly pay for support.
(2) The status quo is that I can create any password I dang well please for any website, but the new world order is that Google gets to snoop on my affairs and intervene on the website's behalf, and since nobody will implement anything more than the bare minimum I'm going to be beholden to Google for normal day-to-day activities where I wasn't before. Maybe I could buy an iPhone or three and be beholden to Apple and/or Google. Either way, it's not a good world.
Yes, it's perfectly reasonable absent any other facts that if Google owns my passkey then they're the people I should pay for support. What's happening instead though is:
- They're lobbying websites, apps, and developers, trying to push passkeys as more secure and the future of the web.
- All the "getting started" guides only have enough details to actually implement Google and maybe one or two other big actors as providers.
- When people have the audacity to sign in with their usernames and passwords, Google interrupts their flow to tell them about how great passkeys are and how it's critical they make one. They don't mention a thing about how irreversible the process is or how it has zero benefit to the user. The UI is slow and janky, so the accept button is likely to accidentally appear over other things the user planned to click. 100k software engineers somehow can't figure out how to debounce on redraw, so that misclick will permanently infect that person's account.
And so on. I don't want to use Google for passkeys. At all. The near future doesn't, however, look like one which is amenable to me owning my own signing credentials. I won't have a choice in the matter. My choices are to pay Google (and/or some other megacorp with a direct, by order of the courts nondisclosed, line to DOGE and friends) or GTFO.
In the early 1900s this had names like "protection money." More recently we've seen terms like "regulatory capture." Whatever the exact nomenclature, it's terrible. Google is force-feeding a bad solution into the ecosystem and using their clout to ensure that they own a big, steaming piece of the bullshit pie we're cooking.
That's the issue. If I buy a support contract from you and complain that GGM is the worst acronym in the world then that's one thing. If you beat my colleagues and I with a wrench till I fork over my hard-earned dollars and loudly proclaim your sainthood whenever I've healed enough from the attack to speak my mind then I don't think I'm the problem, and those saintly/googley claims will hopefully fall on deaf ears.
The world isn't as black and white as just looking at who has control of the passkey.
And you expect every one of Google's billion users to understand this distinction, and to be fully aware that services constantly marketed as Free actually need to be paid for?
No, thats also a mis-statement. Google gives away free, and google sells higher tiers. Google one is a higher tier. This is no different to any other provider of a service with a free tier. It's not marketed as "free" -It's marketed as the level above free.
Things above free have to be paid for, they aren't marketed as free.
A more reasonable, less argumentative response might be: "did you want them to offer helpdesk to free users" -which in fact, I did, until somebody pointed out the ARPU of a customer, and the cost of helpdesk (this is actually an anachronism, that was pointed out to me when I worked in a dial up ISP) -Whatever profit you extract from a low tier customer (of which free is the lowest tier) is very quickly eroded when you have to pay the staff who operate the helpdesk, and a customer calls in wanting helpdesk support.
Things above free have to be paid for, they aren't marketed as free.
A more reasonable, less argumentative response might be: "did you want them to offer helpdesk to free users" -which in fact, I did, until somebody pointed out the ARPU of a customer, and the cost of helpdesk (this is actually an anachronism, that was pointed out to me when I worked in a dial up ISP) -Whatever profit you extract from a low tier customer (of which free is the lowest tier) is very quickly eroded when you have to pay the staff who operate the helpdesk, and a customer calls in wanting helpdesk support.
What is “Google One” and does paying for it act like an insurance policy to get you human support when shit hits the proverbial fan?
Google one is the paid tier of google for ordinary people, predicated on buying more storage. If you pay google to get more than the 15GB you are on google one and you've become a customer.
There are other forms of customer, GCP tenants, Google G-Suite, Google Workspace. If you pay google for these services, you get helpdesk directed at those services.
Google one includes your base google account. You can ask them about things unrelated to just having more storage, if it's within the compass of that level you paid for.
Google one has helped me when minor amounts of shit, a few clods short of "I lost my passkey" hit the proverbial fan.
There are other forms of customer, GCP tenants, Google G-Suite, Google Workspace. If you pay google for these services, you get helpdesk directed at those services.
Google one includes your base google account. You can ask them about things unrelated to just having more storage, if it's within the compass of that level you paid for.
Google one has helped me when minor amounts of shit, a few clods short of "I lost my passkey" hit the proverbial fan.
This got me to check Bitwardens account export, which does not include any private keys making the backup "incomplete" in terms of importing it into a separate platform.
I guess this is by design, the user can't self "own", but they also cant self own the data. It does look a bit like lock-in though.
I was recently looking at Pocket-ID as a SSO for my home lab, which only supports passkeys by design. In that context I can probably hack the gibson and get into my accounts if something went wrong, but it does make me uneasy about a future where most sites only accept a passkey.
I guess this is by design, the user can't self "own", but they also cant self own the data. It does look a bit like lock-in though.
I was recently looking at Pocket-ID as a SSO for my home lab, which only supports passkeys by design. In that context I can probably hack the gibson and get into my accounts if something went wrong, but it does make me uneasy about a future where most sites only accept a passkey.
Bitwarden says that "Passkeys are included in .json exports from Bitwarden." I'm not sure if it's true but it should be there by now.
Actually I may just misinterpret the JSON. It only includes `keyType=public-key` and `keyValue=...`, I was expecting there to be `keyType=public-key` and `keyType=private-key`, but perhaps keyType is impliying the authentication method and the keyValue is my private key?
They certainly are included, but whether they're included in a way that you can use them elsewhere, vs re-importing them into the same bitwarden account (something their vault has options to do if you encrypt the export), I'm not sure. I should spin up the vaultwarden clone and see if it correctly imports it.
They certainly are included, but whether they're included in a way that you can use them elsewhere, vs re-importing them into the same bitwarden account (something their vault has options to do if you encrypt the export), I'm not sure. I should spin up the vaultwarden clone and see if it correctly imports it.
{
"passwordHistory": null,
"revisionDate": "2025-08-04T03:02:03.600Z",
"creationDate": "2025-08-04T03:02:03.140Z",
"deletedDate": null,
"id": "<UUID>",
"organizationId": null,
"folderId": null,
"type": 1,
"reprompt": 0,
"name": "abcdef",
"notes": null,
"favorite": false,
"login": {
"uris": [
{
"match": null,
"uri": "https://<URL>"
}
],
"fido2Credentials": [
{
"credentialId": "<UUID>",
"keyType": "public-key",
"keyAlgorithm": "ECDSA",
"keyCurve": "P-256",
"keyValue": "<238 chars>",
"rpId": "<URL>",
"userHandle": "<SOME BLOB>",
"userName": "abcdef",
"counter": "0",
"rpName": "abcdef",
"userDisplayName": "abcdef",
"discoverable": "true",
"creationDate": "2025-08-04T03:04:34.418Z"
}
],
"username": "abcdef",
"password": null,
"totp": null
},
"collectionIds": null
}Seems you can only import to the same account, some hand gesturing at FIDO Credential Exchange Format & Credential Exchange Protocol which aren't yet ratified.
https://community.bitwarden.com/t/passkey-portability/59177
https://community.bitwarden.com/t/passkey-export-file/77448/...
https://community.bitwarden.com/t/passkey-portability/59177
https://community.bitwarden.com/t/passkey-export-file/77448/...
I just migrated to a new Bitwarden server using their JSON export/import and it included my passkeys.
I don’t get the sentiment of the article.
The whole point about passkeys is to replicate the exact UX of passwords (registration, reset…) but offer protection against phishing, by using public key crypto.
If you want a different UX, use a hardware security key. But these failed to reach consumer adoption.
And of course the FIDO2 standard didn’t specify (yet) a way to move passkeys around, so each implementation chose their own way to do vendor lock in. But this will be fixed in a few iterations.
The whole point about passkeys is to replicate the exact UX of passwords (registration, reset…) but offer protection against phishing, by using public key crypto.
If you want a different UX, use a hardware security key. But these failed to reach consumer adoption.
And of course the FIDO2 standard didn’t specify (yet) a way to move passkeys around, so each implementation chose their own way to do vendor lock in. But this will be fixed in a few iterations.
Author here. My sentiment is mixed. I like the anti-phishing protection of passkeys. I don't like getting locked in to one password manager.
I think passkeys are worth it for ordinary sites/apps that support resetting your password with a simple email, because if you lose your passkey, you can just reset your passkey with a simple email.
The main point of the article is to demystify passkeys, especially passkey resets. Lots of people (especially on HN, even here on this thread) are in the habit of saying that if you lose your passkey, you're going to get permanently locked out of your account.
That's no more true (and no less true) of passkeys than passwords. If you lose your password, you'll have to reset your password. If you lose your passkey, you'll have to reset your passkey, via the exact same process as resetting your password, however easy/hard that may be.
Logging into Google with a passkey feels more perilous to me, especially if Google is your password manager. Losing your Google password is bad, but you can see your Google password. You can write it down and keep it somewhere secure in your house.
If you're using a passkey to login to Google, you've really gotta go to https://myaccount.google.com/security and set up backup codes, and then keep those in a secure vault in your home.
(But, if you can trust yourself to keep a secure backup code, and not give it away to a phisher, then you're not getting much benefit from passkeys, are you?)
I think passkeys are worth it for ordinary sites/apps that support resetting your password with a simple email, because if you lose your passkey, you can just reset your passkey with a simple email.
The main point of the article is to demystify passkeys, especially passkey resets. Lots of people (especially on HN, even here on this thread) are in the habit of saying that if you lose your passkey, you're going to get permanently locked out of your account.
That's no more true (and no less true) of passkeys than passwords. If you lose your password, you'll have to reset your password. If you lose your passkey, you'll have to reset your passkey, via the exact same process as resetting your password, however easy/hard that may be.
Logging into Google with a passkey feels more perilous to me, especially if Google is your password manager. Losing your Google password is bad, but you can see your Google password. You can write it down and keep it somewhere secure in your house.
If you're using a passkey to login to Google, you've really gotta go to https://myaccount.google.com/security and set up backup codes, and then keep those in a secure vault in your home.
(But, if you can trust yourself to keep a secure backup code, and not give it away to a phisher, then you're not getting much benefit from passkeys, are you?)
> Author here. My sentiment is mixed. I like the anti-phishing protection of passkeys. I don't like getting locked in to one password manager
Most sites that support passkeys let you make more than one passkey. For all sites I've made passkeys for except one I've simply made two passkeys, one using 1Password and one using Apple's Password.
The one site I have not done this with is Premera. They only let you have one passkey as far as I can tell.
Most sites that support passkeys let you make more than one passkey. For all sites I've made passkeys for except one I've simply made two passkeys, one using 1Password and one using Apple's Password.
The one site I have not done this with is Premera. They only let you have one passkey as far as I can tell.
> I don't like getting locked in to one password manager.
You can choose any credential manager you like, including those like Bitwarden who give you full control of your data.
You can choose any credential manager you like, including those like Bitwarden who give you full control of your data.
I'm not sure why you're picking up negative sentiment? It seems mostly factual and not particularly against passkeys.
(I'm in favor of passkeys, but also agree with the article that for people using password managers properly, there's no need to hurry on migrating.)
(I'm in favor of passkeys, but also agree with the article that for people using password managers properly, there's no need to hurry on migrating.)
Passkeys seem like alpha software that somehow got shipped by mistake. Wake me up in 5 years when/if they are actually safely usable (not just securely usable). Until then I advise my family members to stay away from them and I think everyone else should too.
Alpha and shipped too early - spot on. My personal strategy is to adopt at the last moment I absolutely have to. I know Dan, and liked the article, but I feel he ended it too early. The Passkeys leads don't have a solid website with an FAQ from a non-technical end user point of view and it is desperately needed.
The fact that you can't actually see the passkey is absurd. I understand it's a "feature" prevent phishing — victims have a lot less to share — but it constrains more sophisticated storage and use of passwords.
Their spec doesn't dictate that you shouldn't be able to see it. It's just dumb implementations that do it (mostly for lock-in purposes). There are ones where you can see it just fine.
It's not for lock in, it's for anti phishing purposes. Passkey managers are designed so that grandma on the phone to a scammer can't physically dump and email her entire passkey vault. It's impossible to get phished by a fake login page with Passkeys and it's impossible to send your private keys to someone on the mainstream Passkey managers.
Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
Portability between Passkey managers is still an issue though. Last I checked there were in draft specs for migrating between managers but nothing ready yet.
Not being able to see it all can't be justified with "for phishing purposes". You can put a big warning there that exposing your private key is a risk, but user should be able to see it with needed effort. Not being able to see it at all is a problem, like anything that moves away control from the user to some external entity.
Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
The person on the phone will just instruct grandma to ignore the warning and that it's important she continue and send the private key over to secure her account.
Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.
Considering there isn't really anything you can do with the private key other than logging in to a website, making phishing impossible is a higher priority than letting people view the keys. There are alternative open source passkey managers which do let you view them. But it seems pretty obvious the average person is much better off not having this.
The person on the phone will walk grandma through installing remote desktop, make gradma login to the account, show a fake Windows update picture fullscreen, and do whatever they like.
It's not reasonable to remove all agency from users because they sometimes click through warnings. Scammers will do the exact same refund scam script that they do today, and at no point will a passkey stop someone from doing a sketchy money transfer, or letting the scammer control their computer.
It just doesn't make sense to impose these extreme restrictions on exporting passkeys that won't stop the most common phone scams sctipts at all.
It's not reasonable to remove all agency from users because they sometimes click through warnings. Scammers will do the exact same refund scam script that they do today, and at no point will a passkey stop someone from doing a sketchy money transfer, or letting the scammer control their computer.
It just doesn't make sense to impose these extreme restrictions on exporting passkeys that won't stop the most common phone scams sctipts at all.
Well, I'm talking about definition of the spec and principle here. If they start dictating impossibility of looking at your own private keys by design of the spec, it should be strongly pushed back against. There is enough of abuse in taking away control from the user with all kind of opaque stuff.
And what you can do or want to do with your private key is really up to you. Copy it and import into another password manager could be a reasonable use case, besides simple curiosity. Basically, slapping on it some kind of DRM-like restrictions in the name of security isn't right.
You can make it non trivial to make it more clear that it has risks, but not prevent users from accessing it if they insist.
And what you can do or want to do with your private key is really up to you. Copy it and import into another password manager could be a reasonable use case, besides simple curiosity. Basically, slapping on it some kind of DRM-like restrictions in the name of security isn't right.
You can make it non trivial to make it more clear that it has risks, but not prevent users from accessing it if they insist.
So there is a portability spec in progress for copying your passkeys between password managers, it's just seemingly not ready yet.
You can also use KeepassX which lets you export the keys in plain text which would be the power user option. Passkeys as a tech doesn't stop you doing this, only the mainstream Passkey managers.
You can also use KeepassX which lets you export the keys in plain text which would be the power user option. Passkeys as a tech doesn't stop you doing this, only the mainstream Passkey managers.
KeepassXC is great, until the Passkey mafia starts actively blocking its use: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
> 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).
Or in less patronizing terms: "do what we want or we're blacklisting you."
> 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).
Or in less patronizing terms: "do what we want or we're blacklisting you."
who exactly is "we" in this context?
keepassxc is good, yeah. The point I'm making is that it shouldn't become mandatory to always force this DRM stuff. So far it didn't happen, but it always can.
They're probably just trying to not get their implementation blackballed with the attestation feature like one of the FIDO devs immediately threatened to do to keepass: https://github.com/keepassxreboot/keepassxc/issues/10407
I think the dance is all for naught though, they'll end up locked out as non-standard once uptake is high enough IMO.
I think the dance is all for naught though, they'll end up locked out as non-standard once uptake is high enough IMO.
The control freak approach proponents will push for it I'm sure. There should be more push against it though.
> one of the FIDO devs immediately threatened to do to keepass
Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues).
1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice
2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world?
Enough with this bullshit.
Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues).
1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice
2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world?
Enough with this bullshit.
They aren't passwords, they are just glorified private / public keys that are hard to manage due to all kind of attached requirements. But it's somewhat better now with tools like keepassxc.
Private keys themselves are essentially just glorified passwords.
It might help to think of them like that, but they aren't the same in some pretty important ways. The website never gets access to your private key like they do with passwords.
So even if a website has it's database breached, there isn't a need to reset your passkeys since they were never compromised. I guess maybe you might have to be sure the attacker didn't replace your pub key with their own.
So even if a website has it's database breached, there isn't a need to reset your passkeys since they were never compromised. I guess maybe you might have to be sure the attacker didn't replace your pub key with their own.
Just in case you (or someone reading) doesn't know the technical details, private keys are distinctly different from passwords, on how they work to authenticate the user.
In case of an online login, a password travels to the server, and gets checked against its stored form, to see if the user's login request is valid.
In case of a private key, the server sends a bit of data that the user signs digitally on their own device with their private key, sends back the signed data, and the server checks authenticity with the user's previously stored public key.
So at the end of the day, private keys are not essentially glorified passwords. Yes, both are strings that are used to authenticate. But it's their very essence itself that makes the difference.
In case of an online login, a password travels to the server, and gets checked against its stored form, to see if the user's login request is valid.
In case of a private key, the server sends a bit of data that the user signs digitally on their own device with their private key, sends back the signed data, and the server checks authenticity with the user's previously stored public key.
So at the end of the day, private keys are not essentially glorified passwords. Yes, both are strings that are used to authenticate. But it's their very essence itself that makes the difference.
I hope you are making a humorous understatement
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login, but the site/app has no way of knowing/proving whether that happened; they just get the password.
Thought sites can request hardware attested passkeys? In this case usb keyfob, or passkeys instanced from a secure enclave, etc.?
Thought sites can request hardware attested passkeys? In this case usb keyfob, or passkeys instanced from a secure enclave, etc.?
stuff like this makes me wish Firefox supported serial communication like Chrome does :/. I haven't run into this since I don't have a hardware passkey, but the Circuit Python website makes it super easy to communicate and flash over serial... expect I have to use Chrome for five minutes
For DIY interaction with USB Webauthn/Passkey hardware tokens, you don't want serial (USB CDC), you want USB HID protocol. Those are two different things.
This was briefly possible with WebUSB, but all mainstream browser vendors have a stoplist of certain USB devices for security reasons.
This was briefly possible with WebUSB, but all mainstream browser vendors have a stoplist of certain USB devices for security reasons.
Just don't use that on windows with how they have broken most real hardware tokens with their bluetooth nonsense.
Fully admitting, I'm still learning about this topic. Also admitting that my current impression of the whole passkey system looks like a massively user-hostile and lock-in prone technology. But I have some questions to better understand it:
- Suppose I'm a website owner and I handle authentication of my users with passkeys. Now for whatever reason, I want/have to move my site to a different domain. How would I "move" the passkeys, as they'd still be tied to the old domain?
- Passkeys on Yubikeys or other dedicated hardware token sounds easy enough and mostly reasonable. (I could buy a bunch if yubikeys, copy the keys onto each of then and keep some if them as a backup in the drawer. The security properties of those seem a lot like regular keys or chip cards) Passkeys on phones or on cloud accounts much less so, but this is the main method that is promoted and expected to be used by "regular" users. But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored?
- I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?
- Suppose I'm a website owner and I handle authentication of my users with passkeys. Now for whatever reason, I want/have to move my site to a different domain. How would I "move" the passkeys, as they'd still be tied to the old domain?
- Passkeys on Yubikeys or other dedicated hardware token sounds easy enough and mostly reasonable. (I could buy a bunch if yubikeys, copy the keys onto each of then and keep some if them as a backup in the drawer. The security properties of those seem a lot like regular keys or chip cards) Passkeys on phones or on cloud accounts much less so, but this is the main method that is promoted and expected to be used by "regular" users. But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored?
- I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?
Let me address your questions in reverse order.
> I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?
In general, logging into your password manager with a passkey is probably the least compelling way to use passkeys; you'll need some kinda backup code (i.e. a password) to avoid losing access to the password manager and the passkeys inside it.
The company 1Password calls it that because, yes, you're probably going to need to memorize/retain one last password, the one you use to login to your password manager.
If Google is your password manager, then, yeah, you're going to need something outside the password manager to login to the safe and get access to your passkeys and other passwords. You'll probably need to use a password for that.
But https://myaccount.google.com/security lists a bunch of alternatives:
• TOTP authenticator
• Google prompt on multiple devices (login to YouTube on another machine? use that as a second factor)
• Recovery email
• Recovery phone
• Backup codes (one-time passwords)
If you lose your Google password, you'll have go through Google's password reset process. It can be hellish, but if you've set up backup codes and recovery contacts, you'll probably be fine.
> But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored?
Yeah, you lose access to your Google password/passkey safe when Google bans you.
(It depends a little on how you got banned. If you're an identified persona non grata, sometimes they'll let you export some of your data with Google Takeout. If you're locked out of your account (because you lost your password and all of your other factors), well, of course you can't access your password safe at that point, because you can't prove your identity to Google.)
If Google is your password safe, you really must set up backup codes, and you need to keep them safe. That's true regardless of whether you use Google passkeys or not.
Either way, it sounds like maybe you don't want to trust Google as your password manager. It's perfectly reasonable to mistrust Google. There are a number of good alternative password managers that support passkeys; consider using them instead.
> How would I "move" the passkeys, as they'd still be tied to the old domain?
You can't really "move" passwords, either, because any phishing site could claim to be your site. ("We've moved! Please enter your password for example.com here. hehehe")
But, while you control both sites, you could log people in on the old site and then redirect people over to your new site and let them create a new password/passkey there.
But, if you're moving domains, you're probably just going to have to revalidate a significant fraction of your users, putting them through your "reset my password/passkey" flow. If your site does that with a "forgot my password" email, that's probably OK-ish.
> I have a set of passkeys on my phone and the phone gets stolen. Do I instantly lose access to all my services? Probably not, because the keys are still in the cloud, but then how do I authenticate to Google from a new device?
In general, logging into your password manager with a passkey is probably the least compelling way to use passkeys; you'll need some kinda backup code (i.e. a password) to avoid losing access to the password manager and the passkeys inside it.
The company 1Password calls it that because, yes, you're probably going to need to memorize/retain one last password, the one you use to login to your password manager.
If Google is your password manager, then, yeah, you're going to need something outside the password manager to login to the safe and get access to your passkeys and other passwords. You'll probably need to use a password for that.
But https://myaccount.google.com/security lists a bunch of alternatives:
• TOTP authenticator
• Google prompt on multiple devices (login to YouTube on another machine? use that as a second factor)
• Recovery email
• Recovery phone
• Backup codes (one-time passwords)
If you lose your Google password, you'll have go through Google's password reset process. It can be hellish, but if you've set up backup codes and recovery contacts, you'll probably be fine.
> But what happens if I have my passkeys stored in a Google account or whatever and then Google decides to ban me? Do I permanently lose access not just to all Google services but also to all services that had a passkey stored?
Yeah, you lose access to your Google password/passkey safe when Google bans you.
(It depends a little on how you got banned. If you're an identified persona non grata, sometimes they'll let you export some of your data with Google Takeout. If you're locked out of your account (because you lost your password and all of your other factors), well, of course you can't access your password safe at that point, because you can't prove your identity to Google.)
If Google is your password safe, you really must set up backup codes, and you need to keep them safe. That's true regardless of whether you use Google passkeys or not.
Either way, it sounds like maybe you don't want to trust Google as your password manager. It's perfectly reasonable to mistrust Google. There are a number of good alternative password managers that support passkeys; consider using them instead.
> How would I "move" the passkeys, as they'd still be tied to the old domain?
You can't really "move" passwords, either, because any phishing site could claim to be your site. ("We've moved! Please enter your password for example.com here. hehehe")
But, while you control both sites, you could log people in on the old site and then redirect people over to your new site and let them create a new password/passkey there.
But, if you're moving domains, you're probably just going to have to revalidate a significant fraction of your users, putting them through your "reset my password/passkey" flow. If your site does that with a "forgot my password" email, that's probably OK-ish.
> How would I "move" the passkeys, as they'd still be tied to the old domain?
You can also use a combination of Related Origin Requests[1], Conditional Create, and Signal API to allow the passkey for the old site to be used on your new site, automatically create a new passkey for the new domain, and optionally tell the user's credential manager that the old passkey is no longer valid.
[1] https://passkeys.dev/docs/advanced/related-origins/
You can also use a combination of Related Origin Requests[1], Conditional Create, and Signal API to allow the passkey for the old site to be used on your new site, automatically create a new passkey for the new domain, and optionally tell the user's credential manager that the old passkey is no longer valid.
[1] https://passkeys.dev/docs/advanced/related-origins/
I think the summary of that is "passkeys only solve the problems the designers cared to solve, and I care about some others but not those".
I heard at a conference that users of one large freemail service store their passwords in an average of seven different files, so that provides an average of eight different possible attack vectors to get hold of a user's password — seven plus social engineering.
I heard at a conference that users of one large freemail service store their passwords in an average of seven different files, so that provides an average of eight different possible attack vectors to get hold of a user's password — seven plus social engineering.
> To present a passkey, you have to use a password manager.
This is what makes passkeys nonstarters for me.
This is what makes passkeys nonstarters for me.
that isn't true at all.
i regularly use a yubikey as a passkey, and it's entirely orthogonal to any password manager i use. it happily just works on firefox on both mac and linux.
to use a passkey, you need a place to store the passkey. that can be a hardware token, a tpm, or a password manager.
i regularly use a yubikey as a passkey, and it's entirely orthogonal to any password manager i use. it happily just works on firefox on both mac and linux.
to use a passkey, you need a place to store the passkey. that can be a hardware token, a tpm, or a password manager.
Yubikeys are an even worse solution, in my opinion. They dramatically increase the amount of hassle and maintenance required because you have to have multiples of them to ensure that you won't get locked out.
Also, it's not always convenient or possible to plug something into a machine you're using.
> to use a passkey, you need a place to store the passkey.
Yes, and any place that requires me to use particular piece of software, machine, or device is a real friction point for me.
Also, it's not always convenient or possible to plug something into a machine you're using.
> to use a passkey, you need a place to store the passkey.
Yes, and any place that requires me to use particular piece of software, machine, or device is a real friction point for me.
What is someone steals your backpack with your laptop and all your yubikeys, your phone, etc? How do you get back your access?
Don't keep all of your yubikeys and phones and laptops in one bag.
Unfortunately, many services don't allow you to register multiple passkeys, so having a backup key that is stored somewhere safe is simply not an option.
That's why you have multiple passkeys that have the same key. It's a physical backup, not a software backup.
Is that what you have set up? Can you describe how you do it in more detail? I'm looking for an option like this but everything I've found seems to suggest it's not possible (or at the very least wildly impractical). I'm looking for something where it's at least possible to make a physical backup that's still relatively secure.
... at which point you lose the whole "something you have" part of 2FA. If they all have the same key, it is impossible to distinguish between individual copies, so the compromise of a single copy is impossible to detect. Additionally, you can't revoke a single copy: you are now forced to revoke all of them at once.
I have 5 in Google.
That doesn’t answer the question, unless it means you’re SOL. If that’s the case why on earth would I prefer passkeys to regular passwords as long as I practice safe password handling?
Do whatever you want. It's easier for me to have a primary recovery email and password manager with MFA that uses a yubikey and phone authenticator. Then I can use passkeys or whatever for the rest of the stupid accounts that I don't care about.
Side note: I feel like people always say 'i can just use good passwords' and then their password is like '<sports reference><year>'
Side note: I feel like people always say 'i can just use good passwords' and then their password is like '<sports reference><year>'
Don't bring anythng you really wouldn't want to get stolen anywhere outside of your house.
What if your house burns down with all your contents?
My point being, there is a reasonable limit to how many physical passkeys a person would make but there’s also a non-zero possibility that a physical catastrophe could occur that destroys all the passkeys.
What happens in that case? Can you recover your accounts?
My point being, there is a reasonable limit to how many physical passkeys a person would make but there’s also a non-zero possibility that a physical catastrophe could occur that destroys all the passkeys.
What happens in that case? Can you recover your accounts?
Most sites currently have you create your account with a password, and then later you can add passkeys.
If you still have your passwords after your house burns down you can use those to get into sites.
If your house burning down also wiped out wherever you store your passwords, you'd use whatever mechanism each site provides for recovering from a lost password.
If you still have your passwords after your house burns down you can use those to get into sites.
If your house burning down also wiped out wherever you store your passwords, you'd use whatever mechanism each site provides for recovering from a lost password.
[deleted]
It's not true at all.
Not many apps support passkeys, but for the ones that do, it's a godsend. No longer do I have to worry about whether my password is stored in Google, or Firefox, or if it's up to date, or what happens if I get hacked. I just plug my little key into the computer and tap it.
It's like having a physical key instead of having your password written in a page of an obscure book in the library. Probably safe, but someone dedicated can find it. A physical key can only be taken if my house gets robbed.
Not many apps support passkeys, but for the ones that do, it's a godsend. No longer do I have to worry about whether my password is stored in Google, or Firefox, or if it's up to date, or what happens if I get hacked. I just plug my little key into the computer and tap it.
It's like having a physical key instead of having your password written in a page of an obscure book in the library. Probably safe, but someone dedicated can find it. A physical key can only be taken if my house gets robbed.
> No longer do I have to worry about whether my password is stored in Google, or Firefox
Once Google and Firefox start pushing their passkey implementation, you do. One issue with them is user confusion about where the passkey is stored.
And do you have a backup solution for if you lose your physical key? That's the big problem I have in practice at the moment: I would like a physical device for storing credentials, but I 100% cannot have it as a single point of failure. Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!.
Once Google and Firefox start pushing their passkey implementation, you do. One issue with them is user confusion about where the passkey is stored.
And do you have a backup solution for if you lose your physical key? That's the big problem I have in practice at the moment: I would like a physical device for storing credentials, but I 100% cannot have it as a single point of failure. Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!.
> Unfortunately at the moment it seems like I either have a cloud sync vendor lock-in or a single point of failure, or I have the completely impractical solution of enrolling multiple devices, which means I have to carry both around with me, thus making it far more likely I lose both of them!
• You can use multiple independent cloud sync vendors. When I add passkeys to an account I add two passkeys. One gets stored in 1Password and synced using their cloud. The other gets stored in Apple's Password and synced using Apple's cloud. This should give you enough redundancy to mitigate most vendor lock-in concerns.
• If using devices that don't cloud sync I don't see why your would need to carry around two devices in order to enroll two devices. Carry around one device, and when you make a new account create a passkey for that account stored in the device.
Later, back home, login into any accounts you created while away using the passkeys on the device you were carrying, and create a second passkey on each of those accounts and store it on the other device.
• You can use multiple independent cloud sync vendors. When I add passkeys to an account I add two passkeys. One gets stored in 1Password and synced using their cloud. The other gets stored in Apple's Password and synced using Apple's cloud. This should give you enough redundancy to mitigate most vendor lock-in concerns.
• If using devices that don't cloud sync I don't see why your would need to carry around two devices in order to enroll two devices. Carry around one device, and when you make a new account create a passkey for that account stored in the device.
Later, back home, login into any accounts you created while away using the passkeys on the device you were carrying, and create a second passkey on each of those accounts and store it on the other device.
Manually enrolling multiple devices/apps is pretty much the main thing that I view as impractical (especially because I need a system that can handle a range of authentication options: not everything supports passkeys, some passkey implementations prevent enrolling multiple devices, and that's the standard for TOTP as well). I have a lot of accounts, and it's really not something I can manage reliably to make sure that two different systems are in sync.
The thing is, this seems like an entirely solvable problem, from multiple angles: e.g. an end-to-end encrypted sync between devices (using some pairing process), or, even better, a way to enroll a non-present device as an alternative (though this has some of its own challenges, if not just using a persistent certificate). It suprises me a little that there's nothing that really attempts to address this.
The thing is, this seems like an entirely solvable problem, from multiple angles: e.g. an end-to-end encrypted sync between devices (using some pairing process), or, even better, a way to enroll a non-present device as an alternative (though this has some of its own challenges, if not just using a persistent certificate). It suprises me a little that there's nothing that really attempts to address this.
> The thing is, this seems like an entirely solvable problem, from multiple angles: e.g. an end-to-end encrypted sync between devices (using some pairing process), or, even better, a way to enroll a non-present device as an alternative (though this has some of its own challenges, if not just using a persistent certificate). It suprises me a little that there's nothing that really attempts to address this
Apple is adding that in iOS 26 and MacOS 26 [1], based on the FIDO specification for this [2].
Google is also in the midst of implementing it [3].
[1] https://fidoalliance.org/9to5mac-apple-work-passkey-portabil...
[2] https://fidoalliance.org/specifications-credential-exchange-...
[3] https://fidoalliance.org/mobileidworld-google-developing-pas...
Apple is adding that in iOS 26 and MacOS 26 [1], based on the FIDO specification for this [2].
Google is also in the midst of implementing it [3].
[1] https://fidoalliance.org/9to5mac-apple-work-passkey-portabil...
[2] https://fidoalliance.org/specifications-credential-exchange-...
[3] https://fidoalliance.org/mobileidworld-google-developing-pas...
> No longer do I have to worry about whether my password is stored in Google, or Firefox
You never have too worry about it with a password manager, and also don't need to worry whether your key is plugged in in the computer you're currently using
You never have too worry about it with a password manager, and also don't need to worry whether your key is plugged in in the computer you're currently using
Are you not already using password manager for all of your passwords?
It took forever to make any movement towards getting people to stop using the same password every where. Now we're telling people passwords aren't secure even with using a password manager and they should use passkeys. So now we're saying that using the same software that we spent so much time suggesting to use is not good enough. Instead, now you want them to use a dedicated piece of hardware that needs to never be lost, but people lose their phones frequently.
It's amazing to me how the majority of readers here absolutely cannot put themself in the place of non-computer nerds that spend 0% of their day thinking about code/security or anything other than what the Kardashiens are doing or their favorite influencer or whatever other nonsense that is everything and not nonsense to them. It's this kind of thinking that put us in this position that the people building the thing can't think about how the users will actually use it
It took forever to make any movement towards getting people to stop using the same password every where. Now we're telling people passwords aren't secure even with using a password manager and they should use passkeys. So now we're saying that using the same software that we spent so much time suggesting to use is not good enough. Instead, now you want them to use a dedicated piece of hardware that needs to never be lost, but people lose their phones frequently.
It's amazing to me how the majority of readers here absolutely cannot put themself in the place of non-computer nerds that spend 0% of their day thinking about code/security or anything other than what the Kardashiens are doing or their favorite influencer or whatever other nonsense that is everything and not nonsense to them. It's this kind of thinking that put us in this position that the people building the thing can't think about how the users will actually use it
That's not the problem: the problem is if I change password managers, or move software or any of many other possible things, whereas with password I can just type them into the new thing in the worst case...passkeys are wholly opaque.
The ability to migrate them was considered an optional feature and not implemented before they were launched. It's still wholly unclear whether any individual implementation will let you do that or not, with options to prevent it.
The ability to migrate them was considered an optional feature and not implemented before they were launched. It's still wholly unclear whether any individual implementation will let you do that or not, with options to prevent it.
Again, it's us nerds making thing that didn't make it well enough that it causes pain on the end users. Not really sure how that's not the problem.
Standards/specs set incentives which uniquely decide implementation quality. If after many years implementations backed by a variety of funding and brains _all_ suck, then it's the standard/spec's problem.
Passkeys aren't tied to hardware. Basically every password manager syncs them between devices. If you just go the easy route of using the Apple/Google password manager you'll never lose access unless you lose your whole Apple/Google account.
Except sibling comment to yours says that they are not so easily transferable. We're also discussing using a fob for the passkey. That's the physical hardware that I was referring. People keep tossing around Yubikey type of suggestions. How is that not hardware? Why do we keep making strange comments like this when they're clearly not true.
The Apple, Google, 1Password, etc managers sync Passkeys to your account between all devices. Sure, if you specifically use a hardware device like a Yubikey then you can physically lose it but most people will never have a hardware authenticator.
There are device-bound passkeys.
How do you plan to sync your passkey between devices?
Another feature of the password manager.
Another feature of the password manager.
> Passkeys make it harder to switch password managers, because you can’t copy and paste them
Does it not depend on the manager? Doesn't keepass manager allow open access to your passkey so you could also copy and paste it?
Does it not depend on the manager? Doesn't keepass manager allow open access to your passkey so you could also copy and paste it?
The article looks like either author knows something I don't (but fails to link any source on their claims), or is a bunch of misinformation.
> Passkeys are randomly generated passwords that are required to be managed by a password manager.
This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials.
Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends.
> Passkeys can be public/private keypairs, or they can just be secret passwords.
To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern.
> Password managers provide no way for you to copy and paste your passkeys.
This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
> A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened
This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.
> Passkeys are randomly generated passwords that are required to be managed by a password manager.
This is not correct. Passkeys are keypairs, and unlike shared secrets (like passwords) they do not require private key material to be ever revealed to the remote system. That's the whole point of Webauthn - so servers never ever possibly see any secret credentials.
Otherwise - yes - they're random-looking blobs of data that is handled by a special software (which can be a password manager, but is not limited to password managers - e.g. an HSM like Yubikey can be used without any password management software), but that's where the similarity ends.
> Passkeys can be public/private keypairs, or they can just be secret passwords.
To best of my awareness, this is incorrect. I'm really curious where this idea comes from. In my understanding of the Webauthn spec it's all about public-key cryptography, attestations always use PublicKeyCredential. I'm not aware about any way to use a static token instead. Maybe it's possible to bastardize the standard somehow, but I doubt it's a real concern.
> Password managers provide no way for you to copy and paste your passkeys.
This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
> A passkey manager is morally required to do an extra factor of authentication [...] but the site/app has no way of knowing/proving whether that happened
This is partially correct. There is attestation in Webauthn, but to best of my awareness it's something frowned upon, so IMHO it's best if we all pretend it doesn't exist. If attestation is not required (which is AFAIK how most Webauthn-supporting services operate), it's up to user to decide on how they secure their system. And that's a good thing (YMMV), because it allows end user to have freedom of choice.
> This is only partially true. Nothing in the spec, all up to implementers. At least KeypassXC sure provides a way to access your data: https://github.com/keepassxreboot/keepassxc/issues/10407. Other software behavior may vary.
This thread is one of the guys from FIDO threatening to blacklist keypass for doing just that, using the spec'd passkey attestation feature as the tool to do so. Just because the attestation feature isn't widely used as a weapon just this second doesn't mean that is not the intended endgame, in fact I'd argue the hand was tipped in that very thread.
This thread is one of the guys from FIDO threatening to blacklist keypass for doing just that, using the spec'd passkey attestation feature as the tool to do so. Just because the attestation feature isn't widely used as a weapon just this second doesn't mean that is not the intended endgame, in fact I'd argue the hand was tipped in that very thread.
There's also a FIDO standard in the works for how to export passkeys: https://blog.1password.com/fido-alliance-import-export-passk...
> Passkeys can be public/private keypairs, or they can just be secret passwords. (WebAuthn passkeys were designed by committee, so there’s always more than one way to do it.)
I'm surprised by this. Last time I checked, a few years ago, I couldn't create a passkey in Chrome without using either the Chrome developer tools to create an emulated passkey, or an actual hardware device. Why would I use a TPM to store a shared secret? Has this changed, or did I miss something?
> Instead, password managers recommend that sites/apps allow each user to have multiple passkeys. Sites/apps may or may not actually allow that, but, for now, that’s the only way to be sure a given user can login with both Google’s password manager and Apple’s password manager: give each password manager its own passkey for each site.
Having a simple procedure for rotating/replacing keys would probably be useful for the "switch password manager/TPM" case. I.e. a protocol between two password managers and a browser to do batch authorization of a new key. The migration story is one reason I don't use passkeys.
I'm surprised by this. Last time I checked, a few years ago, I couldn't create a passkey in Chrome without using either the Chrome developer tools to create an emulated passkey, or an actual hardware device. Why would I use a TPM to store a shared secret? Has this changed, or did I miss something?
> Instead, password managers recommend that sites/apps allow each user to have multiple passkeys. Sites/apps may or may not actually allow that, but, for now, that’s the only way to be sure a given user can login with both Google’s password manager and Apple’s password manager: give each password manager its own passkey for each site.
Having a simple procedure for rotating/replacing keys would probably be useful for the "switch password manager/TPM" case. I.e. a protocol between two password managers and a browser to do batch authorization of a new key. The migration story is one reason I don't use passkeys.
> Why would I use a TPM to store a shared secret?
There is no shared secret. A passkey is a public/private key pair.
There is no shared secret. A passkey is a public/private key pair.
> Why would I use a TPM to store a shared secret?
I don't understand your incredulity at this; a disk encryption key is a shared secret and commonly stored in a TPM. It kinda still makes sense because the TPM 'enforces' platform security.
But a TPM isn't the same as a hardware token, and storing a shared secret on a hardware token does make less sense. But that doesn't prevent people from doing it...
I don't understand your incredulity at this; a disk encryption key is a shared secret and commonly stored in a TPM. It kinda still makes sense because the TPM 'enforces' platform security.
But a TPM isn't the same as a hardware token, and storing a shared secret on a hardware token does make less sense. But that doesn't prevent people from doing it...
> a disk encryption key is a shared secret and commonly stored in a TPM.
Thinking some more about this, you're right. If the stored shared secret is high entropy, and the user might choose a weak password, then using the TPM as a defense against password cracking is a useful reason for the seeming indirection.
That assumes the TPM can e.g. rate limit extraction attempts and not be foiled by power-loss or sped up oscillators or similar externalities.
Thinking some more about this, you're right. If the stored shared secret is high entropy, and the user might choose a weak password, then using the TPM as a defense against password cracking is a useful reason for the seeming indirection.
That assumes the TPM can e.g. rate limit extraction attempts and not be foiled by power-loss or sped up oscillators or similar externalities.
My understanding of Passkeys used to be that they were hardware-bound, so stored in the system’s TPM, Secure Enclave, whatever. Somewhere they can’t be retrieved. As soon as I realised that wasn’t the case I lost all interest in Passkeys.
Why would I bother when it’s basically just a password? Some services I’ve seen dangerously accept it as a form of 2FA, when it’s anything but.
Why would I bother when it’s basically just a password? Some services I’ve seen dangerously accept it as a form of 2FA, when it’s anything but.
One key difference is that it's not anything like a password.
With a password, you send your password to the server and hope it's not intercepted or stored in plain text.
Passkeys are more equivalent to the server sending you some random data and asking you to sign that data plus the server url with your private key. Then the server can check it against the public key it has to verify you possess the correct private key. It's both phishing and replay resistant.
With a password, you send your password to the server and hope it's not intercepted or stored in plain text.
Passkeys are more equivalent to the server sending you some random data and asking you to sign that data plus the server url with your private key. Then the server can check it against the public key it has to verify you possess the correct private key. It's both phishing and replay resistant.
That is the case - provided they are backed by a hardware token like a Yubikey.
This is correct. There are two types of passkeys: device-bound and synced. You can choose whichever credential manager/authenticator that supports your needs.
https://passkeys.dev/docs/reference/terms/#synced-passkey
https://passkeys.dev/docs/reference/terms/#device-bound-pass...
https://passkeys.dev/docs/reference/terms/#synced-passkey
https://passkeys.dev/docs/reference/terms/#device-bound-pass...
It's telling that the "exchange protocol" was only begun to be developed after the main spec was written, and apparently as a response to pushback from the community. I can't imagine designing something like that and not having this be a core part of the feature set from day one. It's not even necessarily about switching vendors. When you first learn about passkeys, something as basic as what you need to do when you get a new computer is unclear. "The passwords are yours, we're just giving them a bodyguard" should have been the message from day one, but it wasn't of course, because that wasn't what was actually being pitched.
I want to point out a subtle part of this critique: I don't necessarily think that vendor lock-in or anything like that was an intentional goal (I make no claim either way there), but rather what is worrying to me is that the experiences of the designers of this technology seem to be so different from ours that this feature wasn't an obvious v1 need, and as such makes me worried that the "solution" will also not be representative of what we actually need (perhaps it will be overly complicated and focus on the large vendors and not on being able to extract them easily yourself for example). This all sort of makes sense though, given that it seems to have had significant influence from humongous corporations like Apple and Google, where the idea of moving away sincerely confuses them.
All of the "FIDO Alliance"[1] copy has a distinct tone of them seeing their job as chaperoning users like kids who don't know any better and are in constant danger of hurting themselves on the playground. Even the end user benefits read like business benefits on that site, with such gems as "Higher sign-in success rates". That made the list for convincing users? It's as if they've grown exasperated in trying to "teach" people about phishing, it feels like the obfuscation is a feature of passkeys, a long awaited release from the burden of learning about passwords. Which, to be clear, would possibly be great, if it handled the things people care about. But this obfuscation goes beyond the "implementation" and into the "usage". It goes from "it's simple to use" to "don't worry your pretty little head over that". I've found the whole thing rather bizarre, especially since many people on the browser side seem either oblivious to pushback, or annoyed. There is a unique "just trust us" feel to the this feature.
A brief note: This isn't all that unexpected for completely non-nefarious reasons. I've spoken before about a common pattern I've witnessed where "platform owners" (where "owner" can be anything from a "company" to a "developer") usually start off empathizing with the user, but the longer they work on the platform, the more contempt they develop for the user and the more empathy they develop for "the platform". I've seen it everywhere from language and compiler developers (where the more senior they are, the more the features they suggest tend to make the "compiler's life" easier, such as complex features that enable performance boosts, instead of trying to figure out how to make the code people write go faster; to web engine developers, who over time suggest lower and lower level features (such as WebGPU or WASM) vs. "going big" on high level semantic features, etc.). This makes sense if you've ever worked in these environments, the nature of bug fixing and reporting is such that you get an incredibly lopsided biased view of the usage of the platform: you see all the worst usage of it. Day after day, it can demoralize and lead you to think that what users need is in fact to have less say in what goes on, your trust in their ability to learn or improve degrades, and with it "ergonomics" as a first priority.
1. https://fidoalliance.org/passkeys/
I want to point out a subtle part of this critique: I don't necessarily think that vendor lock-in or anything like that was an intentional goal (I make no claim either way there), but rather what is worrying to me is that the experiences of the designers of this technology seem to be so different from ours that this feature wasn't an obvious v1 need, and as such makes me worried that the "solution" will also not be representative of what we actually need (perhaps it will be overly complicated and focus on the large vendors and not on being able to extract them easily yourself for example). This all sort of makes sense though, given that it seems to have had significant influence from humongous corporations like Apple and Google, where the idea of moving away sincerely confuses them.
All of the "FIDO Alliance"[1] copy has a distinct tone of them seeing their job as chaperoning users like kids who don't know any better and are in constant danger of hurting themselves on the playground. Even the end user benefits read like business benefits on that site, with such gems as "Higher sign-in success rates". That made the list for convincing users? It's as if they've grown exasperated in trying to "teach" people about phishing, it feels like the obfuscation is a feature of passkeys, a long awaited release from the burden of learning about passwords. Which, to be clear, would possibly be great, if it handled the things people care about. But this obfuscation goes beyond the "implementation" and into the "usage". It goes from "it's simple to use" to "don't worry your pretty little head over that". I've found the whole thing rather bizarre, especially since many people on the browser side seem either oblivious to pushback, or annoyed. There is a unique "just trust us" feel to the this feature.
A brief note: This isn't all that unexpected for completely non-nefarious reasons. I've spoken before about a common pattern I've witnessed where "platform owners" (where "owner" can be anything from a "company" to a "developer") usually start off empathizing with the user, but the longer they work on the platform, the more contempt they develop for the user and the more empathy they develop for "the platform". I've seen it everywhere from language and compiler developers (where the more senior they are, the more the features they suggest tend to make the "compiler's life" easier, such as complex features that enable performance boosts, instead of trying to figure out how to make the code people write go faster; to web engine developers, who over time suggest lower and lower level features (such as WebGPU or WASM) vs. "going big" on high level semantic features, etc.). This makes sense if you've ever worked in these environments, the nature of bug fixing and reporting is such that you get an incredibly lopsided biased view of the usage of the platform: you see all the worst usage of it. Day after day, it can demoralize and lead you to think that what users need is in fact to have less say in what goes on, your trust in their ability to learn or improve degrades, and with it "ergonomics" as a first priority.
1. https://fidoalliance.org/passkeys/
> It's telling that the "exchange protocol" was only begun to be developed after the main spec was written, and apparently as a response to pushback from the community.
And that it continues to be vaporware.
And that it continues to be vaporware.
The article already defeats itself in the title: password managers are a must-have. One needs to choose a good password manager, but that's already true.
The difference is that I don't know my passkey by heart and can't give it away involuntarily. And the design of passkeys is way more robust than plain 2FA.
Having to centralise your, essentially login process, seems like an awful idea. Similarly to a paper ballot system, the current 'attack surface' of the huge array of password managers, text files, notebooks, etc renders compromising a specific someone's entire digital life not scalable really not so much a widespread thing.
When every service is using a handful of central login handlers, I can imagine oppressive regimes, malicious entities, etc will have a field day trivially getting access to everything they've done and said.
I'm not really a conspiracy theorist, but this definitely feels like it could go bad.
When every service is using a handful of central login handlers, I can imagine oppressive regimes, malicious entities, etc will have a field day trivially getting access to everything they've done and said.
I'm not really a conspiracy theorist, but this definitely feels like it could go bad.
no they aren't, they are asymetric key pairs
They are static pieces of private data that require you to have a password manager. In simpleton terms, the title is accurate.
Absolutely not, because the sensitive part (the private key) is never sent to the website, so unlike a password it cannot be sniffed or leaked or stolen. It will never end up in a data breach or haveibeenpwned.
With this comes a new problem: how do you reset it?
With this comes a new problem: how do you reset it?
Good point.
From a user perspective, though, the management of it remains, and in many cases, sites are not allowing you to manage your passkeys in your preferred manner. They become harder to back up and transfer.
From a user perspective, though, the management of it remains, and in many cases, sites are not allowing you to manage your passkeys in your preferred manner. They become harder to back up and transfer.
Can we substitute "password" for all instances of "private key"?
This article is pretty much all wrong.
Holy AI slop Batman!
Yes. So?
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.