I am using the ASP.NET password hashing code example provided in this article. Its using 32 bytes RNGCryptoServiceProvider instance for Salt and SHA256Managed instance for hashing.
- Do you see any issues with the approach described here to be used in production environment.
- I don’t understand what is the need of BytesToHex method and also why "x2" is appended there. Any ideas?
- If i want to store this hashed password (retunred by HashPassword method) in SQL Server database, what data type should be used. A CHAR(128), VARCHAR(128) or something else with pros and cons of each approach.
TIA
Ok first let’s talk about the hashing. First you should know simple Hash(Salt+Password) can be cracked easily enough when people use common passwords. So a salted hash alone generally doesn’t buy you much time before they’ve cracked a large percentage of you’re user’s passwords.
Scenario: Let’s say it takes you 24 hours to notice a breach was made. Many accounts will already be compromised in this short window. You reset all user account passwords, the users are safe now right? So you send emails to all your users informing them of the breach and advising them to reset their password. The trouble is those silly users have been using that password around the internet for some time, the same password for their bank, email, etc. So even after you stop them accessing your site with the stolen passwords the user may have other accounts they must reset. So let’s say it takes another day for them to receive the email and reset their passwords. How do you buy more time for user?
The answer is PBKDF2. This adds a large volume of complexity to the hash so that each test of each password takes thousands of times longer than a simple salted hash. To accomplish this in .NET one uses the Rfc2898DeriveBytes class. See a working example by reading: “Another example of how to store a salted password hash“.
No reason I can think of.
Acutally raw bytes works best, Base64 is also worth considering if you want to store it as text.