The beginning of the story is missing. PZ clicked on the link in the email because it was "received [...] from a familiar mailing list" . Did PZ trust a mailing list where anyone could post? Or did the attackers spoof the "from" field? The former may have been prevented by employee training, the latter by SPF or similar technologies.
Sharing links is so common that if you want to punish users for that you can't run your business anymore.
But yeah they shouldn't login on sites that the password isn't auto completed for.
> What makes an attack like this so effective is that you never expect to see something as convincing as this I've been working on phishing and counter-phishing recently, and if someone is actually putting any effort in, you have to expect something like this. Very legitimate looking email, the correct signature (complete with up to date font/logo), and a virtually perfect copy of the login page to whatever service t…
Then you may be able to answer this question: is it really a problem that those people accessed the link but didn't login? Because sure you could put malware on it, but that's possible on any website.
This is where the type of MFA matters a lot: with a TOTP code, that phishing attack will be successful. With U2F, however, a per-host keypair is generated during the setup process and the public key is given to the remote server. Critically, the hostname as seen by your browser is part of the key identifier: see http://security.stackexchange.com/a/71704/311 That means that if in the future even if someone convinces y…
But can't the phisher just visit Google and log in there with 2FA, while receiving the 2FA code from the fake site? This only requires the user not to read the URL and match it to the URL in the Google Authenticator app (as far as I can see right now).
As acdha said, no, this type of attack isn't possible with U2F.
> What makes an attack like this so effective is that you never expect to see something as convincing as this I've been working on phishing and counter-phishing recently, and if someone is actually putting any effort in, you have to expect something like this. Very legitimate looking email, the correct signature (complete with up to date font/logo), and a virtually perfect copy of the login page to whatever service t…
Then you may be able to answer this question: is it really a problem that those people accessed the link but didn't login? Because sure you could put malware on it, but that's possible on any website.
Yes, but in theory some sort of MAC could stop it from accessing important files, or anti-virus could detect it and stop it too. But once the password leaves the computer, it's going to take a lot more effort to mitigate the damage. Also, your browser is on your side for protecting against malware, so for example if you have Flash disable, that's a whole vector you can just ignore.
Many people won't check the url when signing in if everything looks to be on the up and up. This is why I really liked one of the things Yahoo did which was create a sign-in seal. Every time you signed in Yahoo would display a custom image that you set and if that image wasn't there then something was probably wrong.
My bank (ING Direct) had that. And then they were bought by Capital One, who removed it.
ING-Diba in Germany is still doing this. Here, I am assuming that ING Direct is the same folks as ING-Diba.
The beginning of the story is missing. PZ clicked on the link in the email because it was "received [...] from a familiar mailing list" . Did PZ trust a mailing list where anyone could post? Or did the attackers spoof the "from" field? The former may have been prevented by employee training, the latter by SPF or similar technologies.
In my experience if you use multiple Google accounts you get login prompts all the time: half the time the Google Doc/Drive link requires me to switch to another account, and occasionally asking for password confirmation as well.
If a server is making the proxied request, would this still matter? The server will pretend to be a legit browser submission? In your link they mention reply. But what about a browser you control on the server?
Your browser connects to Google and tells the U2F token to auth using the www.google.com key: works Your browser connects to www.google.com@phish.me but no matter whether you believe that site to be Google, the U2F process means that it can only use a key for phish.me, which won't work on the Google.com servers even if they relay it. The only attack which still works is if they control DNS and can forge an SSL certif…
> The only attack which still works is if they control DNS and can forge an SSL certificate
Or if they're able to get some malware onto your system permitting them to change your dns servers or alter your hosts file, and add certificates to your OS/browser trust store.
2 factor authentication is key here. The ubikey is a gold standard for business - no one should do serious business without it! For everyone else, I think the new 2fa Google App approach is better. When you go to login, your Google App pushes a notification to your phone and you have to click on it. This raises the bar to doing a simultaneous login, which isn't impossible, but even if it weeds out a large number of a…
https://tozny.com/ sells a service that enables this for any app, not just Google. I have a Yubikey and I find it too obnoxious for day-to-day use. I'd rather use an authenticator app (such as Google's or LastPass'). For TOTP on non-Google sites, I find LastPass better than Google's Authenticator. First, LastPass locks the app with a PIN. Second, it can work with the browser extension to fill out those 6-digit codes…
https://duo.com/ also provides a service (with free and paid tiers) to enable this in a range of applications.