How to Use More Iterations to Slow Down Password Crackers

How to Use More Iterations to Slow Down Password Crackers

With data breaches constantly in the news, it is prudent to prepare for the worst. Hopefully you won’t be next, but there are some simple things you can do now that will help protect you if your users’ accounts are ever leaked.

I assume you are reading this because you are still keeping your password hashes in a database somewhere. Generally it is a much better idea to have a company that specializes in authentication and security to keep that important information for you. After all, if you don’t have your user’s password hashes, you can’t loose them! But if you haven’t started using an OpenID Connect identity provider yet, then you certainly should be doing your best to guard your user’s credentials.

Password cracking has become an advanced art, and many cyber criminals are using advanced hardware that can perform millions of guesses a second against a weak hash. Your goal (aside from protecting your data), is to make the potential attacker’s job of cracking your users’ passwords slow and expensive so that it isn’t worth the effort. The best thing you can do it to educate your users to use long, random passphrases to make the password cracker’s job millions of times harder. If you are are using ASP.NET Core Identity, there is there is also a simple configuration setting you can control to significantly increase the effort required to crack your users’ password hashes.

If you use the default template for a new ASP.NET Core web application with individual user accounts, you will find the identity system configured like this in Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    ....
    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores()
        .AddDefaultTokenProviders();
 
    services.AddMvc();
    ....
}

The details of the password hashing are hidden away, but they are configurable. The default password hasher for ASP.NET Core Identity uses PBKDF2 with HMAC-SHA256, a 128-bit salt, a 256-bit subkey, and 10,000 iterations. Those are excellent choices, except for the number of iterations. The more iterations, the longer it takes to compute the hash, which means that more time and money are required for anyone to crack the hash. So you should set the iteration count to the maximum value your hardware can handle without noticeably affecting performance. I’ll show you how to calculate that in a moment–but first, in order to change the default, add this anywhere in the ConfigureServices method:

    services.Configure(options =>
    {                
        options.IterationCount = 99999; // TODO: Use a value calculated for your hardware 
    });

Now how do you know how many iterations to use? To answer this, you need to know how fast your hardware can verify passwords and how many users you need to authenticate per second. I have created a simple console app that will calculate the value for you. Just clone the GitHub project, build it (using the Release configuration), and run it on the server that will be handling authentication. You will probably find that your server can handle a lot more than 10,000 iterations for your use case.

Now that you’ve got that fixed, be sure to check out other ASP.NET Core Identity security settings that you should consider in order to secure your site.

Leave a Reply

Your email address will not be published. Required fields are marked *