Last post Jul 15, 2020 05:40 AM by Evern
Jul 11, 2020 03:22 PM|simongoldstone|LINK
I'm looking for advice regarding this scenario:
We have an Asp.net core MVC application that uses the built-in Identity feature. Everything is working great: Account management, password changes, resets, lock out, etc.
If somebody attempts to log into a user account 20 times over 5 minutes, the built-in lockout feature is triggered.
As soon as this happens, the real user will receive a notification email telling them that their account was locked out for 5 minutes.
During this lockout period, the real or fake user can perform a password reset. Obviously, only the real user gets the email. When the real user receives their email, they are able to reset their password. However, they are not allowed to log in for the
remainder of the 5 minutes.
This feels wrong from a user experience point of view, but I'm very aware of not changing the Identity workflow too much.
It seems to me we have these choices:
Use the current spec. You can reset your password during lockout but still cannot login.
The process of resetting your password also unlocks your account. (Change to the current Identity workflow)
Switch off the forgotten password feature during account lockout. Of course, we won't know the email address until they try, so there would have to be an error message AFTER they have attempted to change their password.
Switch off the password reset feature during account lockout. This means the real user will receive the reset email but when they click the link they'll be told to wait for 5 minutes.
I feel that only (2) and (3) are suitable from a UX point of view, but (2) feels less secure (but I don't know why).
I'd really appreciate advice/guidance on this. UX is important, but security is paramount. I'd also happily examine alternative suggestions.
Jul 15, 2020 05:40 AM|Evern|LINK
I think the third case is feasible. When the user enters the password twenty times, it is still incorrect. There may be a risk of the account being tested. You can disable it for one minute when the user enters the fifth password is still incorrect. At the
same time, you can tell the user to change the password by email, and then continue to time. When the user continues to enter the input twenty times and it is still incorrect, there may be a risk of the account being attacked at this time, so it should be