Comment by aeternum

> 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.

> (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.

> re-enroll attacker's key or register attacker's passkey

Can you walk me through how that would work?

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.

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.

>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)

> 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.

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.

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.)

> 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.

the non-mumbo-jumbo version is:

- you can't get phished

- you dont need to worry if your password is securely stored

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.

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.

> 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.

> 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.

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"

> 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.

This ^. It introduces MORE layers to phish. More external 'trust me'.

If your account is already not protected by passkeys (it has access to traditional username + password credentials), it can be phished regardless.. in those cases you just need to send them a traditional "reset password" phishing email.

The point is that those attacks would be (nearly) impossible if you have a truly passwordless system.

Yep, just look at the FBI alert of signal accounts being hacked. This is the same "vulnerability" that syncing passkey will have.

You know how to feed the site certificate into gpg before every login to check for url phishing attacks? I usually have to ask my password manager to do that (which didn’t exist 25 years ago)