How much stronger would this be:
return sha1($salt.sha1($passwd));
compared to just:
return sha1($salt.$passwd);
salt is a per-user strong 12 char with random ascii
views:
176answers:
3
+3
A:
At first glance, and without strong knowledge in crypto, I'd say it's not stronger at all.
By the way, it's usually advised to use
sha1($login.$salt.$passwd);
so that 2 users with the same password won't have the same hash.
Vinzz
2010-01-11 16:10:34
Including login name in the hash solves one problem but introduces another. Now the user cannot change his/her login because it would break the hash and the hash cannot be recomputed because we don't know the user's password.
Asaph
2010-01-11 16:13:13
dutifully noted, I'll keep that in mind.
Vinzz
2010-01-11 16:14:30
The solution to this is to generate per-user salts.
Will Vousden
2010-01-11 16:20:44
@Asaph - I'd say a major change like changing username should require them to enter their password to confirm, anyways. That way, it's available to you for recreating the hash, and another user can't change something so major as their username if they left their session open on a public computer.
ceejayoz
2010-01-11 16:25:47
Then use something unique like the user's ID in the database... Problem solved, user can change his/her name.
Boldewyn
2010-01-11 16:36:06
The very definition of salt is that it is random (random per user), so prepending the string with the login name is entirely pointless.
molf
2010-01-11 16:38:20
The "definition of salt" is not that it is random (or random per user), it is to make it harder to perform dictionary attacks by someone who has access to a copy of a hashed password database. How this is done (per user, or a single salt for a given DB) differs depending on the usage scenario. With regard to user specific information in the salt other than the username, you could use a constant, like a UID, for this purpose - though there is no intrinsic problem with two different users having the same hash value because they have the same password...
Iain Collins
2010-01-11 16:57:16
+1
A:
As far as I know there is no difference in strength.
Since it is common practice to prepend the salt to the password hash, the salt is generally known to an attacker. But this does not defeat the purpose of the salt.
It is generally speaking not a a good idead to add the $login/$username to the hash (Vinzz's solution) as it will cause problems if the user changes his or her username. A better solution is to use a random salt.
The used hashing algorithm does make a difference. SHA1 is considered cryptographically broken and should not be used to hash passwords.
Gennerally speaking BCRYPT (a Blowfish based adaptable-cost hashing algorithm) is considdered best to be the practice (CRYPT_BLOWFISH flag for PHP's crypt();)
Other solid options are SHA256 and above.
Edit:
I wrote a longer answer on salting here: stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/
Jacco
2010-01-11 16:20:18
+3
A:
It's exactly twice as strong, because the attacker needs to perform twice as many SHA1 calculations for a brute force attack.
Of course, that is still not exactly impressive. On the other hand, doing the SHA1 5000 times in a loop is practical for authorization, but makes attacks take 5000 times longer - this technique is known as key strengthening. It is, however, really just a poor man's substitute for the adaptible-cost hash algorithms that Jacco mentions.
Michael Borgwardt
2010-01-11 16:31:32
5000 times SHA1 is still quicker than the DB request that you need anyway.
Michael Borgwardt
2010-01-11 16:41:24