ASP.NET Identity Account Lockout

ASP.NET Identity 2.1 comes with the infrastructure to support varied authentication from the complex two factor to the simple username and password. It also has the ability to enforce rules on sign in to keep account information secure. One feature that comes with out of the box identity but is not enabled by default is lockout. The behavior of the feature is straightforward: a series of incorrect passwords supplied for a given account will force the user to wait a penalty period before attempting to sign in again. This feature needs to be configured the right way to both prevent phishing for user accounts but to also not inconvenience legitimate users who may have mistyped their password a few times in a row.

The first step to enabling this feature is to make some changes to your user manager. Below are 3 properties of the user manager that I am setting in the initialization for the class.


The first property is one that is repeated in several of the classes we will look at and goes by different names. In this context, this field means that a new user will be set up as a user that can lockout. This does NOT mean that a user is locked out by default. Instead, this allows you two have different types of users. This means that you could, for example, disable lockout for admin accounts or another special subset of users.

The second property is the duration of the lockout. When the sign in manager (something we will look at shortly) determines that a user is in violation of the consecutive password attempt policy, it will use this timespan to determine when the user will be allowed to sign in again. An important note: this is not a sliding window. Any login attempts (valid or invalid) during a lockout penalty period will NOT extend the window that the lockout ends. If you want to override this default behavior and create a sliding window, you’ll need to extend and override the sign in manager class. You will need to alter the LockoutEndDateUtc property on the user table every time an incorrect password is entered when in a locked out state within the sign in manager’s PasswordSignIn[Async] method.

The final property is the number of consecutive incorrect attempts needed to trigger a lockout. By default, successful sign-ins do NOT reset the incorrect attempt counter. If you wish to zero out this count after a successful login, you should call the user manager’s ResetAccessFailedCount[Async] method during your login action when the login is successful.


The other piece of setup you’ll need is how you sign a user in. If you started a project with Identity out of the box, you should see the following in your account controller.





It comes with a comment explaining that you need to set shouldLockout to true to trigger account lockouts. As I mentioned before, this flag really means a user can lockout, despite the rather vague name. So, if you set the flag in this method, the sign in manager should take care of the rest, obeying the rules you supplied in the user manager earlier.

One final implementation note: this framework works by unlocking accounts after time spans. If you are worried about the security of accounts and their data, you may want to enforce other methods of unlocking on the user besides simply waiting out the penalty period. To start, you’ll want to set the lockout span to something on the order of years instead of minutes. By doing so, you will force the user to reset their password, which by default will unlock an account. Additionally, you can make an admin function that clears out the LockoutEndDateUtc field and uses ResetAccessFailedCount (two things discussed earlier) to instantly remove the locked out state of the given user.


Thanks for reading!

Comments

Popular posts from this blog

ASP.NET Identity Remember Me

IIS Express Client Certificates

ASP.NET MVC - How to enable/disable CaC/Client Certificate authentication per area or route.