6

Assume a 2FA system with user-supplied passwords and 6 digit TOTP tokens. It is not possible to test a TOTP token without authenticating with a password first, so whoever submits a token is presumed to know the password. Each token is generated for 30 seconds and is also valid within the preceding 30 seconds and the next window of 30 seconds alongside the "then current" token.

It's quite common to see false alarms because the token took a little too long to enter, so tokens can't be much longer to be practical.

Should a certain number of wrong token inputs in a row result in forced password invalidation, based on the assumption that the password may have leaked? (It might not have leaked. There might be just some problem with the second factor that will eventually go away.) If current widely used 2FA systems do this, what are the typical thresholds?

I am aware of RFC 4226 suggesting a throttling parameter of 5. I am not sure what exactly happens after the threshold is reached. Account lockout? Password invalidated? Wait a little and allow retrying?

Jirka Hanika
  • 201
  • 1
  • 7

2 Answers2

3

RFC 4226 doesn't tell me what others are doing, but it does have some viable suggestions in its Section 7.3.

Apparently, after the 5 attempts per account and device are exhausted, either a full account lockout or exponentially increasing delays should kick in, semi-permanently.

The counter must apply across login sessions and across individual TOTP tokens, as long as they are associated with the same authentication device. That way, it is impossible for too many unsuccessful device factor authentication attempts to accumulate before the constant need for the administrator to reset the device factor lockout hopefully draws appropriate attention to the account under attack; and once the password is eventually changed, the lockouts caused by the attack will stop.

Lessons taken:

  1. The protection of the device factor is no different from the protection of the password, and the two need independent protections from brute force attacks, regardless of the authentication flow.

  2. If the device factor is adequately protected in itself, it would be redundant to speculate whether the password has leaked or whether the legitimate user is just having a modest amount of trouble with their devices.

  3. To protect the device factor, it is not sufficient to protect only keys (against leaking) and tokens (against eavesdropping or guessing).
Jirka Hanika
  • 201
  • 1
  • 7
2

Limit the amount of attempts that can be made within the 30 seconds.

So if you have a token that is valid for 30 seconds and is 6 digits (for example), and you limit the amount of attempts that can be made in 30 seconds to say 5 (again as an example), then the chances of success of bruting forcing the second factor are 0.0005000005000005%.

TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
  • 1
    A sustained stream of 10 random guesses per minute, lasting 70 days, will, on average, result in one successful logon. – Jirka Hanika Dec 17 '16 at 17:25
  • Which widely used 2FA implementation does this? – Jirka Hanika Dec 17 '16 at 17:26
  • How did you calculate the 70 days until successful login? By / the seconds in a day by 30 then * 30. Im not questioning if you are right, just trying to get it right in my own head. I describing a method of making brute forcing a single valid token of 6 digits and 30s lifetime less probable, that is all. – TheJulyPlot Dec 17 '16 at 17:46
  • I assumed non-overlapping windows of validity like you stated. There are 1 million possible tokens, so 1 in a million random tries (that's 1 in (1000000 / ((5 * (60/30)) * 60 * 24)) days) will happen to match. I don't care about brute forcing a particular token. I care about brute forcing access to an account. Rate limiting helps somewhat, but it's not my only option. I'm trying to anchor my thinking around what's standard practice of mature 2FA implementations. – Jirka Hanika Dec 17 '16 at 18:26
  • A sustained stream of 10 random guesses per minute, lasting 70 days, will, on average, result in one successful logon. I therefore think that to protect each TOTP token separately would be insecure and not really RFC 4226 compliant. I tried to capture what I learned meanwhile into an answer. – Jirka Hanika Apr 10 '19 at 16:39
  • 1
    @JirkaHanika If you want to get a bit deeper into the math, following my answer [here](https://security.stackexchange.com/a/185917/151903) there's a 50% chance of successful brute forcing in just over 48 days; with 70 days it increases to a 63.5% chance of success (assuming all 5 attempts are always used every 30 seconds). – AndrolGenhald Apr 10 '19 at 19:16
  • 1
    @AndrolGenhald - I can confirm your math. The average number of successes in 70 days is 1, whereas the probability that the number of successes will be at least one after 70 days is 63.5%. Over one year, the average number of successes is 5.2 and the probability of at least one success is 99.5%. Protecting each token separately thus doesn't work. – Jirka Hanika Apr 10 '19 at 21:06