Regarding hashing passwords .NET & Rfc2898DeriveBytes

I live outside the world of oAuth and need to hash passwords for authentication

For goodness sake don’t be tempted to write your own hash! Research the latest advise as it changes as machines and cracking advances. Swathes of passwords have been stolen from compromised sites in the past, and have been cracked and sold or given away. Don’t let your site be the source of misery!

Use well known hashing algorithm

Use the .NET class Rfc2898DeriveBytes that implements PBKDF2 for password hashing. This uses iterations to make it computationally expensive for any brute force attacks.

Use salt

To prevent attackers reverse engineering your users’ passwords using rainbow tables, and other colourful techniques, use the above class with a random salt per user hash. You need to store the salt in your data store, its ok to store it concatenated with password hash.

Use good random salt with high amount of entropy

Use a decent random generator such as that provided by the RNGCryptoServiceProvider  in the System.Security.Cryptography namespace to generate your salt, there are degrees of randomness, remember random is pseudo random in the random class in .NET.

Load the CPU with iterations

Choose a good number of iterations when generating the hash. To future proof your implementation, also store the number of iterations used to generate the hash against each user, with the hash and salt, in the data store. This makes it possible to “turn up” the number of iterations as machines get faster in the future and not “spoil” the existing hashes (obviously the hashes would be upgraded after login in this scenario).

Risks of Denial of Service (Dos)

Denial of Service, be aware that for this protection you are on purpose introducing a computationally expensive routine to the authentication methods of the site. This exposes a possible denial of service attack by bombarding the login method with authentication requests, some sort self healing technique to limit such an attack is required. Perhaps if high traffic is detected, temporarily add a capture to the login page to limit the DoS impact.

 

 

Add comment

Loading