3 ms·

If you setup TOTP (Authenticator) while this bug was out in the wild your shared secret key could have leaked. SMS would actually be safer than TOTP in this sce

If you setup TOTP (Authenticator) while this bug was out in the wild your shared secret key could have leaked. SMS would actually be safer than TOTP in this scenario.

leni536 10y ago
That's insightful. So you shouldn't only reset your passwords, but your TOTP setup too (if you set it up in this period). I think it's a flaw of TOTP though. The client secret should be client generated and should never leave the device.
- almost_usual 10y ago
  Yes, unfortunately both the client and server need to have that shared private key to generate the same codes. Transmitting the key over a 'secondary' channel would have protected people here. It begs the question of whether or not TOTP is really 2FA if it is setup using a single channel of communication.
philsnow 10y ago
What ? No, that shouldn't be possible (unless the site operator massively fucked up, or there's some attack that feasibly lets you go from one or more TOTP values to the likely shared secret). TOTP works by having (as you said) a shared secret key, and both sides calculate an HMAC of the secret along with the timestamp, and then just modulo the resulting HMAC by 10^6 (usually, for TOTPs with six digits). Your google authenticator (or whatever) app does this HMAC on the shared secret + time, you type in six digits, and the other side does the same HMAC and verifies that they're the same. If they're UX-conscious, they might decide to HMAC the previous and next 30 second periods as well and compare those too, to account for small amounts of time skew.
- detaro 10y ago
  parent said "if you setup TOTP". If you did that, you somehow communicated the shared secret key to your authenticator, presumably from a web page. Which could have leaked.
  - philsnow 10y ago
    ah, thank you, that makes more sense.

3 ms·

If you setup TOTP (Authenticator) while this bug was out in the wild your shared secret key could have leaked. SMS would actually be safer than TOTP in this sce

by almost_usual 10y ago

If you setup TOTP (Authenticator) while this bug was out in the wild your shared secret key could have leaked. SMS would actually be safer than TOTP in this scenario.

leni536 10y ago
That's insightful. So you shouldn't only reset your passwords, but your TOTP setup too (if you set it up in this period). I think it's a flaw of TOTP though. The client secret should be client generated and should never leave the device.
- almost_usual 10y ago
  Yes, unfortunately both the client and server need to have that shared private key to generate the same codes. Transmitting the key over a 'secondary' channel would have protected people here. It begs the question of whether or not TOTP is really 2FA if it is setup using a single channel of communication.
philsnow 10y ago
What ? No, that shouldn't be possible (unless the site operator massively fucked up, or there's some attack that feasibly lets you go from one or more TOTP values to the likely shared secret). TOTP works by having (as you said) a shared secret key, and both sides calculate an HMAC of the secret along with the timestamp, and then just modulo the resulting HMAC by 10^6 (usually, for TOTPs with six digits). Your google authenticator (or whatever) app does this HMAC on the shared secret + time, you type in six digits, and the other side does the same HMAC and verifies that they're the same. If they're UX-conscious, they might decide to HMAC the previous and next 30 second periods as well and compare those too, to account for small amounts of time skew.
- detaro 10y ago
  parent said "if you setup TOTP". If you did that, you somehow communicated the shared secret key to your authenticator, presumably from a web page. Which could have leaked.
  - philsnow 10y ago
    ah, thank you, that makes more sense.