6

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?

kelunik
  • 161
  • 4
  • 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 Apr 13 '16 at 14:34
  • 1
    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 Apr 13 '16 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 Apr 13 '16 at 14:47

1 Answers1

7

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.

Jeff Meden
  • 3,966
  • 13
  • 16
  • 2
    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 Apr 02 '17 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. – AndrolGenhald Jul 16 '18 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 Jul 16 '18 at 20:55