If you use the physical tokens it does solve that because the tokens won’t authenticate on the scammer site.

What type of physical tokens are you talking about and what exactly do they do to prevent authentication on the scammer site?

Yubikeys could be one example

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.

This is true, and the goal of Security Awareness Training is to resolve this problem. I’m a huge believer in it.

Domain checking hardware will mitigate such vulnerabilities, sure, but good luck seeing that viably roll out to SMEs.

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)

It's involves some clever cryptography, and engineering. Here's an old ImperialViolet entry about it: https://www.imperialviolet.org/2018/03/27/webauthn.html

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.

>MFA doesn’t solve targeted phishing and that’s something people keep forgetting.

any VPNs support u2f?

While not U2F but pretty close for the issue at hand (preventing phishing), any VPN that supports radius as a backend can use Windows NPS which can be integrated with Azure AD MFA to send a notification to the phone.

You may still want to train the users not to accept any random request on the app, though. But this works (fairly) well and is cheap (no hardware token to buy).

https://docs.microsoft.com/en-us/azure/active-directory/auth...

Phone confirmation doesn't evade phishing. The user doesn't think the request they just got on the app is "random" because they think they're doing the right thing. The whole idea of phishing is to trick the human user.

Tailscale should (indirectly) with 3rd party Google/Okta/Etc auth.

Cisco VPN does.