1

I was wondering about the security of TOTP codes.

Is there any cryptographic security around the secret to stop a user being able to guess the secret after capturing a variety of TOTP codes. For example:

Attacker sniffs creds on a targets network where SSO is over HTTP using User:Pwd:TOTP . After some time can the attacker make a reasonable guess as to what the TOTP secret is by looking at what secrets produce each TOTP code and narrowing down the results?

Sam Long
  • 11
  • 2

2 Answers2

4

Yes, TOTP is cryptographically secure. TOTP is HMAC of current timestamp using a shared secret [1]. HMAC is secure. TOTP produces only 6 digits (20 bits), while protocols like TLS prefer longer MACs (128 bits), but there is no way to predict the next TOTP code (with better than 1 in 10^6 odds) by seeing all previous TOTP codes, without knowing the shared secret.

1 - https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • Agreed in general, though saying it's only 6 digits is not correct in all cases or per the standard - it's just the most common oversimplified implementation. TOTP can produce a variety of lengths; it's not actually limited to 6. Even some programmable hardware tokens go up higher, like the Molto-2 which does 4/6/8/10 digits. Many software solutions let you select your own count, including but not limited to the Keepass plugin KeeOtp2 plugin and Aegis Authenticator on Android. – Anti-weakpasswords Jan 11 '22 at 09:03
  • Even 10 digits, ~30 bits, is very far from the length used when a human doesn't need to type it (e.g. 128 bit is 38 digits). I just meant that obviously the MAC is heavily truncated. – Z.T. Jan 11 '22 at 09:09
2

The algorithm is weak, because it assumes that local timestamp cannot be manipulated, but it can under the right conditions.

Being predictable is one of the worst mistakes that can be made when security is a true concern. Counting on facts that you cannot verify is also naive design.

One great weakness of TOTP is that the combination of secret key and timestamp generates always exactly the same token result. Allowing internal clock manipulation weakens the entire concept, possibly leading security problems.

Secret Seed + Time = Token

ntpd daemon allows clock manipulation. It accepts anything coming from the upstream NTP service. So you could give a false timestamp and ntpdate would accept it without concerns.

Is a common pratice to use ntpdate as a replacement for ntpd(both of them are vulnerable to MITM attacks). ntpdate hostname should be avoided.

NTP vulnerabilities: https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html

RF03
  • 1,063
  • 1
  • 8
  • 12