Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Some sites lock me out for a while after too many failed attempts.
For our own site, we want to force a password reset email after X amount of failed attempts. After all, if your email is compromised, then everything is compromised.
Further advantages: we don't stop the user in their tracks.
Am I missing something?
You assume that they would have access to their email. That ties access to your site to their access to their email. Loss of access to email can be more than a compromised email account. You could, in fact, be stopping the user in their tracks by assuming that they would have email access.
This might be fine, depending on the criticality of your site, but you have to make this choice mindfully and consider the impact.
Other options are
For our own site, we want to force a password reset email after X amount of failed attempts. After all, if your email is compromised, then everything is compromised.
How do you infer that the "email is compromised" ? A more reasonable approach to brute force attempts is to ban the offending IP address for a while, that's what tools such as Fail2ban do. There is no reason to restrict the account of the victim.
If someone is trying to brute-force your account, it shouldn't cause inconvenience to you, like forcing a password reset upon you, which is most likely pointless since the attempt was unsuccessful.
If you were to implement such a "security feature" this could even turn to a form a DDOS against yourself: if a bot is continuously brute-forcing your account and forcing a password reset every time, this could deny you the ability to log in to the site.
On the other hand, being notified of repeated failed attempts is a good thing.
When it comes to the security of this solution, it is slightly better than timeouts because if the attacker has an idea what the password might be, but doesn't get it in X tries, the user will be notified.
But it might make UX way worse. If the user has 1 password for all their applications (often the case) and has to reset it due to a small typo (different keyboard, caps lock on), that would be annoying.
When it comes to the UX of this solution. You need to think about the user type:
Depending on how the app will be used and how often users will log in, the solution should follow, but this is UX.
I'd personally like to choose if I want to reset or wait after X failed attempts (I'd also want to be notified if I decide to reset).
