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.
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.
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