If I implement two factor authentication using TOTP, I (obviously) have to protect against simple brute force attacks of the TOTP value.

If I ask for the TOTP value after successful password login, the attacker already knows the valid password. Since the default length for TOTP value is 6 digits, it's easy to brute force.

Possible solutions:

  • Block user account: Disadvantage of blocking a legitimate user with no way of unblocking.
  • Block IP: Might work, but might be bypassed by leveraging a botnet. Should block more than a single IP for IPv6.

Solutions that do not work:

  • Block current session: Doesn't work, because the attacker knows the password and can just open another session.

How can a brute force protection be implemented so it doesn't lock out the legitimate user, but still blocks attacks as good as possible?

  • 1
    You could suspend the account for n mins, that would slow an attack, but not impact legitimate users too badly. Another option would be popping a captcha after n failed attempts. You probably want monitoring around this so you can IP block attackers. Legitimate users don't make 100s of requests in a short time span.
    – Jay
    Commented Apr 13, 2016 at 14:34
  • 2
    another thought, you could lock their account after n failed attempts and force a password reset, assuming you do that via email you at lest confirm that the user has access to the email address).
    – Jay
    Commented Apr 13, 2016 at 14:36
  • @Jay So we would have to ask for the current password, a TOTP value, a token sent per e-mail and the new password (assuming that e-mail isn't secure and access to an e-mail inbox should grant access to an account).
    – kelunik
    Commented Apr 13, 2016 at 14:47

1 Answer 1


The thing about brute forcing a TOTP token is that you have to guess right at the right time. So, if you don't want to lock a user out after x failed attempts (which is common practice) you can slow failed attempts down to the point where the odds of getting the TOTP right are statistically insignificant.

For example: 6 digit TOTP token has 1,000,000 possibilities. But the correct key changes every 30 seconds (in the standard implementation of TOTP) so window of success is not how long it takes to exhaust the entire token space, but how many tokens the attacker can get through in a given period divided by the tokenspace, and its still only a chance at success. Make it impossible to get through the token space in 30 seconds and you reduce the attack to a gamble.

Example: the attacker gets one guess per second. They can only get through 30 guesses of any given token so the odds of success are basically random. Using the Bernoulli process of random variables (chance of failure times number of guesses), 24 hours of attacking this way (86,400 guesses) yields only an 8.2% probability of success. At 10 days, it rises to 57%. So, simply convince your user to change their password, or find some other way to block the attacker (by IP, etc) before that percentage gets very high.

  • 3
    I do not think it is relevant for a brute-force attack that the token changes every 30 seconds. Suppose an attacker can test 1000 tokens in the first 30 seconds. That gives a change of 1/1000 of being correct. The next 30 seconds the attacker can simply try the same 1000 tokens again. As the token has changed, there is a new 1/1000 chance of being correct. After 500 * 30 seconds (a little over 4 hours) he has a over 50% chance of success in all the tries.
    – Jeff
    Commented Apr 2, 2017 at 17:45
  • 2
    @Jeff Incorrect. After 500 rounds of 1000 attempts it would be 1 - .999^500 = 39.36% total chance of success. If the token never changed it'd be 500,000 / 1,000,000 = 50% chance, so it does matter that it changes. Commented Jul 16, 2018 at 15:14
  • 1
    It seems you have a point. More extreme after 1000 rounds of 1000 attempts the never changing token has been guessed for certain (100% chance) whereas the changing token may have escaped the guessing game.
    – Jeff
    Commented Jul 16, 2018 at 20:55

You must log in to answer this question.

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