> ".. The user must approve access on a per website, per device basis .."
Of course, but a phishing website "fake-bank.com" could collect user's username, password, and then prompt them to touch their yubikey. This wouldn't trigger any alarm bells because it's part of the expected flow.
> This isn't any more a security hole than people clicking "yes" on UAC prompts that try to install malware.
Yes it is. The only reason why Yubikeys are immune to phishing and TOTP codes aren't is because a trusted component (the browser) accurately informs the security key about the website origin. When a phishing website at "fake-bank.com" is allowed to directly communicate with the security key there's nothing stopping it from requesting credentials for "bank.com"
Again, that exploit factor is irrelevant now because WebUSB is blacklisted from accessing, among other things, HID class devices. So no site, even with permission, can access U2F devices over WebUSB. There is no special blacklist needed per vendor or anything.
You are right that it was a security hole in Chrome <67. Which is almost a decade in the past by now.
Of course, but a phishing website "fake-bank.com" could collect user's username, password, and then prompt them to touch their yubikey. This wouldn't trigger any alarm bells because it's part of the expected flow.
> This isn't any more a security hole than people clicking "yes" on UAC prompts that try to install malware.
Yes it is. The only reason why Yubikeys are immune to phishing and TOTP codes aren't is because a trusted component (the browser) accurately informs the security key about the website origin. When a phishing website at "fake-bank.com" is allowed to directly communicate with the security key there's nothing stopping it from requesting credentials for "bank.com"