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

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.