[nadams]

> What kind of two factor authentication? TOTP codes don't protect you against e.g. phishing.

Sure it does. TOTP codes are only good for X seconds and most phishing scammers merely collect the information to use much later (I have seen the source behind the actual phishing sites).

I have yet to hear of a story of someone's account being compromised while using TOTP (knock on wood).

But seriously though - companies like Google, Facebook, Gandi, Dropbox, and Microsoft all use TOTP. So I would wager that TOTP is pretty safe to use.

[microtonal]

Sure it does. TOTP codes are only good for X seconds

Not seconds, usually a minute:

https://tools.ietf.org/html/rfc6238#page-6

(This is mandated because the user could start typing at the end of a time step and/or clocks can be slightly out of sync.)

and most phishing scammers merely collect the information to use much later

Right. It's probably still profitable to do things in this manner because most people do not use any second factor. That does not change the fact that TOTP is extremely vulnerable to phishing. Most people here could probably a code that does this live in an hour or so.

But seriously though - companies like Google, Facebook, Gandi, Dropbox, and Microsoft all use TOTP.

Yes, because TOTP adds good security against other attacks, such as password leaks, since every site has its own shared secret.

[nadams]

> Not seconds, usually a minute:

Almost every service I use is 30 seconds - including Google's [1]. Even in the RFC you linked it says 30 seconds.

> This is mandated because the user could start typing at the end of a time step and/or clocks can be slightly out of sync.

That is the downside of TOTP. If your clock isn't in sync with the server's then you may never have a valid OTP. However, I have seen many implementations allow for time shifting - ie the code that was generated in the past 30 seconds, this 30 seconds and the next 30 seconds are all valid. I didn't do that for my source code hosting service - but it makes sense in case the user hit enter right after the 30 second window. I suppose HOTP is supposed to solve the timing problem.

> That does not change the fact that TOTP is extremely vulnerable to phishing.

This doesn't make sense - TOTP isn't any more vulnerable than the password itself. You still need my password. And even if you phished that - by the time you would attempt to access my account the TOTP would be invalid. The only way that would work is if you were actively watching the captured credentials and attempted to login right away. That to me would be a targeted attack rather than some random phish.

[1] - https://github.com/google/google-authenticator/wiki

[microtonal]

However, I have seen many implementations allow for time shifting - ie the code that was generated in the past 30 seconds, this 30 seconds and the next 30 seconds are all valid.

Hence one minute. This is also why I referred to the RFC.

The only way that would work is if you were actively watching the captured credentials and attempted to login right away. That to me would be a targeted attack rather than some random phish.

Why? It's no problem to make a phishing site that requests the password and the TOTP code and uses these credentials immediately.