121–130 of 156 posts
Earlier quoted context omitted.
But it's also the default behavior if you sign on from a computer Google doesn't recognize, so it's not really strange to see the grey icon instead.
> a computer Google doesn't recognize If Google can recognize your computer without being logged in, it's time to up your privacy settings.
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 they're using. All of this, even just to target a single person, is under 8 hours of work, which is to say, it's a simple task for someone who really wants to phish you.
The article mentions having an IDS and disaster recovery plans, and this is the best you can hope for as pretty much everyone is susceptible to this, and AI still can be beaten.
Source: I've done this, beaten Gmail's anti-scam filters, and phished CTOs.
Earlier quoted context omitted.
Does 2 factor prevent phishing though? If I was going to do a Google Phishing page - I would take the username + password that the user supplied into MY fake page, and POST/CURL that to the Google login. If Google returns asking for a 2factor to MY fake, I would display the 2 factor prompt to the user, and get them to type the 2-factor into my page, which I would pass back to Google. Basically you can use a phishing…
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…
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).
This article seems great at describing how phishing actually works in practice, especially to people without much exposure to technology. I've gone through at least a couple of training emails from IT departments about phishing, and this was way more effective. A realistic case-study with a really clear description is valuable! This article could definitely augment the anti-phishing education at your organization—the…
Earlier quoted context omitted.
Does 2 factor prevent phishing though? If I was going to do a Google Phishing page - I would take the username + password that the user supplied into MY fake page, and POST/CURL that to the Google login. If Google returns asking for a 2factor to MY fake, I would display the 2 factor prompt to the user, and get them to type the 2-factor into my page, which I would pass back to Google. Basically you can use a phishing…
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…
> 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…
Trust the top 10,000 domains, then the user has to allow anything beyond that. Built off of dnsjack. App will point to corporate dns server.
Earlier quoted context omitted.
No. There is no email-to-profile-pic mapping endpoint for unauthenticated users, to my knowledge.
Then how does the image consistently display before the password has been provided? No matter what the answer is, I don't see how it could be an anti-phishing feature.
Try from the incognito windows in your browser the image should not show up since no cookies are being sent in the incognito window.
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…
Does 2 factor prevent phishing though? If I was going to do a Google Phishing page - I would take the username + password that the user supplied into MY fake page, and POST/CURL that to the Google login. If Google returns asking for a 2factor to MY fake, I would display the 2 factor prompt to the user, and get them to type the 2-factor into my page, which I would pass back to Google. Basically you can use a phishing…
I just announced beta of host based DNS whitelisting app. It trusts top 10,000 domains, then user has to allow other domains.
It's worth nothing the new user-image-before-password-input for Google is an anti-phishing feature. Of course, most people won't think that deeply when prompted with a password request and a similar UI.
For example, we use Google Apps at work with our custom domain, with an internal SSO server providing authentication services. You enter your email address, the Google page directs you to the internal SSO server, you get a token, take that back to Google, and you get logged in - no password required.
Earlier quoted context omitted.
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).
If you use U2F, then the domain name difference will mean that the U2F key can never match unless the attacker has control over DNS and is issued a Google.com SSL certificate by an authority the target's computer trusts.