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.
Of course they'll happily justify it with security reasons, but that doesn't remove the problem.
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.
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.
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.
Thought sites can request hardware attested passkeys? In this case usb keyfob, or passkeys instanced from a secure enclave, etc.?
This was briefly possible with WebUSB, but all mainstream browser vendors have a stoplist of certain USB devices for security reasons.
With this comes a new problem: how do you reset it?
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.
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.
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.
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 struggling to see what the issue is.
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.
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.
> 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.
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.
It is nice to just have a one click login for things.
You can require Google IDP to still have 2FA with passkeys.
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.
Sure. Provide an escape hatch for the technically literate and let us use our ssh-agent then.
Bitwarden even now supports passkeys on mobile browsers and apps. As a happy user for over 5 years it's been great being able to configure something less theatrical than push/codes without needing to plug in my YubiKey every time.
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
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 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.
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.)
- in the typical mundane case, its prescriptive about a PIN with the well-known bad outcomes on that
- in the limit case, a bad guy who has already demonstrated a willingness to steal your credential now needs to threaten harm to get what he wants
There's a reason bank tellers can't open the vault and a reason everyone knows that.
Physical custody (U2F) is intuitive, maps extremely well onto existing infrastructure (everyone has keys for their car and home), scalable in security (safes are common, well understood, and can be made arbitrarily secure).
So by the time you're at FIDO2 / demand a pin? Already user hostile. Strictly lockout increasing, strictly violence incentivizing.
Moving right along, Webauthn could mandate trivial portability as a QR code, TOTP style seed, a zillion ways. Nope: vendor lock in battle (FireFox overlays its password thing on the same pixrls that the Proton or BitWarden one does that I turned on!).
None of this is about security, none of it is about safety, none of it is about welfare.
It's about money.
Guess what their password was: solarwinds123
So yes, I am in favor of passkeys everywhere because humans are bad at realizing their operational risks when they start creating an account and haven't even used it yet.
Without password managers, humans tend to reuse their passwords, which makes one breach a breach of all accounts. Humans are also bad at remembering passwords, so time based recreation of passwords will always lead to the month or week or iteration as a suffix.
And that's the actual problem that can be prevented with passkeys (or MFA that is not based on sending SMS or emails which are unencrypted as a transport channel).
But I agree with the author's implied sentiment: export/import should work between password managers and be required by law, because currently Microsoft's authenticator workflow is pretty useless if you can reset the passkeys via email ownership anyways.
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.
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?
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.
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-...
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.
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 these 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.
JohnFen•9h ago
This is what makes passkeys nonstarters for me.
aldshglkhdg•6h ago
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.
blindriver•2h ago
dfedbeef•2h ago
int_19h•1h ago
chipsrafferty•1h ago
blindriver•1h ago
chipsrafferty•1h ago
blindriver•1h ago
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?
dylan604•2h ago
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
XorNot•2h ago
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.
dylan604•2h ago
porridgeraisin•2h ago
Gigachad•2h ago
dylan604•1h ago
qwerpy•1h ago
I’ve seen enough horror stories here that this can’t be handwaved away.
chipsrafferty•1h ago
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.
eviks•56m ago
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