Question

A client program (over which I have no control) is authenticating by sending me a password, hashed as SHA1(password).

I’m reluctant to store the password hashed using only SHA1 in my database, so I’m proposing to store passwords in the database hashed as SHA256(SHA1(password)) (where the password is hashed over multiple iterations using PBKDF-2 or something similar).

My question is: is there anything insecure about the inner-most hash using SHA1 in this scenario? I realise that the probability of collisions will be increased, but since this is just for storing passwords in the database I don’t think I need to be concerned about that. Is there anything else that I’m missing?

Answer 1

Consider adding a salt which is unique-per-row before doing the final encryption. Example:

Lets say that you receive W6ph5Mm5Pz8GgiULbPgzG37mj9g= (a SHA1’d encryption of "password"). That is associated with a User, who should have a unique key, such as a UserID and/or UserName.

My suggestion – to avoid collision – would be to do a conversion of the Bytes to a Base64String (in C# this would be Convert.ToBase64String( byteVariable ) – then concatenate onto the string the user’s unique-ID (making the new string something like:

W6ph5Mm5Pz8GgiULbPgzG37mj9g=+103 (where I added +103 to reflect the user’s ID) – then apply your SHA256 algorithm. This will produce: mNXRjWsKJ7V+BHbAuwJJ7neGT+V1IrLQSQXmb4Vv1X8= – which you can store in your database. A SHA256 hash – which eliminates the collisions from the less-safe SHA1 algorithm.

And – since you are using 1-way encryption – when you go to check whether the password is valid in the future, you simply append the user’s ID again before checking.