views:

511

answers:

5

Currently Many of my passwords are stored with a mixture of md5's and sha1's however I've just been introduced to salting, and wanted to know the breakdown of what might be the most secure.

I'm certin that a simple md5() can easily be revoked, however what about md5(sha1(md5($var))); Does this combo provide more difficulty, or is more not necessarily better.

Also, is doing

$var = $var.'t00lup';
md5($var);

more secure than the above, assuming t00lup is a private key?

Is there a better way of doing this instead of just using md5 or just using sha1?

Thanks

+4  A: 

More is not necessarily better. Just use Sha256 and be done with it.

$var = $var.'t00lup';
$hashedPass=hash('sha256', $var);

Read more about hash() here.

ryeguy
PHP does not support SHA-256
FractalizeR
Yes it does..it actually supports about 35 different hash algorithms. See here: http://us.php.net/manual/en/function.hash-algos.php
ryeguy
I mean it doesn't support it natively. Hash extension is neeeded
FractalizeR
The hash extension is part of the PHP core. See here: http://us.php.net/manual/en/hash.installation.php
ryeguy
+1 for the core support
RageZ
Well, it has been part of the core since 5.1.2. Other than that you can get it as a pecl extension. Regardless, this is a better option than using just sha1 or md5.
ryeguy
More IS better when it comes to password hashing: http://en.wikipedia.org/wiki/Key_strengthening
Michael Borgwardt
Is there a reason you wouldn't use sha512 then over 256?
Frederico
No, not really. Sha256 is good enough, but I normally choose it over sha512 simply because the hash is half the size, so you save some space in the database. You can use 512 if you wish.
ryeguy
More is better, in the sense of performing many (thousands) iterations of the chosen hash function. The time required for an attack increases (linearly) with the number of hash iterations performed.
erickson
A: 

VBulletin uses something like md5(md5($password).$salt). Seem to be ok.

FractalizeR
A: 

I think doing some salting improve security since it make dictionary attack more difficult and also even If the password is short the whole security level is still ok.

The most important things is really the hashing algorithm and the lenght of the resulting hash so you have better to look into sha256 or better.

RageZ
Also md5 have been proven to have collisions , two different input resulting same hash. And md5 is easily crackable with current CPU power so it is not advised to use it anymore
RageZ
ALL hash algorithms have collisions, it's not even possible to have a hash algorithm without collisions when the output has a fixed size. And MD5 is not really "easily crackable" - it has weaknesses that can be exploited in certain scenarios and therefore one should generally use better algorithms. But it's still not true that you can easily find a matching input for a given MD5 hash except through (somewhat improved) brute force and dictionary attacks.
Michael Borgwardt
+9  A: 

A couple things:

  1. Just use SHA256 - don't bother re-hashing.

  2. Don't just hardcode a single salt for every account. Generate a random salt for each user and put it on their user record in the database. That way if someone generates a rainbow table for that salt, at least they would only get access to that one user account rather than all of them.

Eric Petroelje
AH yes, fantastic. Thank you.
Frederico
+1 for generating a new salt for each person - many people misunderstand this.
ryeguy
Just use one hash algorithm, but repeat it thousands of times.
erickson
What about using an user ID (primary key in db table) as salt hash?
tomp
@tomp - that would probably be fine as well. The only reason I usually don't do that is because if you are using auto-generated user id's, you wouldn't have a user id at the time you create a user record. So it would require an INSERT to create the record, then a second UPDATE to set the password hash once you have the user id from the inserted row. Also, it essentially creates a dual-use column (it's both an id and a salt) which I try to avoid if possible.
Eric Petroelje
+3  A: 

Using a salt is absolutely required, because otherwise, an attacker can use existing precomputed tables to simply look up hashes for all short or dictionary passwords your users have used. You can try this yourself: take the MD5 of a very bad (short or dictionary) password and do a google search for the result - most likely you'll get a hit somewhere.

With a salt, existing tables become useless, and computing your own takes too long for all but the most resourceful and motivated attackers. Individual salts for each user are even better (otherwise an attacker who knows the salt can attack all your users at once).

Combining hashes could have a similar effect, but should not be used for that purpose (without a salt) because it's still possible for a precomputed table to exist for that combination.

However, the combination and repetition of hashes has a value of its own, by increasing the time it takes for an attacker to do a dictionary attack: applying MD5 ten thousand times still takes a fraction of a second and is feasible as part of the login process. But for a dictionary attack, taking 10,000 times as long is a problem.

This technique is known as key strengthening.

Michael Borgwardt
really nice answer!
RageZ