Comment by MBCook
5 days ago
Bull. People need to stop repeating this.
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.
>They have to be transmitted.
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.
> 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).
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.
Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?
It seems like one of those things that only works if you're sticking to one ecosystem.
4 replies →
>Hardware Attestation solves this problem
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.
5 replies →
> (re-enroll attacker's key or register attacker's passkey).
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.)
>Everyone knows to hash passwords
got a good chuckle out of me. your optimism is inspiring.
Anyone not hashing passwords is going to find a way to mess up passkeys.
4 replies →
> re-enroll attacker's key or register attacker's passkey
Can you walk me through how that would work?
Probably something like this https://cybersecuritynews.com/hackers-abuse-microsoft-entra-...
11 replies →
You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.
Exactly! Whereas passwords are extremely flexible and can be stored, managed, and written down in numerous ways that are vendor-independent. Want to store your passwords on sticky notes in a safe? Go ahead! Want to use Bitwarden? Yep, you can. KeePass for offline storage? Yes! With good password hygiene (128-bit entropy, never reusing passwords) there is virtually no risk, especially with 2FA added.
You can (and should) do the same with passkeys. Like SSH keys, they're just text.
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 implementation, passwords are a complete disaster. We’ve been dealing with the fallout of it for decades.
In theory, if everyone did everything correctly and followed best practices, passwords would work quite well.
Reality shows we are not anywhere near there.
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
You 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.
>which objectively do exactly that
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)
So they do, in fact, do that and you have a workaround? They won't autofill on a phishing site, thus the copy/paste bypass.
It is a pretty big red-flag.
6 replies →
> Passkeys don't offer portability, user choice, or user control.
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.
You lose a device or the local DB that keeps your passkey and you are screwed.
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?
Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?
As far as I know, it has never happened. I know there was a presentation or two on bugs in individual password managers.
But that is not a flaw in passkeys. And there have been bugs in password managers that expose standard passwords as well.
> But that is not a flaw in passkeys.
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.
Can you provide details on this attack?
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.)
There are a lot of examples of attacks and bypasses, but this one is probably the worst I've seen so far https://www.techtimes.com/articles/323093/20260805/google-pa...
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...
> Passkeys can be, and have been, stolen and hijacked.
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.
Feel free to google for more:
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...
1 reply →
Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.
the non-mumbo-jumbo version is:
- you can't get phished
- you dont need to worry if your password is securely stored
And what if I need to use a different device?
4 replies →
> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.
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.
> They have to be transmitted.
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?
The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.
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.
>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.
3 replies →
> Bull. People need to stop repeating this.
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.
What are you talking about? Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
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.
That's not accurate. If that were true, then a hacker stealing password hashes would enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.
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.
>then a hacker stealing password hashes would enable them to instantly log in, without cracking them
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.
2 replies →
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
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.
Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.
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.
3 replies →
Correct. The hash effectively is the password at that point.
If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
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.
I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.
> Many sites have e-mailed my password in the open when I registered, as well.
A phpBB forum era classic!
2 replies →
This is incorrect implementation fyi.
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"
Hash the hash.
2 replies →
> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.
Don't assume everyone coding a login page is as competent as you though...sadly.
The mechanism proposed by the GP is not competence. It's a well-known vulnerability called "pass the hash".
But the sites where I actually care if my account gets compromised - Steam, FastMail, DigitalOcean etc. - are very unlikely to screw up password storage.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.