Pretty. Damned. Clever. ...And, scary too.
The closest I've ever come to falling for a Gmail phishing attack
191–200 of 289 posts
Re: The closest I've ever come to falling for a Gmail phishing attack
#192Earlier quoted context omitted.
Very clever, thanks for sharing. However I wouldn't want my second-factor to be attached to my browser. Seems way too volatile for me. Personally I'd rather keep TOTP and be vulnerable to time-of-use phishing. Maybe if the browser had an OS API that a YubiKey could query...
It's actually the other way round, the YubiKey (or other U2F token) has an API the browser queries, generally triggering the token requesting some sort of physical interaction.
I know how it is now, but that's not what I'm talking about. Currently the URL is not included in the hash, that's my point. It could be by having those two talk to each other. Who's the server and who's the client is beside my point.
Re: The closest I've ever come to falling for a Gmail phishing attack
#193Earlier quoted context omitted.
This is definitely true of TOTP but U2F was designed to prevent phishing attacks by incorporating the hostname in the protocol[1], which means the attacker needs to successfully compromise SSL as well. 1. https://security.stackexchange.com/questions/71316/how-secur...
Very clever, thanks for sharing. However I wouldn't want my second-factor to be attached to my browser. Seems way too volatile for me. Personally I'd rather keep TOTP and be vulnerable to time-of-use phishing. Maybe if the browser had an OS API that a YubiKey could query...
Just to extend on what jon-wood said, that's definitely the other way around: U2F is an open standard and the intelligence lives on the USB/NFC device. Any browser which implements that standard[1] can login and, especially nice for security, the browser never gets access to the keys or, with devices like the YubiKeys which require you to touch a button for each request, even the ability to authenticate without user approval.
1. Currently Chrome has this, Firefox is close (50.1 shipped it but it only works in the e10s mode), and there are extensions for Safari and older versions of Firefox.
Re: The closest I've ever come to falling for a Gmail phishing attack
#194Earlier quoted context omitted.
My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used…
Sorry to hear about your experience, Jarwain! Duo offers a choice of authentication methods, depending on the usability and security requirements of your application or organization. Duo Push is actually one of the easiest (and most secure) authentication methods, as one of the commenters pointed out: https://www.youtube.com/watch?v=tPLxe9HUDjY It might be worth pinging your IT/security dept to ask about enabling Duo…
I hadn't heard of Duo. Just looked briefly at the site. Does anyone have a TL;DR on that? Why would one use that rather than the native 2FA?
Re: The closest I've ever come to falling for a Gmail phishing attack
#195This could be prevented by using physical keys instead of passwords. People are weak in deciphering URL bar contents.
Re: The closest I've ever come to falling for a Gmail phishing attack
#196Earlier quoted context omitted.
Yep, that's what I'm saying too. If you've fallen for providing 1FA, you'll fall for 2FA too, since you think it's legit.
Apple's 2FA for iCloud will likely avoid this if you're careful. They do a GeoIP lookup of where the request is coming from and show the approximate location of the login attempt before they show you the 2FA code. For example, when logging in legitimately from home, it'll say that there's a login attempt from the city where I live. In the likely case where the phisher's server isn't in this area, it'll show something…
[deleted]
Re: The closest I've ever come to falling for a Gmail phishing attack
#197Earlier quoted context omitted.
That would break more legitimate HTML e-mails than the phishing it's aiming to catch. You might argue that it's worth the breakage but that would be a harder argument to sell to businesses. Pragmatically I think Browsers disabling the rendering of data:text/html is a better approach. The breakage is minimal and it would catch more phishing attacks than just ones that originated from emails with images embedded.
According to our numbers, plain emails actually perform better than HTML emails when it comes to business mailings.
That's good to read but sadly that's a different point to the one I was making. Google would break a lot of legitimate emails if they make the changes to GMail that the GP was proposing. This would be an unattractive solution to Google as they are effectively breaking their "mail client" (in the broader sense of the term) in relation to their competitors and the benefits are limited to a specific type of phishing attack. So when Google way up the risk of annoying their customer base vs the securing them: this particular fix is unlikely to score high enough in the latter category to be worth the risk to the former.
Re: The closest I've ever come to falling for a Gmail phishing attack
#198I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…
Ah the classic "ugh. we don't want to have to fix this, so here are some bullshit technical reasons why it's impossible and a bad idea".
[deleted]
Re: The closest I've ever come to falling for a Gmail phishing attack
#199I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…
Ah the classic "ugh. we don't want to have to fix this, so here are some bullshit technical reasons why it's impossible and a bad idea".
yeah but we all do this everyday to the designers
Re: The closest I've ever come to falling for a Gmail phishing attack
#200IMHO javascript should never have been allowed in the address bar or even inline in an href. The first time I learned about this feature of a browser, I was thinking 'security defect'.
It's not Javascript, it's a data URI that renders an HTML page.