2

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?

4

2 に答える 2

1

クライアントが常に同じパスワードを送信する場合、単にSHA1ハッシュを使用すると、SHA1ハッシュ出力すべての目的と目的のパスワードになります。PBKDF2、SCrypt、BCryptなど、他のパスワードと同じように扱い、保存します。

于 2012-10-26T11:27:42.143 に答える
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.

于 2012-10-25T20:42:30.900 に答える