4 ms·

MFA doesn’t solve targeted phishing and that’s something people keep forgetting. Sprays are just the best ROI, but if everything had MFA it would quickly create

MFA doesn’t solve targeted phishing and that’s something people keep forgetting. Sprays are just the best ROI, but if everything had MFA it would quickly create a phishing as a service business model.

gruez 5y ago
>MFA doesn’t solve targeted phishing and that’s something people keep forgetting. any VPNs support u2f?
- vladvasiliu 5y ago
  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/authentication/howto-mfa-nps-extension https://docs.microsoft.com/en-us/azure/active-directory/auth...
  - tialaramex 5y ago
    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.
- mdeeks 5y ago
  Tailscale should (indirectly) with 3rd party Google/Okta/Etc auth.
- galuano1 5y ago
  Cisco VPN does.
foxpurple 5y ago
If you use the physical tokens it does solve that because the tokens won’t authenticate on the scammer site.
- mistahenry 5y ago
  What type of physical tokens are you talking about and what exactly do they do to prevent authentication on the scammer site?
  - tialaramex 5y ago
    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 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.

gruez 5y ago

>MFA doesn’t solve targeted phishing and that’s something people keep forgetting. any VPNs support u2f?

vladvasiliu 5y ago
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/authentication/howto-mfa-nps-extension https://docs.microsoft.com/en-us/azure/active-directory/auth...
- tialaramex 5y ago
  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.
mdeeks 5y ago
Tailscale should (indirectly) with 3rd party Google/Okta/Etc auth.
galuano1 5y ago
Cisco VPN does.

foxpurple 5y ago

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

mistahenry 5y ago
What type of physical tokens are you talking about and what exactly do they do to prevent authentication on the scammer site?
- tialaramex 5y ago
  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 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.