ASP.NET storing encrypted & salted Password

Question

I have a question about storing encrypted passwords in your database to help secure them. I have a class that encrypts the password passed in and returns a string. This string has 3 parts too it, all separated by a colon. The first part is the iteration, the 2nd part of it is the salt, and the third part of it is the encrypted password. Ex: "1000:{salt}:{encrypted password}".

My question is how am I suppose to store this? As of right now, I am storing the entire string in my database under the password column. Then when I go to check the passwords for a login, I retrieve that record, and I have a method in my class that parses it and verifies that the two passwords match. Is this a big 'no no?' I've read where some people store the salt in it's own column then pull that down when verifying a login. However, this class that I am using for the encryption will return a string like I showed above. Then it came with a method that I can just pass that entire string into it and it will parse it up and verify the passwords as a login.

I guess what I'm asking is, do I need to re-construct my class to separate the string ("{iteration}:{salt}:{encrypted password}"), or is storing that entire string in the database OK?

Answer 1

What you do is how most are doing it, and it is perfectly fine.

The thing people say about not doing your own security is that you should not invent your own way of hashing the password. Always use a state of the art password hashing algorithm.

So store the hashed password including the individual salt and the number of iterations (which allows you to increase the number of iterations later if you need to) in the database.

Answer 2

While developing an application I was using an Encryption Library that had the same format {iterations}:{salt}:{PasswordHash}. It had 2 main methods public string GetPasswordHash (string PlainTextPassword) and public bool VerifyPassword(string formatedPaswordHash, string PlainTextPassword). Since GetPasswordHash returned and VerifyPassword expected a string in the {iterations}:{salt}:{PasswordHash} format that is how I stored it in the database. It was then a simple retrieve hash from DB, Pass to Verify method and not have any additional code to deal with.

I could have broken it up into 3 columns (Iterations, Salt, PasswordHash) but then I would just have to combine them again to verify adding a step that could introduce a bug. Since I would never manually update any of the parts I saw no benefit to storing them separate, especially when an attacker could break them apart or put them back together as easily as I could if they got access through a different bug.

Overall either way can be defended but I always tend to go with keeping things simple. If the library spits out a string from one method and expects a string in the same format to be passed into another method, why bother changing the format for storage if we are not going to manually update any of the individual parts.

The only big no no of encryption is to not roll your own GetPasswordHash and VerifyPassword. As long as those are strong, how you store things in the database becomes a secondary concern.