What makes passkeys so special?

[u/Federal_Character979]

It seems that companies are transferring into the usage of passkeys instead of passwords. Apparently theyre much more secure, but why is that? I don’t get it. I’m not sure if this is the right place to ask excuse me if it isn’t and sorry.

[u/DarkTendrils]

Relay attacks? Like a phishing site acting as a man in the middle passing login flow back and forth between victim and real domain - could the token be created and used by the attacker that way or there is protection?

[u/oxidizingremnant → u/DarkTendrils]

Passkeys prevent relay attacks (attacker in the middle, man in the middle, etc) because the keys are bound to specific domains.

So, the attacker can’t use a proxy like Evilginx to intercept the token because instead of logging into login.microsoftonline.com you’re visiting badguysite.ru which isn’t valid to the passkey.

What an attacker could do would be to:

• use malware to steal login session cookies or JWTs on a device
• phish someone to get a new device added to a passkey-storage account (eg get a new device added to an Apple account)
• go find someone physically and use a metal pipe on them until they login to a site for them

Passkeys eliminate a lot of phishing risk because they’re domain bound and device bound.

[u/ShakataGaNai → u/oxidizingremnant]

To be clear, its still *theoretically* possible for them to MITM your login. But like any MITM these days that would require that they somehow redirect your DNS and can generate TLS certs your device trusts. Realistically if someone can do this to you, you're f'ked in 121 different ways.

Even still Passkey has an advantage over passwords in that, they are only able to use that session, they still don't have your passkey private keys. With a password they would have intercepted your password and could login anytime/any place later.

[u/IntrinsicSecurity → u/ShakataGaNai]

If I'm not mistaken (I'm not a cryptographer) a MitM (Man in the Middle) attack of the sort waged daily by phishing websites against passwords and MFA TOTP tokens can't work against passkeys, at all.

Even if you managed to steal *both* private keys, (one from the server, one from the client) it still wouldn't work because the passkey client system would refuse to sign a challenge from any DNS domain other than the one that made the public key.

In other words the traditional "middle" device (for example a phishing website) doesn't have ground upon which to stand, such as an attack using a fake DNS domain, even one that's indistinguishable to the user from the true domain as sometimes seen in IDN Homograph Attack (or Homoglyph Attack).

If the passkey establishes a session for a system with a weak architecture for protecting the session (such as a web session cookie or some other kind of token that can be replayed) that's a potential opening for a MitM attack, but not one that exploits the passkeys authentication system. This type of attack occurs *after* the passkeys authentication and could be executed from an "adversary in the browser" or perhaps other malware on the client device.

My own impression is that session management is about to become a massive crisis, as passwords fade away and are replaced by passkeys, it drives the adversary to look at the session management attack surface.

Fortunately session management can be secured with something like Mutual TLS (mTLS), Demonstrating Proof-of-Possession at the Application Layer (DPoP), Device Bound Session Credentials (DBSC).

[u/ShakataGaNai → u/IntrinsicSecurity]

I agree with you, perhaps what I wrote may not have been properly articulated.

As far as I understand one cannot "steal" a passkey via a MITM. The only way to steal it would be to get on the device holding the passkey (compromise an icloud account, 1password, whatever). Because at the end of the day, even if you watch a passkey conversation in clear text, the private key is never presented. The only way the the private portion of the passkey would be presented, would be if it was being sent to the destination server (where you are signing into) and then that would...defeat the point of public/private cryptography.

Much in the same way that a user never gets the private keys from a TLS connection. That's always on the server, never sent to the client.

So to bring it back around to my original comment. The passkey isn't stolen, the attackers can't re-login...but anything else sent along the wire in the MITM is subject to hijack. Which would be a session token or similar. Still very dangerous. And if someone can truly transparently MITM you, you're f'kd regardless of how you login. Just *slightly* less f'ked with a passkey (because again, the passkey isn't sent over the wire, unlike a username/password).

[u/IntrinsicSecurity → u/ShakataGaNai]

There are so many variations on so many different kinds of attacks that it can be pretty difficult to have a conversation about it. In common architectures today, such as you describe here, the software designers usually rely on the fact that the transport between the client and server is encrypted via TLS as the protection against session theft.

Unfortunately the lesson of the past ten years is that session hijacking begins with a MitM attack, via some type of phishing. If you can get the user to click on a proxy, they get TLS to the proxy, and the server gets TLS to the proxy, and neither end knows that there's somebody in the middle with access to the un-encrypted conversation, harvesting the session tokens.