Securing password before storing in database

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.

1. Do you see any issues with the approach described here to be used in production environment.
2. I don't understand what is the need of BytesToHex method and also why "x2" is appended there. Any ideas?
3. If i want to store this hashed password (retunred by HashPassword 开发者_C百科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

---

1. There isn't anything really wrong with the implementation as shown. And the real hard problems here aren't necessarily properly hashing things as properly managing accounts so there isn't a hole somewhere. In any case you probably using the built-in membership providers for most cases -- there typically isn't a good reason to roll your own.

2. The .NET crypto stuff handles bytes, and most other systems spit out hexidecimal representations of these bytes -- look at the PHP examples. The BytesToHex method's job is to make this conversion. Using the "x2" in the ToString method tells the bytes what format to use -- in this case Hexidecimal. See the documentation for a deeper explanation.

3. See #1 first. Personally, if I was rolling my own, I would use a VARBINARY or BINARY and not make the text conversion -- it is a wasted step as .NET wants to treat it as a byte[] anyhow. If you want text, and you were sure you were never changing your encoding or hashing method, then I guess CHAR(LENGTH_OF_HASH) would be the most efficient storage option.

---

Do you see any issues with the approach described here to be used in production environment.

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".

I don't understand what is the need of BytesToHex method and also why "x2" is appended there. Any ideas?

No reason I can think of.

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.

Acutally raw bytes works best, Base64 is also worth considering if you want to store it as text.