Salt is good; but if the salt becomes unsalty, with what will you make it salty again?
Salting your hashes is a good thing. It adds another level of protection to your hash, and prevents the effectiveness of rainbow tables should your hash get out. It’s been standard practice to use a salt when storing passwords and similar information for almost 30 years now. Using a weak salt can significantly reduce the protection it will give you. Also, use of a salt should just be an additional level of protection to your hashes – not your only protection. However, the use of a salt doesn’t suddenly mean that sharing your hashes with the world is a good thing.
It’s a well known, well documented, and well abused fact that SQL injection attacks can take place in the WHERE clause of a SQL statement. The commonly applied practice among professionals is to run user input through mysql(i)_real_escape_string(). However, this only protects against user variables within quoted values, and does not protect against SQL injection attacks elsewhere in the query.
One place that is commonly vulnerable is in the ORDER BY clause. Many developers either do not understand that mysql(i)_real_escape_string does not protect them from these types of attacks, or do not think that meaningful SQL injection can be done at this point in the query on a single statement engine like MySQL. As a result, this vulnerability can be found and exploited in many applications and websites, both commercial and open source, personal and corporate. Read more…