4

How much stronger would

return sha1($salt.sha1($passwd));

be compared to just:

return sha1($salt.$passwd);

$salt is a per-user string of length 12 consisting of strong random ASCII.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Tomek Wojtek
  • 41
  • 2
  • I might be mistaken, but why should the hash of a password be any weaker than the hash of a hash of a password? That is, as long as the hashing algorithm does what it advertises. And if it does *not*, then you shouldn't use it at all, however often. – Boldewyn Jan 11 '10 at 16:33
  • rainbow tables (http://en.wikipedia.org/wiki/Rainbow_table) – Mr. Boy Jan 11 '10 at 16:36

3 Answers3

4

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
  • 342,105
  • 78
  • 482
  • 720
3

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
  • 3,968
  • 6
  • 36
  • 51
  • 5
    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 Jan 11 '10 at 16:13
  • 3
    The solution to this is to generate per-user salts. – Will Vousden Jan 11 '10 at 16:20
  • 5
    @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 Jan 11 '10 at 16:25
  • Then use something unique like the user's ID in the database... Problem solved, user can change his/her name. – Boldewyn Jan 11 '10 at 16:36
  • 2
    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 Jan 11 '10 at 16:38
  • 1
    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 Jan 11 '10 at 16:57
1

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/

Community
  • 1
  • 1
Jacco
  • 23,534
  • 17
  • 88
  • 105
  • I didn't downvote, but IMHO it's missing the point. The question is about double-hashing a password. – Boldewyn Jan 11 '10 at 16:41