views:

230

answers:

5

Hi,

After knowing that hashing a password is my choice for making a login form. Now I am facing another issue - sha1, sha256 or sha512?

This is a standard method using salt I think I got it from a reference book of mine,

# create a salt using the current timestamp
$salt = time();

# encrypt the password and salt with SHA1
$usr_password = sha1($usr_password.$salt);

but then after I have done some research on sha1, it was told it may not be so secure in the future, suggesting using hash().

But I don't quite understand using hash() - for instance -

$usr_password = hash('sha256', $usr_password); 

what is that 'sha256' or 'sha512' which I found it here?

http://hungred.com/useful-information/php-better-hashing-password/

can I put anything instead, like '@123'?

why is it called salt anyway - $salt = time(); is nothing else but just a unix timestamp isn't it?

thanks!

+2  A: 

sha-256 is a more modern hash algorithm than sha1 and is more secure. It belongs to the family known as SHA-2. If security is important to you than I would recommend using SHA-256 or even SHA-512 instead of SHA-1.

In 2005, security flaws were identified in SHA-1, namely that a mathematical weakness might exist, indicating that a stronger hash function would be desirable. Although SHA-2 bears some similarity to the SHA-1 algorithm, these attacks have not been successfully extended to SHA-2.

Mark Byers
I believe sha-2 refers the family of hashes sha-224, sha-256, sha-384, and sha-512
GregS
@GregS: Yes, that's right. I've reworded my answer to make that clear.
Mark Byers
+1  A: 

PHP's sha1 function does what it says, it generates a SHA1 message digest from your input.

The hash function is more generic, and the first argument you give it, like "sha256", tells it to use that algorithm to generate the hash from your input. You could also pass it another algorithm name such as "md5", "sha512", or "ripemd160".

More information: http://www.php.net/manual/en/function.hash.php

You can get the list of supported hash functions you can give to hash by using the hash_algos function.

I will agree with Mark Byers - SHA-256 is probably the minimal hash function you want to use due to vulnerabilities in the SHA-1 algorithm. Similarly, do not choose MD5 (an unrelated hashing algorithm) because it is trivial to break.

Salting is a good practice as it helps prevent rainbow table attacks.

birryree
+2  A: 

See Comparison of SHA functions: SHA-256 and SHA-512 are newer versions of the algorithm with larger hash sizes compared to SHA-1, and hence believed to be more secure.

The salt is just an additional piece of random data that is added to the original string in order to make attacks even more difficult. Even if two people have the same password, for example, but different salts, the hashes will be different. Using $salt = time() makes it reasonably random because the time keeps changing, but if you want even better security, consider using a random number generator such as mt_rand. More about salts at Wikipedia.

casablanca
The main reason you want your hashes to be different, is that otherwise people can reverse-crack hashes with so called Rainbow-tables. The original password belonging to a Sha1, MD5 and such, hash, are hard to find: with pure computer power it is possible. However, simply generating a list of all words known (and its variation) and creating a hash for each such word is is simple. Resulting in so called rainbow-tables where one can look up the password that goes with an (unsalted!) hash.
berkes
+1  A: 

You should use SHA-2 as flaws have been found in SHA-1.

SHA-2 has different types. The bit values you state (eg 256 and 512) are the more popular ones. Either one should be good for password hashing. However, SHA-512 can be preferred the time it takes to hash is not an issue.

You want to salt hashes as someone may use rainbow tables to look them up. As you know, hash values will always have the same value for the same input. If your users use a short password, it would be easy to test all of the combinations.

You should pick a salt and it should always stay constant. You can use a time value (a unix timestamp, the number of seconds since 1970) to come up with your salt. I'd also suggest adding a few more random characters. You then use the salt everywhere you use the password. The salt serves to make even short passwords long (secure).

Cromwell
Naughty. Never reuse a salt. Never choose a predictable salt (e.g. from a timestamp). A salt should always be as random as you can get, and used only once. If you salt 350 different passwords, you should have 350 different salts. If someone changes their password 293 times, you should generate 293 salts, one for each password.
Slartibartfast
A: 

If you are using salts, you should store those too, so you can recombine the password with the stored salt, and checks those against the hashes. This is done in case the hash is stolen or becomes public in some way. Dictionary attacks like rainbow tabling is then uneffective.

for example: in case some sql injection funerablity exposes the table containing the hashes, a malicious user could try to match all words in a dictionary of commonly used passwords, and possibly discover some users passwords. This won't be possible if it is a hash of a commonly known password combined with an unknown salt.

Even if the salts would be exposed, it still means all dictionary items should be combined with all salts.

Martijn