3

If I were to publicly display the 6 digit code from my google authenticator, would my account security be diminished beyond it's valid life time?

What if it were the code and the time it was generated?

What if it were N sequential codes?

I'd like to know why or why not for each case.

4

Google Authenticator uses the Time-based One-time Password Algorithm ("TOTP"), which works by computing HMAC with a secret key over a timestamp.

HMAC is a message authentication code ("MAC"). The standard security requirement for a MAC is that it be able to resist existential forgery (an attacker who doesn't know the key should not be able to forge any (message, tag) pairs) under adaptive chosen text attack (we allow the attacker the ability to cause the defender to compute tags for any messages of the attacker's choice, and to learn from earlier results when choosing new queries).

The TOTP 6-digit result however is not a straight MAC output, but rather a truncation of a MAC tag, so the question could be raised whether truncating the MAC is also a secure MAC. However HMAC, when used with a good hash function, is also believed to be a pseudo-random function. PRFs are automatically good MACs, and the truncation of a PRF is also a PRF, so the truncation of HMAC is also a good MAC.

TL;DR: Not unless the attacker could break HMAC-SHA1 under unfavorable conditions, which would be a really big setback for the crypto world as a whole, not just TOTP.

  • So you're saying that even if the attacker is allowed to feed timestamps into my fob and observe the resulting codes (despite the fact that I've lost the battle at that point) they have no advantage in producing further codes without the fob? – Aaron McMillin Jul 29 '16 at 15:25
  • @AaronMcMillin: Heuristically yes, meaning it's a weak "yes" with one standard caveat (shared by nearly if not all practical modern cryptography): there is no unconditional proof of it. Basically, if HMAC-SHA1 is a pseudo-random function (PRF), then a SHA-1-based TOTP implementation is secure in the way I described. HMAC-SHA1 is generally considered a secure PRF today because nobody's been able to break it, but it's not impossible that somebody might break it in the future. That would require switching to a different PRF. – Luis Casillas Jul 29 '16 at 18:18
5

No. Thats the whole point of TOTP/HOTP. That it should be infeasible, given any sequence of valid codes, to generate future codes or recreate the seed.

The reason is that the TOTP/HOTP algoritm, use HMAC-SHA1 as hash, given the "challenge" (either current UNIX time or a counter of usages) and the secret "seed" as key. The resulting hash output is then truncated according to a very specific rule.

This would mean, in your first case, it would be impossible to do, as multiple valid keys will come up with the "correct" 6-digit code but will turn out to be incorrect as future codes from these "valid keys" will be invalid.

To successfully mount a bruteforce attack against a seed, you would atleast need 2 valid auth codes, possible more, and even in that case, its infeasible (eg, practically impossible) to do it.

  • So my question is: Is it less impossible to mount the attack with N codes and their challenges than without that information? – Aaron McMillin Jul 29 '16 at 15:22
  • Yes. But still basically impossible. Its totally impossible to mount a attack knowing nothing, or only one code. But knowing 2 or more codes, or knowing a challenge and response, makes it possible to brute force key. But still, that will take the time until the sun extinguish. It would be much easier to bruteforce the actual TOTP/HOTP login instead, as its only 6 digits providing no lockout system is in effect. – sebastian nielsen Jul 29 '16 at 16:43
0

The first OTP definition in RFC 2289 based on S/Key had even this design requirement.

It was not ment to implement two factor authentication but to merely protect the password or passphrase. It was simply used to avoid the password crossing the network - obviously it was assumed that the transmission could be evesdropped or unencrypted.

So as already stated, it is a fundamental design in all OTP systems (S/Key, mOTP, OATH) to not allow the guessing of future passwords based on used passwords.

But: With an event based algorithm like HOTP you can of course create OTP lists. If you generate an OTP value now and post it on the internet but don't use it for login, everyone else can use it. It only gets invalidated, when this very value gets used or a later value gets used.

  • Right, I was considering only the TOTP codes, not the extra recovery codes. – Aaron McMillin Jul 29 '16 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.