While mitigating a number of attacks, MFA with these types of physical tokens is still only as strong as their setup/enrollment process, which in many cases can be compromised via phishing.
From my experience, there’s a difference between trying to compromise someone with good opsec (many readers of hacker news) and compromising regular non technical people
How are you envisioning practically attacking deployment of FIDO tokens via phishing? Compared to conventional phishing or spear phishing attacks this seems very difficult to execute.
Suppose BigCorp users are supposed to enroll the new tokens they all received at mfa.bigcorp.example which I dunno maybe they're reaching via a link from blog.thebigcorp.example because of course these organisations have a dozen different domains used interchangeably.
I can see how you could try to redirect some or all employees to mfa.b1gc0rp.example which you control, and that's an opportunity to steal their non-token credentials, but now their token doesn't actually work.
Even though they've enrolled with mfa.b1gc0rp.example you don't directly gain working token credentials for bigcorp.example this way, and almost as importantly for this attack, nor do they. So they're going to call the company IT desk.
I guess if you own a suitable token, you could conduct this as a spear phishing attack where the victim tries to enroll at your bogus site, then you replay the non-token credentials they used for that to enroll your real token on the real site, but again the victim doesn't end up with a working token, so it seems like you're up against the clock.
And while during the pandemic I'm sure new employees were routinely enrolled off-campus, I suspect that's just not the case in normal times, even at organisations which have a very broad work-from-home policy.
I was specifically thinking banking and it’s exactly this type of spear phishing attack that happens (although with other types of tokens the Fido). In these scenarios, you only need to move the money once.
You definitely have a point with regard to non-transaction usage that requires long term access
Most MFA solutions are vulnerable to attack because there is a real challenge handling enrollment and lost tokens. It requires verification of the user, which guess what? Hard to do especially with remote users.
So, for any sort of FIDO token (a Yubico Security Key, Google's Titan, numerous cheaper products) the browser is working together with the physical token to authenticate you with U2F (on sites that didn't upgrade yet) or WebAuthn (the standard replacement)
During enrollment the site gets a unique random-looking identifier, a public key and a signed message that proves your token knows the associated private key. It stashes the identifier and public key. They aren't secret.
During authentication the site gives back one or more identifiers to ask you to prove you've still got one of these tokens you enrolled, and if your token recognises the identifier for this DNS name, it can sign a new message with the corresponding private key proving you still have the token.
Now suppose I'm a scammer, I am trying to phish users of the site realsite.example with my phishing scam site fake.example but they all use FIDO tokens. I can get realsite.example to give me the IDs for tokens (perhaps I guessed the user name and password or got it earlier by phishing), but then I'm blocked. I could try a few things:
1. I give them the realsite.example ID and I pretend my site is realsite.example. The user is never bothered by this because their web browser knows this website isn't realsite.example, I'm clearly a scammer, my attempt is ignored.
2. I give them the real IDs from realsite.example but I admit to the web browser that this is fake.example. This doesn't work because those IDs are for realsite.example and my site is fake.example. There isn't any "Wrong name, override? Y/N" type pop-up, there's no way for any component to guess what happened, it just doesn't work. Maybe the user will retry a dozen times. Maybe they'll eventually spot that it's a scam. They can't give me working credentials for realsite.example because they aren't at realsite.example.
3. I give them a nonsense ID and I admit this is fake.example, this doesn't work, their token doesn't recognise the nonsense ID.
4. I have them enroll their token on fake.example. This "works" fine, but now all I can do is authenticate this user on my site, the resulting credentials are completely useless on realsite.example, these are credentials for fake.example and nothing about them is the same.