TOTP follow-ups: automated lockouts, email notifications, exponential backoffs

[ewjoachim]

In #8456, we mentioned a lot of ways TOTP could be made more secure:

• We could send an email notification every time the 2FA (TOTP or not) is wrong (because it should happen quite rarely, unless there's an issue with the clock synchronisation, the user waited too long to input the code, made a typo, or uses the wrong hardware key. An email is certainly warranted (it's just an email). And if the user didn't try to login, they know their password was compromised. More so if they have multiple emails.
• Automated lockout after a sufficient number of TOTP failures.
  • In terms of attack surface, it would mean that if the attacker has the user's login and password, but no access to their email, and they tried to bruteforce TOTP, they'd likely lockout the user's account after a few tries. The email the user would receive would let them know that something's off, and in order to unlock their account, they'd likely need to change their password, which would prevent the attack
  • In the attacker has compromised the user's email, though, this wouldn't help. The attacker could automate rotating passwords every time the account is locked out and eliminate the email to hide their traces.
  • If the user has lost access to the TOTP seed, then they will still need to do the 2FA recovery procedure. We wouldn't disable 2FA or anything. Just lock down the account.
• Increase TOTP failure backoff wait, make it exponential (1s, 2s, 4s, 8s, 16s, ...)
  • The problem with this approach is that in case a user's password is leaked, attacker can't connect but they can also keep the user from connecting. After the backoff reaches, like, a 10m wait, it's relevant to lock the account out. Also, when the password is reset following the account lockout, we should remove the backoff wait.
  • In case the email account is compromised, though, that means the attacker may change the password, then try a code, then change the password etc. We should limit to, like 15 password chances per day to ensure this strategy is not feasible.

See discussions in the other ticket for relevant details