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?

Improve this question

2 Answers 2

Reset to default
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).
Improve this answer
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%.

Improve this answer
7
  • 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, 2016 at 17:25
  • Which widely used 2FA implementation does this?
    – Jirka Hanika
    Dec 17, 2016 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, 2016 at 17:46
  • 1
    @JirkaHanika If you want to get a bit deeper into the math, following my answer here 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, 2019 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, 2019 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .