Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The closest I've ever come to falling for a Gmail phishing attack

twitter.com

Post reply on HN
Print view View original

181–190 of 289 posts

Re: The closest I've ever come to falling for a Gmail phishing attack

#181

Post by microtonal »

midgetjones wrote: post #89
microtonal wrote: post #79

Earlier quoted context omitted.

Yes, but as per the standard TOTP codes are valid for a window of 1 minute. TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).

Thanks! Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?

The RFC recommends a time step of 30 seconds + permitting at most one previous time step for handling out of sync clocks and slow/late entry:

The validation system should compare OTPs not only with the receiving timestamp but also the past timestamps that are within the transmission delay. A larger acceptable delay window would expose a larger window for attacks. We RECOMMEND that at most one time step is allowed as the network delay.

[...]

We RECOMMEND a default time-step size of 30 seconds. This default value of 30 seconds is selected as a balance between security and usability.

Since the client's clock could be in the behind or ahead of the server's clock, I have to correct myself and the window would be 90 seconds.

One could be a bit strict and e.g. the previous time step only until 1/2-way the current time step, which would bring the window make to 60 seconds.

At any rate, all these timeframes are far to large to avoid real-time phishing attacks.

Re: The closest I've ever come to falling for a Gmail phishing attack

#182

Post by unholiness »

caleblloyd wrote: post #27
slazaro wrote: post #19

The only two things that I think could have prevented me from falling for this is: I don't have images loaded by default for unknown senders, and LastPass wouldn't match the domain and therefore wouldn't show the button to autocomplete on the password box. Depending on how observant I'd be at the moment, I might check the URL bar and see something fishy. But I could fall for this, which is worrying.

Password managers really shine at times like these. It's especially helpful if when using complicated auto-generated passwords. That way you don't readily "know" your password so the first thing you do is look to autofill. It's still a good idea to have an analog backup of really important passwords. Like if you use Gmail and it is the password reset email for everything else, print out the generated password and put…

> Password managers really shine at times like these

I agree on some levels, but password managers can and have had vulnerabilities[0] that can allow the gmail password to be populated despite the wrong domain. Given that the autofill adds legitimacy and reduces friction, it could make this particular scenario go from bad to worse.

[0] https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...

Re: The closest I've ever come to falling for a Gmail phishing attack

#184

Post by Jarwain »

contravariant wrote: post #164
Jarwain wrote: post #112

Earlier quoted context omitted.

Why even render the content of data:text/html in the first place?

Because that's precisely what the 'data:' URI is supposed to do. The URI is only a description of some resource, there's no reason one description should be treated differently than any other, unless it's actually pointing to a different resource.

Its more the idea of rendering the HTML code in this fashion does not make sense to me. Maybe print the code to the page instead of rendering it. Anything would be better than rendering the code; I can't even come up with a possible use case for that functionality, can you?

Re: The closest I've ever come to falling for a Gmail phishing attack

#185

Post by [deleted] »

btown wrote: post #121
safe001 wrote: post #114

how about use 3-step auth? 1. you input your username google send back an msg/pic which you saved in google at last login confirm then goes to step 2 2. you input password 3. google ask you input auth code

So then they use a botnet to input your username on google.com to get your image, then stream it to you.

[deleted]

Re: The closest I've ever come to falling for a Gmail phishing attack

#186

Post by Jarwain »

voidlogic wrote: post #175
jonoberheide wrote: post #160

Earlier quoted context omitted.

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…

Can Duo be used to Google Authenticator or do you have to use "Duo Push"?

Cannot use Google Authenticator. Can't even use Duo Push; this is the SMS functioniality.

I do plan on getting in contact with the schools OIT for enabling alternatives

Re: The closest I've ever come to falling for a Gmail phishing attack

#187

Post by Jarwain »

grivescorbett wrote: post #170
Jarwain wrote: post #161

Earlier quoted context omitted.

That requires the user to use the Duo app though, right? I don't recall whether I had the option to use the app when I enabled MFA initially. However, after the fact, and as far as I can find, I cannot go back and enable the app.

That's correct, of course without having the app installed there is no option other than SMS or a hardware token. I remember that configuring this is tricky, but I did eventually get user self enrollment configured with push being the default. Happy to dig more into my config, if you're curious: gabe@untapt.com

Totally curious, unfortunately it'd probably go in one eye and out the other since I'm not involved in the Uni's implementation.

Re: The closest I've ever come to falling for a Gmail phishing attack

#188

Post by garrettr_ »

midgetjones wrote: post #89
microtonal wrote: post #79

Earlier quoted context omitted.

Yes, but as per the standard TOTP codes are valid for a window of 1 minute. TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).

Thanks! Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?

If the codes are time-based (TOTP), they are typically generated with a rolling window of 30 seconds (as you saw in Google Authenticator). The 30s rolling window is the recommended (and widely implemented) default value from the TOTP RFC [0].

It is common but not universal for sites to accept, at a given time, 1) the current U2F token, 2) the U2F token from the previous window, 3) the U2F token for the next window. This is done as a partial mitigation for potential clock skew issues on the client that's generating the TOTP codes (e.g. your phone). In practice this means every code is valid for 1m30s, although sites may customize this (with or without changing the window size, which is typically not done because that parameter must be consistent system-wide).

> If I wait till the last few seconds before using the code, does that make me any safer?

Maybe, but this is not practicable security advice. The latency of a MITM attack on a 2-factor TOTP login depends on the attack infrastructure and design, but can easily be made to be on the order of tens or hundreds or milliseconds. Reducing the window seems like it might help your security, but it can never be perfect and there is a direct tradeoff with usability because users need time to look up the codes on one device and enter them on another.

Folks often say "enable 2FA" in response to news of new and sophisticated phishing attack campaigns, but it's critical to note that most commonly deployed 2FA (TOTP, HOTP, SMS) is trivially phish-able. 2FA is not an automatic defense against phishing, although some newer designs achieve this and were created specifically with this goal in mind: U2F is a good example.

[0]: https://tools.ietf.org/html/rfc6238

Re: The closest I've ever come to falling for a Gmail phishing attack

#189

Post by contravariant »

Jarwain wrote: post #184
contravariant wrote: post #164

Earlier quoted context omitted.

Because that's precisely what the 'data:' URI is supposed to do. The URI is only a description of some resource, there's no reason one description should be treated differently than any other, unless it's actually pointing to a different resource.

Its more the idea of rendering the HTML code in this fashion does not make sense to me. Maybe print the code to the page instead of rendering it. Anything would be better than rendering the code; I can't even come up with a possible use case for that functionality, can you?

You could generate a webpage and link to it without needing to host it somewhere.

At any rate, if you allow a URI scheme that embeds the data in the URI itself it'd be very odd to arbitrarily restrict the valid MIME types. It'd be like forbidding a http URL from linking to a JPEG.

Re: The closest I've ever come to falling for a Gmail phishing attack

#190

Post by samch »

jonoberheide wrote: post #160
Jarwain wrote: post #73

Earlier 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'm at a large research university, and we use Duo across the institution. It really does work as advertised. The Duo Push feature combined with my iPhone's TouchID is very convenient (Duo Push also works on other devices).

Most importantly to me, though, the system has thus far been completely reliable. I haven't yet heard of a single case where somebody couldn't log in because of Duo. I'm not sure what our enterprise agreement is / how much this all costs, but it's a very good system for us.

Post reply on HN