Using Rfc2898DeriveBytes for PBKDF2

DRAFT DOCUMENT - WORK IN PROGRESS

Password storage is a large topic in application security. If a security failure occurs, and the database is stolen, the passwords of the users are some of the most important data stored. Given the state of contemporary authentication, they do not need to be stored in plain text, so they should not. A hashed representation of the password, using a contemporary encryption algorithm and process, is the accepted way to store a password in today’s systems. More information can be found in the Password Storage Cheat Sheet[1].

Common .NET password storage

In .NET, the SQL Membership[2] or ASP.NET membership[3] patterns are often used for identity. In a best case scenario passwords aren’t stored by the local application or a well-known and trusted system is used such as AD, Facebook, or ASP.NET Identity. In each of these cases, the password storage is either handled by the subsystem, or not handled by the application at all.

Sometimes, however, there is no choice but to store the password in the application using home grown code. When this is the case, it is upon the software developer to select and use the correct hashing algorithm and process for password storage. Hashing is the process of deriving a unique, repeatable value form a text input and salt. This prevents the storage of the password itself, thus protecting the password if the database is stolen.

Hashes create unique values that cannot be reversed into their source values, however, brute force could potentially lead an attacker to the source values. As such, a key derivation function is often used to increase the work factor needed to create the representative value. Often this key derivitation function is PBKDF2, or the Password-Based Key Derivation Function 2[4].

PBKDF2 basics

PBKDF2 uses a pseudorandom function and a work factor to create a process for hashing a string. The benefit to using an algorithm like PBKDF2 is that the work factor can increase as the power of computing in the environment increases. Because brute force is used to crack hashes, making the process harder to reverse is the primary source of security in the hash creation process.

The details of PBKDF2 are openly published, and the goal of this document is not to replicate that information. Generally speaking, the function is one that accepts a pseudorandom function (such as SHA1), a salt, the number of iterations, the length of the resultant hash, and the text to be hashed. The goal is one of ‘key stretching’, making the overall process of generating or reversing the hash harder. The .NET Framework can abstract the details of the algorithm from the developer.

Implementing PBKDF2 in .NET

Microsoft’s .NET platform supports PBKDF2 out of the box. Rfc2898DeriveBytes allows a developer to generate a key for a value using PDKDF2 without implementing the algorithm. Using a number of iterations and a salt, a developer can easily implement the key stretching hash then store that data in the database. During registration, rather than storing the password entered by the user, you should store the password and salt. Guids provide a very strong salt, as while they are not cryptographically random, they are guaranteed unique. Rfc2898DeriveBytes[5] will generate a hash and return the derived key with the work factor. You need to store them both.

Here is an example of using the System.Security.Cryptography namespace in a simple method. It returns the salt and key in a pipe delimited string.

public static string HashPassword(string password) {

   // Generate a random salt
   byte[] salt = Guid.NewGuid().ToByteArray();
   // Generate the hash
   Rfc2898DeriveBytes rfc2898DeriveBytes = new Rfc2898DeriveBytes(password, salt);
   rfc2898DeriveBytes.IterationCount = 10000;
   byte[] hash = rfc2898DeriveBytes.GetBytes(24);
   //Return the salt and the hash
   return Convert.ToBase64String(salt) + "|" + Convert.ToBase64String(hash);

}

Note that a new Guid is generated for each request. Every record in the database has a stored salt and hash.

Another note is that related to work factor. In the Password Storage Cheat Sheet, it is recommended to make the password generation process as slow as possible without negatively affecting the user experience. Here, we have set the work factor to 10,000 and should review that number every year.

Using the hash on login

When a user later logs in, rather than using the password to confirm authentication, you can use the hashing function to generate a hash with the stored salt rather than a generated salt. Then compare the hash with the stored hash.

Limitations

The built-in .NET implementation of Rfc2898DeriveBytes limits the user to one psudorandom function - HMAC with SHA-1. This is acceptable in most scenarios today, but in the future, a more complex hashing function may be required.

The .NET Compact Framework does not support Rfc2898DeriveBytes.

References

• Password Storage Cheat Sheet
• SQL Membership
• ASP.NET Membership
• Rfc2898DeriveBytes
• Salted Password Hashing