Salting a secret with itself before storing in a DB, what are the weaknesses?

Question

I've heard of people using this approach and would like to know what the implications are. I just know it's a bad idea!

From what I understand, salting a password before storing the hash in a DB has the primary purpose of making every hashing algorithm unique, and thus requiring a new rainbow table for every user when trying to crack it.

How is a hash weakened in this context if the plain text was just salted with itself?

An example:

plainText = input();
saltedText = plainText + plainText;
hashedText = hash(saltedText);
db.store(hashedText);

And would the following approach have the same weaknesses or any other weaknesses?

plainText = input();
saltedText = hash(plainText) + plainText;
hashedText = hash(saltedText);
db.store(hashedText);

score 2 · Accepted Answer · answered Oct 27 '10 at 11:54

2

I think you have misunderstood the purpose of the salt. The salt means that the same data, hashed twice would (usually) give two different results. This prevents attacks where knowing what values can create a given hash gives you the login to everyone who uses the same password.

As such duplicating the test to be hashed will not give you any benefits other than the perf hit of hashing more data.

answered Oct 27 '10 at 11:54

Spence

28,526
15
68
103

If I understand correctly you've addressed the second approach (where hashing happens twice). And in the first approach it means that if 2 passwords are the same, the cracker only needs to crack the one to access the other. This is a weakness, I agree, and it's pretty obvious. Is it the only weakness? – Oct 27 '10 at 12:00
Aha nevermind, I understand what you mean now. There really is no point in adding a salt in this approach then, is there? The same plain text values will always produce the same hash, which eliminates any benefit of salting in the first place. – Oct 27 '10 at 12:10
1

Exactly. It's great that you're asking the question though, most people don't bother to look and end up using something easy and/or reversible for their passwords and session keys, massive security holes. – Spence Oct 27 '10 at 13:36
To be honest, I used to just use a constant in my code. I've learnt to use random salts since then, but I still see people (some of them with way more experience than myself) using funny things as salts for no reason. A lot of people are under the impression that the salt must also be kept a secret. – Oct 29 '10 at 06:40

score 1 · Answer 2 · answered Oct 27 '10 at 12:16

In both your methods the salt is predictable, so only one rainbow table is needed.

You should use a different salt every time you hash a string:

plainText = input();
salt = getRandomSalt();
hashedText = hash(salt + plainText);
db.store(salt, hashedText);

Gerald Davis · Answer 3 · 2010-11-15T15:00:15.767

Others have explained the issues with your implementation.

If you want to derive a salt (to avoid needing to store one) you need another user unique source for the salt.

For example AccountID, username, or email address could be used as a salt source. Obviously you shouldn't use the source straight as the salt instead use a key derivation function like PBKDF2.

Remember if the underlying salt source changes the password will need to be rehashed. This can be implemented by asking the user for the password before changing key information (validate user and then use provided password to rehash w/ salt source).

Salting a secret with itself before storing in a DB, what are the weaknesses?

3 Answers3