[javawizard]

The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it.

That's the benefit you get from passkeys that no password manager will otherwise be able to give you.

[masklinn]

If your TLS connection has been MITM’d, you have much bigger problems than your unique randomly generated password being sniffed out.

[thinkharderdev]

It is not required that your connection has been MITM'd. The service you are authenticating can accidentally log the plaintext password, they can store it with an insufficiently secure hash function or not salt it. A malicious browser extension can scrape it directly from the input form. Etc, etc, etc.

Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.

[aragilar]

If the service is like that, then I'm not sure being able to log in as you is a major issue...

[hal0x2328]

It's very easy to fall prey to an Evilginx or similar AITM phishing attack. Passkeys or TLS client certificates are the only guaranteed defense. Relying on the user noticing the different domain or the lack of autofill by the password manager, not so much.

[knallfrosch]

If they control the information flow can't they simply steal the passkey too?

[tzs]

No, because they never see anything that needs to be kept secret.

Passwords are based on symmetric cryptography. When you log in to a site using a password you give the site your password in plain text, hopefully over an encrypted communication channel such as HTTPS so that no one between you and the site can see the password.

The site then takes that plain text password and decides if it matches the plain text password you gave them when you created the account or most recently changed your password. If the site is following good security practices they aren't actually storing a copy of the password in plain text. They will store a hash of it and compare a hash of the password you just send to see if the hashes match.

Passkeys are based on asymmetric cryptography, also known as public-key cryptography. When you set up an account at a site to use passkeys your device generates a public key and a matching private key. The site is given the public key and your device keeps the private key.

When you want to log in later the site sends your device some data, your device does a computation on that data that involves the private key and sends the result to the site. The site can recognize that whatever did that computation had access to the private key that corresponds to the public key the site has on file.

[manicdee]

The attacker could pretend to be the service the user is trying to authenticate to, issue a bogus challenge signed with the user's public key. That will allow intercepting the user's interactions but by this time the attacker has control over the target system so why not just take what is inside rather than go to the effort of interacting with the user?

[javawizard]

Nope.

Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.

At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.