Passkeys: They're not perfect but they're getting better
90 comments
·October 28, 2025ajnin
stavros
I've seen this argument many times, but I don't understand it. Can you explain a scenario where this would be an issue? So, Netflix makes me log in with a passkey that comes from their own hardware, instead of my password manager. What's the danger there, beyond the fact that this seems to me extremely unworkable because I'd just never sign in?
array_key_first
The danger is that you now can no longer use netflix without they're approved hardware? Of course, that's essentially already the case with netflix, but this becomes dicey when services that actually matter take this approach.
And then suddenly you're debanked.
stavros
No, we're talking about logins, not usage. Can someone explain to me a case where logging in only with an approved authenticator would be problematic?
nabla9
Losing your device and not having any passwords is like losing your fingerprints.
>Device loss scenarios
>Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
>Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
0cf8612b2e1e
Also requires the device allows backup of passkeys. The infamous post where keepass was threatened if they were to continue to allow users to backup their own keys.
spiffytech
I hadn't heard this story. Source: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
stavros
The person there requested that KeePassXC don't let users export their keys in plaintext, which seems reasonable. He asked that the software encrypt the keys with a user-selected password before exporting, so someone stealing the files wouldn't have the keys to literally all of the user's sites. That doesn't seem unreasonable to me.
burnte
Just not having the right device with you is crippling. IMO Passkeys need more work. I'd really like to see accounts support multiple passkeys. I'd prefer biometrics that are device independent. I just don't like the idea of replacing something someone can steal (a password) with something else someone can steal (a phone).
tzs
> I'd really like to see accounts support multiple passkeys
Most accounts seem to. Personally, I think I've only found one or two out of around 25 that I've added passkeys to that would not let me add more.
torstenvl
Would be nice, but biometrics have also been systematically made less secure. Apple, for example, no longer sells a phone with Touch ID.
foobazgt
At first I read this as "Apple doesn't implement Touch ID, because they found it to be insecure", which really confused me. Was that the intent?
On second reading, I'm thinking this might mean, "since Apple only implements Face ID, biometrics on Apple devices is less secure", which makes more sense (to me).
rstuart4133
For me, passkey's have made it when I can pay several different, independent providers to store them for me, and authorise the devices I can put them on.
To expand on that a bit, I don't have a problem with banks or whoever insisting they be stored securely. That means I don't have a problem win the inference that they don't trust me to store or even see my own keys.
What I do have a problem with is not being able to back them up. Which means I have a problem with Apple, Google or even Bitwarden handing me out a free they can take away at any time.
Fix that, so I can have store my identity(ies) at multiple providers, and I happy.
varbhat
I agree. I use Bitwarden on my Samsung Android phone and also on my Linux desktop. Bitwarden currently supports passkeys on almost all the apps on my android including firefox. The same passkeys which i used to login on my phone can be used on my Linux desktop where i use Firefox with Bitwarden extension. What's now possible was not even possible at the start of this year. I haven't switched everything to passkeys but i can see it as an alternative to passwords now(passwords really shines in some areas too).
I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
josephcsible
> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
Here's an Okta employee threatening to use the attestation (anti)feature of passkeys to block open-source implementations, because they allow you to export your passkeys: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
FreakLegion
Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.
josephcsible
The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
jauntywundrkind
Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC:
> The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like.
The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedbac...
Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608
gowld
> because they allow you to export your passkeys
because they allow you to export your passkeys in plaintext, for easy stealing.
"Information wants to be free" should not apply to passwords!
josephcsible
But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.
wbl
That's the whole point of this exercise. If export is possible it's not secure against local compromise in the way that's needed.
tzs
That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already.
For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.
josephcsible
The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
AlexandrB
Needed for whom? As others have said, without export it's a recipe for vendor lock-in.
abdullahkhalids
So the same passkey is being used on multiple devices, rather than different devices (actually applications) having distinct passkeys.
Doesn't that defeat one of the centrals aims of passkeys? In what ways is your setup different than random passwords in bitwarden - what's the additional security?
greenicon
Passkeys cannot be phished.
Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.
ianburrell
Another is that passkeys are single login and sites don’t use 2FA. Not having to get out TOTP or receive SMS is worth it.
Basically, any site that does 2FA should take passkeys.
temp0826
The password manager has become the device (and offers some assurance if the device is lost, as you can log into the manager on another device). I agree definitely isn't the original vision of passkeys (having a different passkey on every device, stored in separate password databases?), but it makes more sense for my cases.
djoldman
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
> Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
The benefit to the user of a passkey is that they don't have to remember passwords ("what you have" and not "what you know"). But if you lose what you have, you're screwed. There's no straightforward way to mitigate this.
Proposed solutions I've seen just add an extra layer of "what you know," but this just changes the security back to "what you know" if it supersedes the passkey.
commandersaki
Passkeys are a convenient second form of authentication that goes overlooked when accounts are hacked.
JohnFen
I'm glad that someone is at least seriously talking about these problems. A couple of them are serious enough to make passkeys a real pain in the butt for me. A big enough one that the whole scheme is a nonstarter.
g-clef
Until passkeys can pass the test of "my non-technical friends and family don't call me for help about them", passkeys aren't ready. Vendors keep making assumptions about how users behave which are not safe assumptions, and that keeps blowing up the interactions of non-technical users. (I'm sure there's an "assumptions developers make about user accounts" blog out there somewhere.)
For example, my family has had to call me for help on the interaction between passkeys on Apple & Amazon multiple times. They have a shared Amazon account, which neither Amazon nor Apple seem to like. The first problem came when they didn't even know they'd been moved to passkeys - there was a popup that one of them didn't understand, they clicked OK to get it to go away, and suddenly the other partner can't log in, and neither of them can figure out how to log into Prime Video on their AppleTV. Another time one of them got "nudged" to add a fingerprint to the account, again freezing out the other person.
Until that nonsense stops happening, Passkeys aren't ready.
stavros
By that metric, passwords are even less ready, as I seem to always have to field calls for passwords getting stolen or compromised or accounts getting phished. I guess we're back to faxing ID.
rekabis
I have a non-technical father with dementia, and passwords+TOTP are almost frictionless for him, with minor exceptions. We are able to share around passwords and TOTP codes without any problems so I can properly monitor his online activities to keep him out of trouble. He’s a cranky old guy with almost zero trust, so having to input all that stuff satisfies him that security is being employed.
Passcodes just freak him out.
stavros
I think Github is basically the only good passkey implementation right now. The ideal flow should be:
* Click login button
* Window pops up asking you which passkey you want to use, you click the one you want
* You're in
Anything on top of that is just added friction, and I haven't seen many sites get it right.
runningmike
“Passkeys are the future of authentication” …this is not the future I hope….When Google, Microsoft and a lot of other B*G-Tech companies promote Passkeys, you know it is not done to protect your security and privacy.
Nice read https://techrights.org/n/2025/05/02/Passkeys_Are_Vendor_Lock...
oldestofsports
So then I should store all my passkeys in a vault that I protect with a single password, how are passkeys safer?
etskinner
Let's assume your vault/login has these properties:
- You have a strong unlock password that you don't use anywhere else
- You have a second factor set up for unlocking the vault (TPM in the device you're using, Yubikey, TOTP, etc.)
- The service you're logging into has good account recovery hygeine
The benefit, assuming those things, is that the passkey is phishing-resistant and social-engineering-resistant. If a user gets an email saying "omg, someone tried to transfer your paypal, click this link to log in", then when they try to log in with the passkey, the site the attacker is using won't be able to use the passkey (because the passkey is associated with a particular domain). Even if the user wanted to bypass this, there's specifically no way for them to extract the contents of the passkey.
That is very different from a user having their password stored in their vault. They could easily forget to check the domain, or get tricked by a very similar looking one, and copy/paste their password into the attacker's form.
abdullahkhalids
My password manager (keepassxc) has a browser extension that only lets you autocomplete the password on a page if the url matches the one stored in the database.
Sure I could manually copy the password from the database, but in practice, this is fairly good security. It also doesn't treat the user as an always-idiot, which is a good thing in my book.
ewoodrich
I'm struggling to think of a reason why being "treated as an always-idiot" is an actual negative in this specific example.
I use Bitwarden and when the password autofill doesn't work as expected my first assumption from many previous experiences is that it's because a website changed something slightly in their auth flow or a particular page has a weird redirect/embedded login scheme different than the primary login, or similar "modern" web weirdness.
So if I get phished and let my guard down just that one time due to panic, sleep deprivation, or whatever else I'm glad that it gives me a second layer of defense against me reflexively clicking a couple times to copy/paste the password manually. A passkey dropdown with "No passkeys saved for this site" would be a massive red flag and stop me in my tracks before trying to do something else stupid.
skybrian
That works for you, but the website doesn't know you use a password manager, so they'll often want you to use SMS as a second factor.
Passkeys require some kind of password manager. That's the main benefit. The adoption problems are because a lot of users don't really understand password managers.
scratcheee
The article explains the weaknesses of the password-centric approach:
> whether by phishing or exploiting the fact the passwords are weak or have been reused
1. Phishing is harder when you only ever enter your password into 1 place, and that one place is designed to be secure and consistent.
2. Much easier to have exactly 1 strong password than unique strong passwords for every website.
Is it better than a vault full of random passwords? Probably not, beyond pressuring the user into using the more secure method
velcrovan
So your real issue here is with credential managers, but I'll bite. In most cases the vault is not protected only with your master password, but with other cryptographic info that prevents the vault from being opened on untrusted devices. If one of your trusted devices is compromised, I guess you have other issues.
AlexandrB
Uhhh, how does that interact with:
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
alexjm
From the article... Passkeys:
- are generated securely and so can’t be guessed - can’t be phished - are unique for each website you use, so if one website is compromised it doesn’t put your other logins at risk
AlexandrB
The better question is: how are passkeys safer given that the recovery flow will be the same SMS or email based approach everyone uses today?
sam_lowry_
How are passkeys different from API keys or just random chains of characters?
And why can't we have the use of such keys enforced by an EU legislation so that all businesses allow users to login using such strings of random characters?
The world would then be a better place.
MaxRegret
Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.
So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.
One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.
IcyWindows
Passkeys are a private key stored on your device with the public key registered with the server.
Servers should allow multiple passkeys per user (so you can register multiple devices), but many don't.
zzo38computer
X.509 already does that, and in a better way. It also makes it unnecessary to register multiple devices, if you allow certificate chains (the server would check the certificate chain; one of the was issued by the service and contains information about which account it is associated with; the other ones you can issue to yourself, optionally with more restricted permissions, and can be revoked or expire). That would also allow you to have passworded private keys, and/or to store one private key on a separate computer that is not connected to the internet to issue the other one to yourself in order to mitigate security issues (and you can revoke the certificate and make a new one if it is compromised or expires). X.509 also is not limited to only WWW, so it can be used with other protocols too.
sam_lowry_
That's an implementation detail users should not care about.
The bigger question is... why don't we replace the login/password combination with just a string of randomly generated characters and call it a day?
Why protect these strings of random characters from users, call them passkeys and advertise them on all street corners?
Feels like a devil's plot to strip us from all the rights to our devices.
joshuamorton
public/private keypairs (and therefore passkeys) provide cryptographically secure anti-phishing properties that passwords cannot.
dist-epoch
If you are not careful, you'll enter the random chains of characters into a phishing site.
But a phishing site can't steal your passkey and forward it to the real site, the passkey will just not work with the phishing site if you try using it there, it's locked to the authentic domain.
sam_lowry_
That's mumbo jumbo to me so far.
What's an authentic domain?
How is my passkey locked to it?
WesolyKubeczek
> How are passkeys different from API keys or just random chains of characters?
As far as I understand it, in the same way that a public/private keypair differs from a random chain of characters you are used to shoving into the "Authorization: Bearer XXXXXXX" header.
gowld
> How are passkeys different from API keys or just random chains of characters?
Passkeys are encrypyed so they can't be simply copied off your device.
sam_lowry_
So how are they better than API keys if I can not even backup them?
supportengineer
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
> websites which [...] also want to know how the passkey is being handled by the user’s device to keep their accounts safe
This is exactly where passkeys go too far. "to keep their accounts safe" is always the excuse used to reduce the freedoms of users. Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable. The boundary of control of a website used to stop at the interface between the site and the user. Now that boundary will extend to the devices. The idea of property and ownership is attacked again. The device is not something the user owns and has full control over but something that is a gateway to access content controlled by the big Internet companies.
Knowing this, how long until Netflix, Disney other content providers (sorry I don't know which ones are popular right now) demand use of a passkey originating form a device with a Trusted Platform (aka Untrusted User) Module ? This is part of a long plan initiated years ago with Windows TPM requirements, Microsoft account requirements. The gap between closed and open platforms will widen and the path is clearly to apply the Smartphone model where everything is closed, controlled, DRM'd, to other computers. We're lucky the IBM PC architecture was an open one but the war on that is on.