Note that not all hardware security devices are safe. U2F security devices are safe against phishing; OTP security devices are not safe against phishing.
what about a phishing attack that involves the attacker talking the target through a login, which also involves the u2f part? and then obtaining the session token from memory/disk instead of username/password
How would the attacker get something from memory or disk? Malware? If there's malware involved I don't consider that credential phishing. It's a matter of debate whether malware can be considered a form of phishing. Maybe I should be been more clear that U2F stops credential phishing, not malware phishing (if that even exists).
I guess one option would be to ask the victim to read out the token from memory or disk. That seems pretty hard though. It's debatable whether that would be considered credential phishing.
A more likely method would be to trick someone into going into devtools and copy and pasting something from there, possibly a curl command, like in this epic "bug report"[1]. That's also debatable whether it would be credential phishing.
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 qht.co 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.
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.
