ASP.NET Identity Account Lockout

By -
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

Post a Comment

Popular posts from this blog

IIS Express Client Certificates

By -
We recently had to investigate how to  CAC -enable a web application, one of the challenges was setting up a proper development environment to prototype & test code changes before deploying to other environments. STEP 1  - You need to have a client certificate installed on your development machine. Assuming you don't have a readily available CAC or Smart Card, you can either  create a self-signed certificate  OR for this example we just used a  corporate outlook email client certificate (used to sign & encrypt emails).   Note : The certificate should be available in your web browser. For IE go to  Internet Options > Content > Certificates  to view all your certificates. In Chrome, go to  Settings > Show advanced settings > HTTPS/SSL > Manage certificates . STEP 2  - Using Visual Studio, create a default ASP.NET MVC 5 web application. STEP 3  - Enable SSL for your project. In Visual Studio, hit  F4...
Read more

ASP.NET Identity Remember Me

By -
ASP.NET Identity comes with a built-in Remember Me feature on the Login form, it's supposed to keep a user logged in (via an authentication cookie) for a predetermined period of time set via your code settings. However it sometimes might not work as expected and users will have to frequently log in which will cause quite a bit of frustration. Your first reaction is to modify your code then test / rinse / repeat and possibly still see the same unsuccessful results ... did you also check your website's IIS settings? Code Settings Let's first take a look at the Code configuration settings. If you create a new default MVC 5.x application in Visual Studio (with Authentication set to  Individual User Accounts ) the following code is generated (in  /App_Start/Startup.Auth.cs ): app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, LoginPath = new PathString("/Account/Login"), Provi...
Read more

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

By -
Image
Use Case Typically, when you enable CaC/Client Certificates on a web app you enable it for the entire app. But what if you wanted to disable it for certain sections of the site. For example, an API controller, or a specific Area that hosts pages that can be publicly viewed. Luckily, it's very easy to make this happen. I'll walk through an example that requires CaC authentication for the base app but does not require it to make requests on an API controller, which will use leverage the HTTP Authentication header for auth.  1. Modify the web.config To require client certs for the base app, add this snippet inside the <system.webServer> tag. <!-- Access for the Base App --> <security> <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert" /> </security> Now we can selectively disable client certs for specific sections of the app. In this case, I am disabling it for all routes starting with /api/v1 ....
Read more