I didn’t test it (of course), but I think they do for this case.
So we have a man in the middle attack, that proxies traffic to a website through it and just decrypts it without changing it during the login. This is similar to what cloudflare does. The browser has no way to know somebody is spying: HTTPS cerificate is ok(stolen cert), the domain matches the expected(dns poisoning), even the page is exactly the same, so it performs the passkey challenge/response. The only thing that changed is the certificate, which is not suspicious (certificates can change normally!).
The attacker is not able to clone the passkey, but they are able though to steal your session cookies after the login. Instead of giving you the “login success page” they keep you waiting on a loading page while they navigate (with a script) with your stolen session cookies to the “add passkey” page of the site to add theirs.
If the website asks them again for the passkey as confirmation, instead of serving the “login successful page”, they serve the new 2FA prompt to you.
You are left wondering “Didn’t I just do the 2FA? What a buggy site!”. And unknowingly approve adding the attacker’s passkey.
Game over, account fully compromised.
We are lucky that HTTPs is very good for security, they revoke certificates very quickly if this happens, and browsers check the certificate transparency logs making it impossible to forge a new certificate, even if you got hold of a root certificate with private key “4”.
This attack also needs unrealistic level of compromise: stolen and unrevoked certificate + a poisoned DNS. Completely unrealistic scenario, but it’s not passkeys that saved you, it was HTTPS.
When they say passkeys are unphisheable they mean you can’t usually copy them and give them to an attacker, but an attacker can absolutely still add theirs to your account.
I didn’t test it (of course), but I think they do for this case.
So we have a man in the middle attack, that proxies traffic to a website through it and just decrypts it without changing it during the login. This is similar to what cloudflare does. The browser has no way to know somebody is spying: HTTPS cerificate is ok(stolen cert), the domain matches the expected(dns poisoning), even the page is exactly the same, so it performs the passkey challenge/response. The only thing that changed is the certificate, which is not suspicious (certificates can change normally!).
The attacker is not able to clone the passkey, but they are able though to steal your session cookies after the login. Instead of giving you the “login success page” they keep you waiting on a loading page while they navigate (with a script) with your stolen session cookies to the “add passkey” page of the site to add theirs.
If the website asks them again for the passkey as confirmation, instead of serving the “login successful page”, they serve the new 2FA prompt to you. You are left wondering “Didn’t I just do the 2FA? What a buggy site!”. And unknowingly approve adding the attacker’s passkey.
Game over, account fully compromised.
We are lucky that HTTPs is very good for security, they revoke certificates very quickly if this happens, and browsers check the certificate transparency logs making it impossible to forge a new certificate, even if you got hold of a root certificate with private key “4”. This attack also needs unrealistic level of compromise: stolen and unrevoked certificate + a poisoned DNS. Completely unrealistic scenario, but it’s not passkeys that saved you, it was HTTPS.
When they say passkeys are unphisheable they mean you can’t usually copy them and give them to an attacker, but an attacker can absolutely still add theirs to your account.