[tptacek]

The purpose of a salt is to randomize the password hashes so you can't easily precompute them. A "salt" derived from the password itself isn't random; it's deterministic. Salts don't add much security, but they do defeat precomputation. The scheme your coworker proposed doesn't do that.

[encoderer]

I'm not going to lie and say I was already thinking that, but I did have a notion that, in such a scheme, if somebodies passowrd was "1111111" then your salt + password would be the unimpressive 1111111111111.

But if you don't mind a follow-up, wouldn't it still defeat rainbow tables? Why not?

[tptacek]

In your scheme, if your password is "apple scrapple", the hash value is always going to be (say) "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15". An attacker can precompute that and just use text search to find everyone with the password "apple scrapple".

[keeperofdakeys]

They would still need a rainbow suited to the algorithm that is used to create the salt, or to have it large enough to contain the password+salt value within it. Still means that the entire database can be used with the same rainbow table, however.