tags:

views:

370

answers:

5

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);

have a nice day

+6  A: 

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.

molf
"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.
rick
@rick, sorry for not being clear. I meant the input strings are longer.
molf
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.
deamon
@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".
molf
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.
Rupert
@Rupert, hashing does not increase entropy.
molf
+1 to molf. You cannot create more entropy from less entropy, just as you cannot create matter from nothing.
Forest
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)
GC
A: 

As long as the salt is different for each user, that's fine.

Ian
+1  A: 

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.

Laodimos
A: 

Your salt should not be easily guessable. In one of it's more basic forms, you could simply create a salt based on the current TIMESTAMP using

   date('U')

which is far more secure due to its length, uniqueness, and the fact that you store it in the DB and don't make it publicly available. You would then utilize it in such a manner:

$hash = date('U');
$pass = hash('sha256', $hash . $password);

and as far as checking passwords on login:

// return query object based on matching email/username
if ($userobj->pass === hash('sha256', $userobj->salt .$_POST['pass'])) {
    // correct pass
}
cballou
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.
Ian
@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?
cballou
@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.
rick
A: 

I don't think that is a good choice: I would use a more random salt saving it into the user record. Maybe saving in the password field this string: sha256($password . $randomSalt) . '$' . $randomSalt

This way you can then retrieve the salt to check the passoword on login.

(Anyway you can also use another field for the salt alone)

Andrea Zilio