using sha256 as hashing and salting with user's ID

Question

I'm gonna use sha256 for my site,to secure my users passwords,and as salt i was thinking of usings the users id (int auto_increment). that will be unique but not very long and hard,and public(user.php?id=1) but it just matters if its unique right?

hash('sha256', $id . $password);

Solution 1

Yes, it is important that the salt is unique (collissions sufficiently unlikely), but it should also have enough entropy (be random and long enough). User ids are not random and may be too short, so your best bet is to use randomly generated strings and store them in your database alongside the hash.

Suppose a user with UID 9 chooses a stupid password: password. The resulting string that will be hashed may then be 9password. You can imagine that even in this case, the full string may appear in rainbow tables (tables which contain lots and lots of hashes with their original string).

If the salt in this case would be, for example, OTAzMzYzODQzMjk5NTM1NDc1N, the string to be hashed is OTAzMzYzODQzMjk5NTM1NDc1Npassword, which is a lot more unlikely to appear in rainbow tables. Also, the input strings are a lot longer, reducing the risk of brute force attacks.

Solution 2

This would work but the purpose of using salt is to differentiate the hash key to strengthen the crypt algorithm. It would be much better to use a unique, random generated / time salted string for salt. Also it would be better not to include the salt and hash key in the same table.

Comments

[Ian]

Salting your database isn't meant to make the password more secret, it's supposed to stop a hacker that has obtained your hashed password from being able to use a rainbow table to hack the hash. Even if he has the salt and password hash, it's still very difficult to get the password.

[Corey Ballou]

@Ian - And to prove my own point, wouldn't obscuring the password hash with a salt be accomplishing just that? Making the password more secret?

[rick]

"Also, the hash strings are a lot longer". I'm pretty sure sha256 creates a 32 byte string regardless of the number of input characters.

[molf]

@rick, sorry for not being clear. I meant the input strings are longer.

[deamon]

It is not so important that the salt is unique. The purpose of the salt is to protect simple passwords. This can be achieved even if all passwords in a system are salted with the same value. It is more important that the salt is a random value and has enough characters.

[molf]

@deamon, if the salt is not unique your password hashes leak information, because different users with the same password (and same salt) will also have the same password hash. Not good. Collisions are no disaster, but it's a risk to use a system-wide "salt".

[rick]

@Ian - with the salt a rainbow table can be created providing the attacker guesses the encryption algorithm and how the salt is appended to the password. If the original password is weak, it will be uncovered.

[Rupert Madden-Abbott]

To increase entropy, would it make sense to hash the salt and password individually and then hash the hashes? Then a secure salt could be generated from intuitive pieces of data such as UID.

[molf]

@Rupert, hashing does not increase entropy.

[ʇsәɹoɈ]

+1 to molf. You cannot create more entropy from less entropy, just as you cannot create matter from nothing.

[GC.]

In this case, with only one system-wide salt, two users with the same password will not have the same hash - as long as you include the user ID as well: ($id.$password.$salt)

[aero]

Another benefit of this method is that the date is know in advance before the INSERT of the user (as opposed to auto-incremented id). This way you can do the hash server side at the same time as you create the user. This is good since you usually cant do sha256 in sql and don't want to roundtrip to the server again risking a user without any password!