0

What are the risks (if any) of sharing the TOTP codes?

I'm referring to the six-digit codes generated by Google Authenticator and the like. By "sharing old tokens" I'm thinking of posting online a list of, say, 10 consecutive codes I got (and the times I got them), or letting someone who's with me see my phone in real-time, but being sure they are not using them to log in as myself into any system.

I'm thinking about the possibilities of deriving? the original secret seed, or thinks like that - and not thinking about people letting others know my code without me noticing it so they impersonate me.

Is there any other risk I'm not thinking about?

mgarciaisaia
  • 157
  • 1
  • 7
  • 3
    https://security.stackexchange.com/questions/162348/how-many-known-time-result-combinations-does-it-take-to-guess-a-hotp-totp-secret Related – Monica Apologists Get Out Sep 06 '18 at 15:08
  • 2
    If an attacker were able to use a malicious NTP server to set back the server's time it could allow them to authenticate (if they know your password as well of course), though this should be prevented anyway as it causes many other problems too (such as allowing expired TLS certificates). – AndrolGenhald Sep 06 '18 at 15:14

1 Answers1

2

I think the general answer is "It should be ok, but TOTP wasn't designed for this so you won't get any guarantees".

If we dive into how TOTP works (general description at wikipedia, full spec in RFC 6238), the TOTP value is computed as (example, simplified)

SHA2_HMAC( secret_seed, system_time_rounded_to_30s )

Generally login servers will check all time values within a +/- 5 minute window in case the device's system clock is off (which is needed for hardware TOTP tokens like those pictured below that have no way to sync).

So your TOTP values may actually still be valid for ~ 5 minutes. Also, as @AndrolGenhald points out, they may become valid again if the server's system clock gets set back.

This question does a good job of addressing the "can the original seed be derived" part of your question, the general answer is "it shouldn't be possible as long as the shared secret_seed is 32 bytes or more".

It's also possible that the website's implementation has some edge-cases that break this general advice. For example, some websites issue account recovery codes that look like TOTP codes, but I don't know if they're actually related to your TOTP seed or not.

Various hardware OTP tokens

Bottom line: I can't think of any attack from posting a list of expired OTP codes, but I also can't guarantee that it's safe.

If you're at a coffee shop, probably best to be careful about who can shoulder-surf your TOTP codes. If you want to post old codes online, probably best to register a new code generator and unlink the other one from your account before posting.

Community
  • 1
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Could you clarify how "TOTP wasn't designed for this"? Doesn't a frequently changing code kind of imply a threat model where former codes may be known to an adversary? I see in the HOTP [RFC](https://tools.ietf.org/html/rfc4226#appendix-A.3): "the adversary is assumed to be able to eavesdrop, meaning, to see the authenticator transmitted by the user." (Not that that makes it a great idea to publish a bunch of former codes online of course) – AndrolGenhald Sep 06 '18 at 16:32
  • @AndrolGenhald It might, if the designers of the server interpret it that way. I would say that it's certainly true that once you've used a code, that particular code should not be reusable (and worthy of a CVE if it is), but I wouldn't be comfortable assuming that an old unused code is harmless across all vendors. – Mike Ounsworth Sep 06 '18 at 16:36
  • Fair point, I didn't take into account that the code was unused. The TOTP RFC says "Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP." And of course HOTP implicitly prevents re-use due to the counter. I would be slightly concerned about non-conformant implementations though. – AndrolGenhald Sep 06 '18 at 16:45
  • @AndrolGenhald Agreed, a good implementation will track in the DB the most recent timestamp used by each user, implicitely invalidating older codes, and also have a short validity window. I wonder if every single 2FA server out there counts as a "good implementation" ? – Mike Ounsworth Sep 06 '18 at 16:52