While the technology itself may be great (I don't really know since I don't use them) it has been co-opted by the tech conglomerates as another form of isolating and walling off users into their ecosystems.
And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny. One of those "if you see them running that way you run the opposite way".
Not as far as I’m aware? They of course require the target app to be compatible with the way they export them, but I don’t think they vet them manually. At the very least, on my phone, the apps it agrees to export to include Chrome and Bitwarden (the latter of which lets me export them further).
> And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny.
The reason is the ever increasing number of hijacks of social media presences and code hosting portals, with the latter being a serious financial threat. Done right, passkeys stay in the Secure Enclave, at least for anything Apple and most of the Android sphere. There is no reasonable way to obtain login credentials for accounts protected by passkeys without physical access to the user's device(s).
Fun fact: Google can decide to reject these. Lose access to the original device, try to rely on recovery codes to login with known current password on family member’s device… nope!
I guarantee you this is within the realm of possibility based on one single experience.
When you upgrade your phone perhaps keep your old one in a safe and charge it and login to Gmail monthly or something?
I’m also quite certain the codes could work instantly with no trouble in some circumstances. Now know it’s risky though. And I’m sure it’s a security measure based on real, deeply painful and costly instances of unauthorized access. Just don’t know what we’re exactly supposed to do…
Google gives you no guarantee of service for your account. They could arbitrarily decide to lock you out for any reason and you have literally no recourse.
The doubt is more "how will tech companies use passkeys as an excuse to do something stupid" than "passkeys themselves must have inherent problems because tech companies are pushing them".
Passkeys could be the savior of all security problems worldwide from a capability point of view and tech companies would still ruin it by trying to force ways it pushes you into their ecosystem instead of just being whats both secure and convenient.
As an example, I have 3 different passkey _APPS_ on my phone and cannot go down to one because of various reasons with each (such as MS authenticator, forced for integrating to Microsoft at work).
My yubikeys have survived dips in the ocean, spilled beers, run over by cars, dropped in pans of used motor oil, and multiple trips through the washer and dryer. They're still fine even after a decade.
Physical keys can easily be copied, and physical locks can easily be picked. That might be fine for your house or storage unit, but for your bank account or your car (newer cars no longer have simple physical keys/locks), we've moved beyond that tech.
That any and all physical security measures can be defeated is a feature, not a bug. Almost no human beings actually need that level of security, and the tradeoffs are absolutely not worth it for those of us without Mossad as a threat.
How often do people lock themselves out of their own house? Don't you know anyone with ADHD? Imagine any time that happens it is mathematically verifiably permanent as a fact of reality itself. It doesn't matter that the state still views you as the legal owner, you are never allowed in ever again.
Now we aren't talking about a security problem, we're talking about who really owns what. Google can lock you out of your account no matter what kind of authentication they use for that account
I'm not even sure what your point is anymore. If Google decides they don't want you to log in anymore, you can't log in anymore. It doesn't matter if you try to log in with a passkey, a password, your fingerprint, or sending a secret code in with carrier pidgeon. This has nothing to do with passkeys vs passwords vs anything else.
If Google does want you to be able to log in then they will work with you to make that happen, whether you forgot your password, lost your passkey, or your carrier pidgeon died.
Passkeys are not special in this regard at all. What does make them special is that nobody can use a phishing attack to steal your passkey and log in to your account. Nobody can guess your passkey and log into your account. Nobody can intercept your passkey in flight and log in as you. That's the important distinction.
That's not the problem for me - I carry a bunch of tokens with me anyway (all my banking stuff is on hardware tokens, for example). My problem is more: My browsers run in containers or VMs, intentionally without hardware access. Getting passkeys to work there would be quite a bit of effort.
I can write my own authenticator implementation in a few hours by hand, maybe 5 minutes vibe coded. <a href="https://www.rfc-editor.org/info/rfc6238/" rel="nofollow">https://www.rfc-editor.org/info/rfc6238/
Even if you throw your phone into a volcano and buy a new one, you can still receive SMS verification.
Passwords can move between walled gardens generally very easily (export) or manually in all cases (enter by hand).
Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.
As much as I hate to admit it (because I love passkeys UX), but I do think that device-bound/attested passkeys are going to happen in the future :(
but what do passkeys offer in terms of security, when stored in password managers, compared to having a (password manager) generated password and a totp?
I believe that by allowing password managers to store passkeys, the whole purpose of "device based security" got lost..
Yes. I use hardware based passkeys and absolutely love them. I think it was a giant mistake having them 'software' based. It some ways it kind of defeats the entire purpose...
They are 100% immune to credentials phishing. You literally cannot authenticate to an impersonator site based on cryptographic guarantees.
And yes, I know the happy path of password managers uses host-based autofill which does add some friction to phishing attempts, but given the prevalence of unexpected but legitimate urls with weird alternate subdomains/SSO/redirects in modern login flows, you have to manually autofill/add an exception often enough that it's possible to let your guard down once at the wrong time.
I did a deep dive on this since progressively more places are taking a hard line about Passkeys.
The most flexible, independence preserving thing to do is to use a third party password manager like Bitwarden, and make that the default passkey flow for your devices. If desired, you can self-host something like Vaultwarden so that you can both keep the keys independent of third parties and walled gardens and also propagate them to other client devices.
To be clear I'd much rather not have learned / implemented any of this, and I don't use passkeys unless forced, but this seems like a valid coping strategy.
elteto · · focus · HN ↗
And honestly, nowadays, if tech companies are pushing really hard for something then that is an immediate red flag for me and it bears more scrutiny. One of those "if you see them running that way you run the opposite way".
spider-mario · · focus · HN ↗
rcxdude · · focus · HN ↗
dingaling · · focus · HN ↗
93po · · focus · HN ↗
spider-mario · · focus · HN ↗
mschuster91 · · focus · HN ↗
The reason is the ever increasing number of hijacks of social media presences and code hosting portals, with the latter being a serious financial threat. Done right, passkeys stay in the Secure Enclave, at least for anything Apple and most of the Android sphere. There is no reasonable way to obtain login credentials for accounts protected by passkeys without physical access to the user's device(s).
iso1631 · · focus · HN ↗
Click "I lost my device", enter contact, get a reset link via email/sms
[deleted] · · focus · HN ↗
[deleted]
terminalbraid · · focus · HN ↗
jmbwell · · focus · HN ↗
I’d buy that there are too many different confusing ways to recover from this situation, but not that it’s impossible
Barbing · · focus · HN ↗
Fun fact: Google can decide to reject these. Lose access to the original device, try to rely on recovery codes to login with known current password on family member’s device… nope!
hobo123 · · focus · HN ↗
Barbing · · focus · HN ↗
When you upgrade your phone perhaps keep your old one in a safe and charge it and login to Gmail monthly or something?
I’m also quite certain the codes could work instantly with no trouble in some circumstances. Now know it’s risky though. And I’m sure it’s a security measure based on real, deeply painful and costly instances of unauthorized access. Just don’t know what we’re exactly supposed to do…
terminalbraid · · focus · HN ↗
iso1631 · · focus · HN ↗
gong_hits · · focus · HN ↗
[dead]
zamadatix · · focus · HN ↗
Passkeys could be the savior of all security problems worldwide from a capability point of view and tech companies would still ruin it by trying to force ways it pushes you into their ecosystem instead of just being whats both secure and convenient.
As an example, I have 3 different passkey _APPS_ on my phone and cannot go down to one because of various reasons with each (such as MS authenticator, forced for integrating to Microsoft at work).
reddalo · · focus · HN ↗
Passwords with 2FA are simply better and more freedom friendly.
apexalpha · · focus · HN ↗
reddalo · · focus · HN ↗
SoftTalker · · focus · HN ↗
vel0city · · focus · HN ↗
hnfong · · focus · HN ↗
apexalpha · · focus · HN ↗
Though realistically I use a passkey for services I care about and a password manager for the rest.
eikenberry · · focus · HN ↗
jazzyjackson · · focus · HN ↗
eikenberry · · focus · HN ↗
krupan · · focus · HN ↗
mrguyorama · · focus · HN ↗
How often do people lock themselves out of their own house? Don't you know anyone with ADHD? Imagine any time that happens it is mathematically verifiably permanent as a fact of reality itself. It doesn't matter that the state still views you as the legal owner, you are never allowed in ever again.
krupan · · focus · HN ↗
EvanAnderson · · focus · HN ↗
Telaneo · · focus · HN ↗
krupan · · focus · HN ↗
Telaneo · · focus · HN ↗
krupan · · focus · HN ↗
Telaneo · · focus · HN ↗
krupan · · focus · HN ↗
If Google does want you to be able to log in then they will work with you to make that happen, whether you forgot your password, lost your passkey, or your carrier pidgeon died.
Passkeys are not special in this regard at all. What does make them special is that nobody can use a phishing attack to steal your passkey and log in to your account. Nobody can guess your passkey and log into your account. Nobody can intercept your passkey in flight and log in as you. That's the important distinction.
apexalpha · · focus · HN ↗
finaard · · focus · HN ↗
jwcrux · · focus · HN ↗
dsl · · focus · HN ↗
Even if you throw your phone into a volcano and buy a new one, you can still receive SMS verification.
qlte · · focus · HN ↗
Groxx · · focus · HN ↗
Passkeys only very recently got relatively broad support for migrating data (after years of promise and no support at all), and they report (optionally with hardware attestation) what password manager you're using so sites can force specific ones.
Shank · · focus · HN ↗
EvanAnderson · · focus · HN ↗
nbobko · · focus · HN ↗
Shank · · focus · HN ↗
tonoto · · focus · HN ↗
I believe that by allowing password managers to store passkeys, the whole purpose of "device based security" got lost..
flumpcakes · · focus · HN ↗
qlte · · focus · HN ↗
And yes, I know the happy path of password managers uses host-based autofill which does add some friction to phishing attempts, but given the prevalence of unexpected but legitimate urls with weird alternate subdomains/SSO/redirects in modern login flows, you have to manually autofill/add an exception often enough that it's possible to let your guard down once at the wrong time.
alibrarydweller · · focus · HN ↗
The most flexible, independence preserving thing to do is to use a third party password manager like Bitwarden, and make that the default passkey flow for your devices. If desired, you can self-host something like Vaultwarden so that you can both keep the keys independent of third parties and walled gardens and also propagate them to other client devices.
To be clear I'd much rather not have learned / implemented any of this, and I don't use passkeys unless forced, but this seems like a valid coping strategy.