Encryption for data you have to decrypt: use variables to set the key.
- Don't log the queries containing user input, they will contain the data you are encrypting. If you have to log it, don't give the database user read privileges to the log
- Don't run your database as a privileged user (e.g. local system/root)
- Store the key seperately from the PHP application and instantiate the variable when the database starts
- Encrypt the key with another key that only root can access, openssl in bash is candidate to do this. The database user shouldn't have direct access to both the key and the key encryption key.
Salted Hashes for data you only need to verify (Passwords).
Salting is incredibly important. I cannot underscore this enough. Using a relatively inexpensive device (roughly 2k) I can run 100m hashes a second in most algos, a higher end device (~6k - mainly used for industrial purposes) I'm able to achieve upwards of 1.2 billion hashes per second (sha, md5, md4 etc.) If your attacker has an FPGA farm trillions of guesses per second are not far fetched. You can view statistics here
Using John and non-optimized code, the Linkedin list (hashes without salt) was guessed @ ~70% using default mangling rules in less than 24 hours... Salt your Hashes. When your database is exposed, this will give you the time to inform your users to change their passwords without (necessarily) immediately compromising their access.
Don't store it if you don't need it.
I know this isn't directly the question, but seriously, it is just as important. Assuming your database is compromised at some point, if it doesn't have data it can't be exposed.
Last: Use best practice security for databases: validate your data, use stored procedures to proces input, and monitor+audit your database access logs.
