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. Given how criminally insecure passwords and push/code based MFA are in the face of user incompetence I have a hard time believing that WebAuthn is some grand plot by Big Tech to lock people into their walled gardens.
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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.)
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.?
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.
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.
To present a passkey, you have to use a password manager. This provides some anti-phishing protection.
Passkeys are locked to a domain, enforced by the browser. This completely breaks phishing. That's why we're doing this song and dance in the first place! You can't read a passkey over the phone or use it on the wrong website.
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.
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
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
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.
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 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?
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?
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
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. Given how criminally insecure passwords and push/code based MFA are in the face of user incompetence I have a hard time believing that WebAuthn is some grand plot by Big Tech to lock people into their walled gardens.
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.
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.
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.
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.
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.
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.
Push notifications don't protect against realtime phishing attacks
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.
Yes but also depends on how the end system is configured.
You can require Google IDP to still have 2FA with passkeys.
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.
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
> 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.)
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.
how can I "use a good password that enforces origin binding"? Is this accomplished on the user side or by the provider?
>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.
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.
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.)
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.
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.
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…?
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.
Can I store a passkey on a YubiKey?
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
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.
A TPM is an HSM.
HSM can store a passkey that you optionally can use a touch + pin/password to unlock.
Not one that works across devices/browsers.
A Yubikey is a "device".
Passkey is literally a software emulation of a yubikey.
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.
"no."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.?
Just don't use that on windows with how they have broken most real hardware tokens with their bluetooth nonsense.
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.
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.
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-...
> To present a passkey, you have to use a password manager.
This is what makes passkeys nonstarters for me.
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.
> 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
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.
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.
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?
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?
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
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.
> unless you lose your whole Google account
I’ve seen enough horror stories here that this can’t be handwaved away.
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.
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 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?
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/
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.
There's also a FIDO standard in the works for how to export passkeys: https://blog.1password.com/fido-alliance-import-export-passk...
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.
I hope you are making a humorous understatement
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.
Except you can store the passwords on a usb key / remote over bluetooth, and then also keep them secret from the potentially compromised host.
The first passkeys were physical (USB) keys. And you never share the key with a host or server.
This article is pretty much all wrong.
Yes. So?
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?
Can we substitute "password" for all instances of "private key"?
Holy AI slop Batman!