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

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