Possible Duplicate:
Best way to prevent SQL Injection in PHP
The necessity of hiding the salt for a hash
I'm very new to MySQL and PHP, and have started self-learning it over the past couple of days and today I was looking at encryption for passwords etc. I've been looking through many webpages with information on the topic and most of them are saying to generate a random salt for every entry in the table (which I understand, you don't want the same salt for every entry) and this salt should then be stored in the table alongside the entry.
From what I've understood (correct me if I'm wrong), the encryption of the password doesn't prevent hackers from accessing it, rather just masks the true value if they do get access to the database. Surely if this is the case, you wouldn't want to store the salt in the table too - if the hacker has accessed the database and can see the encrypted data, showing him the salt just makes his job of decrypting infinitely easier?
The salt isn't used to encrypt. Instead, it goes (together with the password) into a hash function. That way, nobody (not even your application) can determine the password, but you can verify a password.
The salt is then used to require the attacker to attack each password hash individually (if the attacker wants just one password, the salt doesn't help in any way). Thanks to rainbow tables, it is fairly easy to compute the outputs of the hash function for common passwords.
The salt value is not secret, and can be safely stored in a MySQL database (or even published).
The purpose of the salt is to prevent the use of Rainbow tables.These would allow a hacker to have generated a large number of pre generated hashes for certain passwords. By appending the salt to the password before it is hashed the hash is completely different than the original password.
password => 5f4dcc3b5aa765d61d8327deb882cf99
password+saltvalue => 1d7dc54c316b11f3a38cc24fa68e2b6a
thus they would need to recreate the hash for each salt value which is unpractical.
It is perfectly fine to store the salt in the way that you are planning to. In fact it is fine to allow the attacker to see the salts. The purpose of the salt is to prevent people from being able to use prebuilt look up tables called rainbow tables by extending the size of the message space. All the salt does is make them throw out any precomputation and solve the whole problem which is time consuming but certainly possible (especially for hashes like md5 -- you should move to sha256)
You want to use different salts for each user so that an attacker would have to do the full amount of work for each password they recover rather than just generate a new table based on a single salt.
You can consider salt as something 'semi unique', it really does not have to be additional column called salt. Username, user email is also a kind of salt. So they are actually stored in db, next to hashed password. One problem with this approach occur when user decide to change a username or email.