When hashing passwords, is it ok to use the hashed password as the salt?

Question

I don't like this idea. But I can not come up with a technical argument against it. Can somebody explain it to me? The basic idea is:

$passwd = 'foo';
$salt = hash($passwd);
$finalHash = hash($passwd . $salt);

The $finalHash is what would be stored in the database. I do understand that two users with the same password "foo" would have identical hashes. But that is only one weakness of this plan. And such collisions, while dangerous, are not the primary reason we use salts with hashes. But so far this the only technical objection I have come up with to argue against this.

My understanding is that salts should be random and should be unique for each use of the hash. And this scheme appears to violate both requirements. But I can't figure out how an attacker could benefit from this seemingly flawed use of salted hashing.

Answer 1

If two users have the same password, then the salt will be the same, resulting in the same hash for both. This is undesirable, because it leaks information about passwords. If Alice breaks into your database and sees that Bob has the same hash as her, she can use that information. Pick something that is guaranteed to be unique.

Your biggest problem here, though, is that you're using hash without any information about what that hash is. Depending on the system, it might even be the old crappy 3DES implementation that strips everything after the 8th character. You should be using a proper KDF such as bcrypt or PBKDF2.

Answer 2

To answer this, one has to understand why salts are needed in the first place. This is explained pretty well in How to securely hash passwords?; here's an excerpt from the accepted answer:

---

Salts: among the advantages of the attacker over the defender, is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation is precomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.

The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash function. Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).

---

So the problem of your salt is that it doesn't interfere with parallelizing breaking the hashes, which is the very purpose of salting. I strongly recommend you to read the original answer, it has further advice on salting.

Answer 3

If you use the password as "salt" then you are not using any salt at all; you are just hashing the password.

If two users choose the same password, they end up with the same hashed password. That's what is often told as if it explained the problem, but it seems that most people get it wrong. They imagine that this means "collision", which, for some reason, is considered by many to be a bad word when talking about password hashing. But that's wrong, and not the point.

The point is determinism. Suppose that I, wantonly, grab a copy of the hashed passwords for 1000 users (e.g. I retrieved an old backup tape from your garbage bin). Then I can "try" potential passwords: I hash a potential password (using the password itself as "salt") and then I look up the value among the 1000 hashed values. This means that by paying the computational price of one hashing, I actually try one thousand user+password pairs. I am attacking one thousand of hashed passwords in parallel, for the same cost as attacking a single one. This kind of parallelism can express itself under several guises, including rainbow tables.

We really prefer it when attacking 1000 hashed passwords costs 1000 times the cost of attacking 1 hashed password. To do that, you need real salts, i.e. salts which are distinct for distinct users, even when they happen to use the same password -- and, actually, when they potentially use the same password. When there is no real salt, the parallel attack works not because some users do choose the same password, but because if they had chosen the same password then they would have obtained the same hashed value. They don't actually need to choose the same password to trigger the weakness.

Using the user name as salt is much better. It is not good, mind you; but still better. What is even better, to the point of being actually decently secure, is to use random salts.

Answer 4

Using a username or password as a salt doesn't sound like a good idea to me.

An attacker might reasonably guess that you're using the username or password as the salt. Depending on your setup it might be very reasonable to assume an attacker could gain access to usernames.

Also depending on how strict your system is at enforcing passwords the attacker could take advantage of passwords that appear in a dictionary of known/common passwords, and as these are used as the salt your system would be vulnerable to this kind of attack.

Using a salt that doesn't rely on user input is a much better idea.

Answer 5

There have been cases recently where more than 100,000,000 hashes have been leaked. Hopefully they were salted. I think a big number like this makes the effect of salting much more obvious.

Let's say there are passwords that are not really unsafe, but not quite secure enough, because the chance that a random user uses one of these passwords is one in 10 billion. If I try just 100 such passwords, then I can expect to guess the password of one of these 100 million people. Since the password was hashed, then salted with the hash and hashed again, I can easily figure out what is stored in the database for each of these passwords, so after 100 hashes I found a password.

If the passwords were properly salted, each with a different salt, even if each salt is known, I have to calculate 10 billion hashes to get the same result.