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

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 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

(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 4

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

Answer 5

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 6

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.