Password hash and salting - is this a good method?

Question

I was doing a little research or googling for different methods of handling password hashing and salting and came across this interesting link:

http://phix.me/salt/

Now, essentially what this proposes is the creation of two user functions, one for hashing and one for checking the hash.

The salt is pseudo random but is in actual fact based upon the password (strikes me as bad?).

The hashing function also pseudo randomly "sprinkles" the salt amongst the hash string.

The hash checking function reverses the salt sprinkling and then the actual hash check takes place.

Now, I'm aware that unique salts for each password hash = good, but also that having the logic to hash the passwords and create the salt stored in a db function might = bad.

I like the idea that the salt isn't obvious and that it also needn't be based on some hopefully consistent value such as username, userid, date of birth etc, but as I said I do have my doubts as to the implementation.

So, what are people's opinions and ideas of "best approach solutions"?

Answer 1

The purpose of a salt is to make the use of a rainbow table prohibitively expensive, so Attempt 1 pretty much solves the problem correctly. Basing the salt on the password eliminates the variability that defeats rainbow tables, and trying to hide it in the hashed password field is just pointless.

Answer 2

The salt doesn't need to be secret. It does need to be unpredictable for a given password.

Deriving the salt from the password completely misses the point.

Answer 3

I asked a similar question earlier. The consensus was this:

It doesn't matter how you salt, so long as you:

1. Salt before you hash
2. Use a random salt unique per password
3. Use a large enough salt to make rainbow tables prohibitive.

You can even store your salt right next to your hashed passwords and feel pretty darn confident.

Personally, I find GUIDs (in string format) work great for Salts. They take a line of code to generate and in string format are more than large enough to make rainbow tables take millennia to compute.

Answer 4

There have been many similar questions asked before:

• Secure hash and salt for PHP passwords
• Is “double hashing” a password less secure than just hashing it once?
• What algorithm should I use to hash passwords into my database?

That should get you an idea of how to hash passwords.

Answer 5

(Edited answer because I misread the article initially and thought he was just mixing the salt together with an unsalted hash)

His techniques do seem fine, they'll work, but they're not really any "better" than normal salting methods. It's just an attempt to do security by obscurity, it's no better than making up your own random "hash scrambling" method and hoping that the attacker doesn't figure it out.

In fact, it could actually be quite easy for the attacker to figure these functions out, in many cases. If the site is one with public registration, the attacker could repeatedly register accounts with known passwords, then use the known md5 hashes for those passwords to reverse-engineer the password scrambling algorithm. I'd be able to do this very easily, even looking at the result of his "Attempt 4".

If you want to store your passwords really securely, get away from MD5 and even SHA1, and move towards a salted, slower hash function. This is a great article about the topic: Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes

Answer 6

This seems for me to just add obfuscation, not any more security, to the (as Chad Birch pointed out misunderstood) salted hash method.

Answer 7

Interestingly, this is not just obfuscation, not any more security but actually obfuscation, less security because "Attempt 4" is only as good as the CRC32 function it uses (CRC32 is passed ONLY the password, not password+salt) - this is the downfall.

As per Chad's post, to crack "Attempt 4", all one has to do is CRC32 loads of passwords and then reverse the function he's coded up, leaving you with a salted md5 hash and the salt (which you would then test for validity). Simply test this pair by calculating md5(password+salt) (where password is the password you are trying) and salt is the salt you have calculated by reversing the algorithm. If the md5 equals the first 32 characters of the hash, you've cracked the password.

"Attempt 4" is worse than "Attempt 1", in some respects, as it as only as good as the worst function called in the entire routine, in this case, CRC32(password).

Answer 8

I can't view the link in the original question (the website just returns a 404 not found error), but the method described in the question is not really using a salted hash.

In essence, this method is just using a non-standard hash: given a specific password, there is one unique value that will be stored in the database. This is all that is needed to make a rainbow tables attack work: I can precompute the hash value for a dictionary of likely passwords and look for any matches. Now, I will have to precompute rainbow tables specifically for this non-standard hash function.

In a proper implementation of salted hashes, when the passord is created, a random salt is combined with the password and hashed. Then random salt used and the hash are stored. Even if I know the password, I cannot predict what the hash will be since there will be a different hash for each of the many possible salt values. Now an attacker needs to precompute a rainbow table for each possible salt value: this takes a much larger effort.