What do passkeys offer users that rand strong password + password managers don't?
They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
Save a passkey in Bitwarden, then export your vault as JSON. You'll see a nice plain text JSON block with your passkey that you can print, or backup, or import into whatever replaces Bitwarden.
In theory, if everyone did everything correctly and followed best practices, passwords would work quite well.
Reality shows we are not anywhere near there.
- you can't get phished
- you dont need to worry if your password is securely stored
- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.
The way passkeys are being pushed is so clearly an attempt to add friction to leaving walled gardens. Stop talking in absolutes in a world of greys.
Don't assume everyone coding a login page is as competent as you though...sadly.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.
While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.
Many sites have e-mailed my password in the open when I registered, as well.
I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.
A phpBB forum era classic!
Unless I'm misunderstanding what you're doing, this achieves nothing.
Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.
If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.
If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).
MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.
I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.
Here is my hashed password. Good luck:
$argon2id$v=19$m=65536,t=3,p=1$YTE4NzBkMDIwMjRhMGY5NzU4OTc2ZWY5YzI0N2RjOTY$GSBlUwWxr4BBs+5o5Ye2NphT9PFeWx4ECG6siED9uVQ
If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.
Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.
Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.
How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.
Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.
You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.
If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.
The name of this vulnerability is "pass the hash"
Client:
C = SHA256(password)
Server:
V = Argon2id(C, server_salt)
Database:
stores V and server_saltYou replied to someone talking about password managers, which objectively do exactly that.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
And Passkeys don't offer portability, user choice, or user control.
Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.
password managers do not do that. open up your password manager, press "copy" on the password, and then paste it into a random website. it will paste it.
(i think 1password just recently enabled an option that will warn you if the website is different than the one it has, but it still lets you paste it)
It is a pretty big red-flag.
right. and in an office setting, bob in accounting will go "weird, autofill isnt working, ill copy/paste it".
that is not a possibility with a passkey.
This is where Passkeys shine, in an edge-case user that is neither of the two most common user types. Basically a unicorn situation.
you must not work in regular corporate environments. this happens all the time.
yes, they know how to hit the big "copy" button but don't know how to debug an extension.
take a year or two to work security (or general IT support) in a non-tech-company corporate environment, and get ready to have your socks blown off. people become exceptionally literate with things they interact with all day (excel is great example of this) yet have no idea that google.example.com isn't an official google website.
Copy and paste is not a skill that requires much technical literacy. I've not seen a Password Manager that makes the copy button hidden or hard to find or need much technical skill to use.
Many "legitimate" websites, especially corporate "SSO", accidentally train users that autofill just doesn't work some of the time. Example Corporation's SSO configuration generally has users put their password into auth.example.com, except when the app in question is using some weird SAML flow and accidentally ends up at saml.example.com or auth.okta.com. An old legacy internal app still needs the password inputted in an HTML Basic Auth prompt due to a redirect through oldauth.example.com. The user learns to just copy and paste and have no idea why autofill works on some internal apps and not others because they have no idea what SAML is or why a legacy app is special/different from modern ones.
It happens on the public web, too, to a lesser extent. A website goes through a "rearranging deck chairs phase" and can't decide if id.example.com is cooler than auth.example.com or if they should just put login only on top level example.com and flip back and forth over a few weeks as different internal teams "win" or various A/B tests run.
You can not use a passkey on the wrong site. Period. They’re unphishable.
Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.
That’s absolutely not true with a password manager. They may TRY to prevent you from ACCIDENTALLY entering it on a website, but they don’t stop you.
So you're telling me they're phishable?
This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.
All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.
Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.
Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.
Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.
>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).
>If your entire database is stolen, it’s useless.
As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.
got a good chuckle out of me. your optimism is inspiring.
I'm sure that there are big enough fools out there, I'm just thinking there might be signs they are doing something wrong in that case.
Can you walk me through how that would work?
Attacks on passkeys have been because of flaws in the OS, or the browser, or the password manager, but none of those things are going away any time soon. Passkeys depend on those things, which means they aren't are solution to the problem of phishing. They just make phishing harder.
Passkeys also make things harder for the legitimate user though, and there's a very real question of whether the protection they offer is worth the trouble.
It’s not a new vulnerability. It’s not a reason to roll out Passkeys unless it’s also a reason to get rid of passwords.
With Passkeys you’re still net ahead.
> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.
The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.
That's wrong. They attackers actually go on to create a real passkey that gives their device access to the compromised account.
Accounts that are already protected by passkeys can still be vulnerable too. see:
https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...
https://www.esentire.com/blog/securing-passkeys-thwarting-au...
https://unit42.paloaltonetworks.com/passwordless-authenticat...
The other articles you've linked also describe attacks against accounts that allow non-passkey logins, or attacks that require a compromised browser.
The point is that passkeys significantly reduce the attack surface.
In any case, if you can get the user on the phone and convince them to let you walk them through a bespoke auth flow, I doubt there is any auth mechanism that would stop this. This is why every auth system these days is constantly telling you "We'll never ask for X", because at that point, the game is over.
Exactly. Passkeys can't solve the problem of phishing. At best it only makes it more difficult. Phishing is less of a concern to me personally than losing my access to my account because of the complexity and fragility of passkeys. I've read enough horror stories, even from very capable people, about people who were screwed because they thought they were doing the right thing by setting up passkeys. Passkeys sound like they might be great for many other people. My vulnerability to phishing doesn't justify the risk of passkeys.
This is only technically true because of the definition of what a passkey is is vague.
Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.
When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.
So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.
This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will leverage your weakest enrollment option.
Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.
> which enclaves/sources/devices do you support vs. not support?
You support all of them and prefer the strongest configuration for the source available.
If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.
If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.
Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.
So you allow it, then oops it was not a laptop, it was a phishing site.
That's not the argument being made.
The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.
So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.
Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.
Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.
Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.
TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.
Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.
That method still works just fine with passkeys right?
The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.
If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.
> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.
Yep and passkeys explicitly exist to eliminate this behavior.
> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.
Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.
Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.
TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.
It seems like one of those things that only works if you're sticking to one ecosystem.
If the developer fucks up the website/app, that is their fault and not a failure of the technology.
Respectfully, you should consider reconsidering this mindset. The best engineers and tech designs take into account not only how users will use a technology but also how they will misuse it.
What is the mechanism to do this? As I understand it, the passkey is basically a public/private key pair. You'd have to download the attacker's key pair into your passkey system? What passkey system allows you to provide a key pair, rather than always generating one? I'd like to see a step-by-step walkthrough that doesn't involve a straightforward phishing scenario, or running privileged commands on the users computer (if you can do that, all bets are off.)
What do you image happens with passkeys?
> They (or their hash) have to be stored.
What do you image happens with passkeys?
> If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
From the consumer, do you imagine a hacker has my key to unlock my password database?
From a service provider, do you imagine they are not using encryption at rest?
> Cryptography is the solution in passkeys are the implementation.
Do you imagine cryptography is not used with passwords?
And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.
Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.
The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.
All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.
If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.
Proof needed.
> How many phishing emails h
The point is the average Joe will not be phished - especially important stuff - like email or eBay or bank. That is the reason for passkey.
Yes, many people in HN can avoid scammers.
https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...
https://www.howtogeek.com/passkeys-were-supposed-to-be-more-...
https://www.malwarebytes.com/blog/news/2026/08/googles-synch...
https://cybernews.com/security/google-passkeys-vulnerability...
https://cybersecuritynews.com/passkeys-via-aitm-phishing-att...
https://www.zdnet.com/article/your-passkeys-could-be-vulnera...
Typically the user gives a website their public passkey, which does not need to be kept secret since it’s public. If the website is hacked the attackers only get information that is already public.
You seem to be talking about a scenario where a user’s private keychain on their computer is compromised and the attacker is able to access other systems from that same machine without the user’s knowledge. (Note that the keychain data is itself encrypted so can’t be used from a different computer.)
It's not just the end user that you have to worry about, attacks are helped by the fact that websites suck at passkeys too
"...we developed PASSKEYS-ATTACKER. The tool allows for precise manipulation of WebAuthn messages at every step of the protocol and integrates 15 attack types of which 10 were not covered in previous work. Among them, 2 attack types have critical CVSS scores. We discovered them on 18 out of 103 evaluated websites. These attacks take over user accounts, delete their passkeys, or lock them out of their accounts. Nearly half of the tested sites (53) were vulnerable to at least one attack with a high CVSS score, exposing users to threats such as phishing and session fixation." https://www.usenix.org/conference/usenixsecurity26/presentat...
But that is not a flaw in passkeys. And there have been bugs in password managers that expose standard passwords as well.
By that reasoning passwords are 100% secure too, it's the human's fault when they fall for phishing sites! Passkeys depend on humans, password managers, devices, certificate authorities, browsers, and operating systems. That's not even including the implementation itself (https://www.esentire.com/blog/securing-passkeys-thwarting-au...)
All of this means that even when you're using a passkey an attacker could still break into your accounts. Passkeys can make it harder for them, but it can make it harder for you to get access to your accounts too. For me, I don't think the risk of phishing is worth the trouble passkeys would cause me.
You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.
Your password might not be stored anywhere except in your head.
Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).
"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.
My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?
Wow, you sound like you know what you're talking about.
> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
Ok, you've stopped sounding like you know what you're talking about.
Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.
> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.
> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Unique strong passwords offer the following:
1(a). They are never transmitted (well, once), and provide phishing resistance; or
1(b). They are never stored, and provide leak resistance.
2. In the event of compromise, no other credentials of yours are simultaneously compromised.
It's true that it would be nice to enjoy phishing resistance and leak resistance.
Here are some other things unique strong passwords offer:
3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.
4. Yubico can't pretend to be you.
You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.
> Passwords are fundamentally broken. They cannot be fixed.
This is the "PGP is fundamentally broken" argument again. It will never be valid.
If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.
Don't use Outlook plugins. Run PGP yourself.
Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.
If you were about to send the email, but it's still in plaintext, don't send it.
Passwords are no more fundamentally broken than PGP is.
Replying only to this part, using a password manager with autofill solves this problem. The password manager (I use Bitwarden, but there are others) can check the site you're trying to log in to, and only autofill passwords that are for that site. I don't have to do any work to differentiate example.com from thisisexample.com, because Bitwarden will only show me the example.com password.
The point is that those attacks would be (nearly) impossible if you have a truly passwordless system.
So if you get sent to goog1e.com, your password manager won't prompt you to enter your Google passwords. Though of course, you could still manually paste it in if you got somehow convinced that it's a legit site.
But in my opinion, the solutions that passkeys provide come with the costs that are being discussed here, and I haven't found the trade-off worthwhile.
Wrong question.
Users don't use good passwords or even password managers. Users reuse passwords.