Towards more secure password hashing in ASP.NET

A couple of weeks ago I was remotely involved in a discussion on password hashing in .NET with @thorsheim, @skradel, and @troyhunt. (Follow them if you're on Twitter). The background for the discussion was that password hashing using MD5/SHA-1/SHA-256 isn't quite the state of the art anymore. All the recent password breaches have triggered recommendations to make password cracking harder. The algorithms that are usually recommended are PBKDF2 (Password based key derivation function), bcrypt, or scrypt. So which of these should you choose if you're working with .NET?

I'm a conservative guy. Cryptographic algorithms are very hard to get right, as there's all sorts of things that can go wrong when you implement them. Consequently, I prefer to use whatever is available in the .NET framework. That's because Microsoft have crypto-experts on staff, and they've also pioneered the SDL which means you should expect high quality implementations of their (security critical) software. So it's really a trust thing. At the time of writing, PBKDF2 is the only algorithm of the three mentioned that's readily available in the framework. You probably see where this is leading: bcrypt and scrypt are disqualified in my book. When it comes to cryptographic functions, stick with the framework! PBKDF2 is the best alternative for now.

Following the discussion on Twitter, @skradel shared a library where he had wrapped the built-in PBKDF2 as a HashAlgorithm. That way, PBKDF2 (through his wrapper) could easily be used by other parts of the framework, such as the SqlMembershipProvider. It really was an elegant solution. He blogged about it in: Strong Password Hashing for ASP.NET, you should check it out (@thorsheim was so delighted that he had to blog about it too :).

When you're dealing with PBKDF2, you'll see that it takes a couple of parameters. @skradel's already chosen some reasonable defaults in his implementation so it's all hidden and taken care of there. But if you were to implement this yourself and explain to someone how you chose those parameters, what then?

I couldn't find much guidance on the Internet so I started digging into the PBKDF2 standard to find out more.

PBKDF2 parameters
The PBKDF2 is backed by H-MAC-SHA-1 which is a keyed hash function (see HMAC). The supplied password is used as the key, while the salt is used as the input text, concatenated with a block identifier. The whole idea behind PBKDF2 is to introduce a drastic increase in the workload for a password cracker. In the default setup, H-MAC-SHA-1 is run a 1 000 times to generate the output for a password. This is a negligible workload when you're checking that a user entered the correct password. However, for an attacker running an offline attack with a password cracker that needs to try millions of passwords the extra workload really adds up and slows down the attack significantly.

Next, there are a couple of things to take into consideration when implementing PBKDF2 password.

• It requires a salt that's at least 64 bit (8 bytes)
• You can select a number of iterations (1 000 is the default)
• You must choose how many bytes to output
• You need to be sure you encode your passwords correctly (remember how not to hash?)

So, how long should the salt be? I have found almost no guidance on the length of the salt, except for a note on the Rainbow table article on Wikipedia. Considering that the salt's only job is to introduce uniqueness to the calculation and that it's not a secret, I cannot see why a 64-bit salt should not get the job done. Do note that the SqlMembershipProvider uses 128-bit salts, and that's also what's used in bcrypt. So you might just do like the big boys do and go with a 128-bit salt. What's more important is how you generate a salt. You should use a cryptographic RNG for that. I've included an example at the very end of the code samples that does exactly that.

You'll also need to decide on how many iterations to use for the calculation — and now we're getting to the core of the issue. The number of iterations dictate the workload, which is the whole point of using PBKDF2 to begin with. So the recommended setting is: "as high as possible." To maximize this you'll have to test how many iterations you can run before it would become a noticeable delay for the user and hence start to effect the user experience negatively. This of course depends on the hardware you're running so you'll probably need to do some benchmarking here.

Then there's how many bytes to output. The standard gives us some useful hints here:

Thus, even if a long derived key consisting of several pseudorandom function outputs is produced from a key, the effective search space for the derived key will be at most 160 bits. Although the specific limitation for other key sizes depends on details of the HMAC construction, one should assume, to be conservative, that the effective search space is limited to 160 bits for other key sizes as well.

There it is. You'd want the largest effective key space, nothing more, nothing less. That means that you should generate 160-bit (20 bytes) of output. Remember that the security is still bound by the randomness of the passwords used. Password entropy is often used as a term to describe the complexity involved in guessing a password. Have a look at that last link, and you'll see that to have the "guessability" of the passwords match the limits to PBKDF2's output (i.e. 160-bit password entropy), users would have to choose truly random passwords that where 27 characters long, assuming you accepted alphanumeric case sensitive passwords (a-z,A-Z,0-9). As you probably know, users tend to select passwords that are not very random and that are much shorter. So rest assured that it's the passwords that will be killing you here, not the security of PBKDF2.

Rounding of, I have to remind you to use a proper character encoding when translating the passwords to bytes that can be input to the PBKDF2 function (see the sample code). If you feel like giving the passwords' ASCII bytes to PBKDF2, go read How not to hash passwords in .NET instead. That's really important.

And remember also, PBKDF2 is NOT a silver bullet. The RFC puts it quite well:

Password-based cryptography is generally limited in the security that it can provide, particularly for methods [...] where off-line password search is possible. While the use of salt and iteration count can increase the complexity of attack [...], it is essential that passwords are selected well, and relevant guidelines [...] should be taken into account. It is also important that passwords be protected well if stored.

So there. That was my advice on how to set up PBKDF2 when used to hash passwords. If you have anything to add to this please leave a comment. I'd appreciate that.

Appendix: A demonstrational PBKDF2 implementation.

To figure out how PBKDF2 actually works, I implemented it. Here's the source code, which maps rather directly to the steps outlined in the RFC. I wrote it for demonstrational purposes, so it's not optimized or anything. So I hope it's understandable.

Disclaimer: DON'T use this PBKDF2 implementation for anything other than demo purposes. As I demonstrated earlier in this post, PBKDF2 is available in the .NET framework, you should use that instead.

using System;
using System.Text;
using System.Security.Cryptography;
using System.IO;

namespace PBKDF2Example
{
    class PBKDF2_demo
    {

        static void Main(string[] args)
        {
            var enc = Encoding.GetEncoding(Encoding.UTF8.CodePage,
                new EncoderExceptionFallback(),
                new DecoderExceptionFallback());
            var password = enc.GetBytes("passwordPASSWORDpassword");
            var salt = enc.GetBytes("saltSALTsaltSALTsaltSALTsaltSALTsalt");
            var iterations = 4096;
            var keylength = 25;

            var result = PBKDF2(password, salt, iterations, keylength);
            Console.WriteLine(BitConverter.ToString(result));
            Console.ReadLine();

        }

        static byte[] PBKDF2(byte[] password,
            byte[] salt,
            int iterations,
            int derivedKeyLength)
        {

            var hashLength = 0;

            using (var hmac = new HMACSHA1())
            {
                hashLength = hmac.HashSize / 8;
            }

            //Our number of blocks
            var length = (int)Math.Ceiling(
                ((decimal)derivedKeyLength) / ((decimal)hashLength));

            var derivedKey = new byte[derivedKeyLength];
            using (var ms = new MemoryStream())
            {
                for (int blockIndex = 1; blockIndex <= length; blockIndex++)
                {
                    var block = CalculateBlock(password, salt,
                        iterations, blockIndex);
                    ms.Write(block, 0, block.Length);
                }
                ms.SetLength(derivedKeyLength);
                return ms.ToArray();
            }

        }

        static byte[] CalculateBlock(byte[] password,
            byte[] salt,
            int iterations,
            int blockIndex)
        {
            var blockBytes = BitConverter.GetBytes(blockIndex);
            if (BitConverter.IsLittleEndian)
                Array.Reverse(blockBytes, 0, blockBytes.Length);

            byte[] u1;
            using (var hmac = new HMACSHA1(password))
            {
                var firstInput = new byte[salt.Length + blockBytes.Length];
                Array.Copy(salt, firstInput, salt.Length);
                Array.Copy(blockBytes, 0, firstInput,
                    salt.Length, blockBytes.Length);
                u1 = hmac.ComputeHash(firstInput);
            }

            byte[] lastvalue = u1;
            byte[] newvalue;
            byte[] result = u1;
            for (int i = 1; i < iterations; i++)
            {
                using (var hmac = new HMACSHA1(password))
                {
                    newvalue = hmac.ComputeHash(lastvalue);
                    for (int j = 0; j < newvalue.Length; j++)
                        result[j] = (byte)(newvalue[j] ^ result[j]);
                    lastvalue = newvalue;
                }
            }
            return result;
        }

        //Returns 128-bit salt
        static byte[] GetNewSalt()
        {
            var salt = new byte[16];
            using (var rng = RNGCryptoServiceProvider.Create())
            {
                rng.GetBytes(salt);
                return salt;
            }

        }

    }
}