Once they are at the level where they break HTTPS, they can also ask you for the 2FA code or passkey and intercept that through their services, and you’d be hacked anyway.
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.
That’s tickling a part of my recollection, but I could be crossing wires.
I could have sworn webauthn had a component where the server also signed a challenge for proof of possession of their key.
There’s also the component where the server can assert that the device is of a certain type, from a certain providence, in a way that’s a lot harder to fake. Anyone worth their salt would also notice that the users IP address had gone very weird, and in fact all the addresses for every customer had gone weird and identical (automatically, since no one’s checking that obviously).
You’re still fundamentally correct, but it’s worth underscoring how massively you’d have needed to own their infrastructure for the passkeys to be compromised. :)
Some time ago I was browsing less credible part of the internet and got a Cloudflare pop-up asking me to check the captcha tick box. So I did. Then it asked me to verify the check by pasting a command into powershell. Wonder how many people fell for that one
There are plenty of ways.
DNS poisoning with one of those #4 private keys would be the easiest.
Getting Grandma to add a trusted CA would be another.
Paste bombs into browser terminals.
Something you have is a very important part of keeping people out of your stuff.
Once they are at the level where they break HTTPS, they can also ask you for the 2FA code or passkey and intercept that through their services, and you’d be hacked anyway.
Passkeys don’t work like that. They would, in fact, stop that from happening.
That is of course if the company didn’t let you choose another method
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.
That’s tickling a part of my recollection, but I could be crossing wires.
I could have sworn webauthn had a component where the server also signed a challenge for proof of possession of their key.
There’s also the component where the server can assert that the device is of a certain type, from a certain providence, in a way that’s a lot harder to fake. Anyone worth their salt would also notice that the users IP address had gone very weird, and in fact all the addresses for every customer had gone weird and identical (automatically, since no one’s checking that obviously).
You’re still fundamentally correct, but it’s worth underscoring how massively you’d have needed to own their infrastructure for the passkeys to be compromised. :)
I wasn’t aware they dropped WebAuthN, it was RIGHT THERE… but you’re right.
it’s still a lot easier to get someone to 2FA over the phone and tell them their password manager is flakey, but I def concede
Damn, that’s awful news
Some time ago I was browsing less credible part of the internet and got a Cloudflare pop-up asking me to check the captcha tick box. So I did. Then it asked me to verify the check by pasting a command into powershell. Wonder how many people fell for that one