3 ms·

TOTP, unlike a password, can't be brute-forced. If the secret is lost, its game over, but if the secret stays protected, you can't guess it because you can only

TOTP, unlike a password, can't be brute-forced. If the secret is lost, its game over, but if the secret stays protected, you can't guess it because you can only test the codes, not the secret itself. Brute-force for TOTP would only be possible if you could test 2^6 OTPs in the 60-second window, which would be mitigated by rate-limiting. So it really doesn't do any hard to have TOTP enabled as a fallback if you never store the key anywhere.

akerl_ 7y ago
It’s worth noting that TOTP secrets are more vulnerable than passwords on the service-provider side. They have relatively tiny key space (generally 6 digits), so if the provider doesn’t protect against brute-force, it’s quick and easy to slam the whole key space until you win. They also need the secret in a reversible format, since the service provider has to use the secret to calculate valid codes. So the most common password brute-forcing pathway (theft of a database full of password hashes) is rendered moot: you don’t have to brute-force the hashes because they aren’t hashes, they’re just secrets. At best, the TOTP seeds are encrypted at rest, but since whatever server validates tokens has to decrypt them to do so, most implementations in the wild either don’t encrypt or keep the decryption key right next to the data.
- throw0101a 7y ago
  While the resulting codes you get at the end of the process are only six digits, the TOTP secret can really be any length. Everything is fed into an HMAC after all. It's only the last step where truncation occurs.
  - akerl_ 7y ago
    Yes, but the key space to brute force is the key space after truncation. You don’t need to brute force the original seed.
    - philsnow 7y ago
      If an attacker can (for whatever reason, be it rate limiting or cost) only brute force 100 guesses per time period (say, 30s), they'll expect to be able to 'win' the challenge in about 58 hours. The probability of guessing the challenge _wrong_ once is (1 - (100 / 1000000)). Every 30 seconds you get another chance. The probability of guessing the challenge wrong N times in a row is (1 - (100/1000000)) ^ N. Around chance number 7000, the probability that you've guessed it wrong all N times goes lower than 50/50. ~7000 * 30s in hours is around 58 hours.
      - cbo100 7y ago
        At some point the 2FA protected system should stop accepting guesses entirely for a period - the same way you would lock an account for incorrect password guesses, or at worst rate limit down to a single guess per time period after a certain number of failed guesses.

akerl_ 7y ago

It’s worth noting that TOTP secrets are more vulnerable than passwords on the service-provider side. They have relatively tiny key space (generally 6 digits), so if the provider doesn’t protect against brute-force, it’s quick and easy to slam the whole key space until you win. They also need the secret in a reversible format, since the service provider has to use the secret to calculate valid codes. So the most common password brute-forcing pathway (theft of a database full of password hashes) is rendered moot: you don’t have to brute-force the hashes because they aren’t hashes, they’re just secrets. At best, the TOTP seeds are encrypted at rest, but since whatever server validates tokens has to decrypt them to do so, most implementations in the wild either don’t encrypt or keep the decryption key right next to the data.

throw0101a 7y ago
While the resulting codes you get at the end of the process are only six digits, the TOTP secret can really be any length. Everything is fed into an HMAC after all. It's only the last step where truncation occurs.
- akerl_ 7y ago
  Yes, but the key space to brute force is the key space after truncation. You don’t need to brute force the original seed.
  - philsnow 7y ago
    If an attacker can (for whatever reason, be it rate limiting or cost) only brute force 100 guesses per time period (say, 30s), they'll expect to be able to 'win' the challenge in about 58 hours. The probability of guessing the challenge _wrong_ once is (1 - (100 / 1000000)). Every 30 seconds you get another chance. The probability of guessing the challenge wrong N times in a row is (1 - (100/1000000)) ^ N. Around chance number 7000, the probability that you've guessed it wrong all N times goes lower than 50/50. ~7000 * 30s in hours is around 58 hours.
    - cbo100 7y ago
      At some point the 2FA protected system should stop accepting guesses entirely for a period - the same way you would lock an account for incorrect password guesses, or at worst rate limit down to a single guess per time period after a certain number of failed guesses.