U2F protects against that because the signature is tied to the hostname. The browser reads the hostname. The browser is infallible when it reads the hostname, unlike a human.

In most scenarios a FIDO authenticator (for U2F/ WebAuthn) won't even sign your login attempt for the wrong site at all, because of how it works. We'll look at the original FIDO (second factor only) scenario because that's cheapest and apparently Twitter was very budget conscious on security?

This FIDO authenticator has absolutely no idea what your per-site keys are. Instead, the random-looking ID provided to the site when you register and then given back by the site when logging back in actually is your private key for that site... encrypted using AEAD with symmetric keys only the FIDO authenticator knows.

One of the ingredients for decrypting the key is rpIdHash which is SHA256(dnsName) where dnsName is the FQDN of the site you're looking at or some suffix of that FQDN chosen by the site. So here it could be news.ycombinator.com or ycombinator.com (Public Suffixes like com or co.uk are prohibited). The browser is responsible for calculating rpIdHash.

Thus on a phishing attempt usually the AEAD fails, the authenticator not only doesn't give the phishing site a signature that can be used to sign in on a different site, it will ignore this ID and act as though the user doesn't have a FIDO authenticator plugged in at all.

Oops, I didn’t realise U2F was different to 2FA.

I guess you would need to ring someone up pretending to be tech support and convince them to disclose the private key.

The private key is embedded in the hardware key, there's no way to extract it without an advanced attack involving tearing apart the key.

But a practical attack along the lines of what you mentioned would be to ring someone up and convince them to disclose their cookie. Check out[1] in which the victim disclosed their cookie without the attacker even asking for it.

[1] https://hackerone.com/reports/745324