I'm curious about the security implications of reusing characters from the plaintext as salt.e.g.
$salted_plaintext = $plaintext[1] . $plaintext[7] . $plaintext;
My gut feeling is that it increases security through obscurity, though not as much as a proper salt, as existing rainbow tables wouldn't be applicable and would have to be re-made with this "salt" in place.
Since I'm sure someone will ask: the hash is for comparison of some sensitive data against a list of stored hashes.
My gut feeling is that it increases security through obscurity [...]
Security through obscurity is the name of an antipattern, for good reason. Generally, the way we analyze security measures is by trying to give the attacker as much power as we can get away with.
So we just assume that the attacker knows your construction:
$salted_plaintext = $plaintext[1] . $plaintext[7] . $plaintext;
...and then we can observe that since the salt is a function of the password, two users who use the same password will get the same salt and thus the same hashed password, meaning that for each password guess the attacker is able to test every user's password entry. Same as with unsalted password hashes.
[...] existing rainbow tables wouldn't be applicable and would have to be re-made with this "salt" in place.
The proper answer to that is "meh." GPU password cracking is so fast these days that an attacker might not even consider rainbow tables. See Troy Hunt's article on GPU password cracking, where he demonstrates how he cracked 24,710 out of 40,000 salted SHA-1 hashed passwords in 45 minutes with a $500 GPU and a cracking dictionary he downloaded.
You really ought to read the Information Security Stack Exchange's site popular entry on how to securely hash passwords, particularly the top answer.
