I want to encrypt the username, email, and password fields in the database AND encrypt user files at rest. How can I do this? I am aware of software such as Gazzang and since there is not cost published I can only figure that it will cost thousands of dollars each year.

Is there any alternative solution that I can build myself OR use a software that runs on the server that can encrypt the fields and the user files?

Not sure if it makes a difference but I am using PHP/MYSQL and I have cloud servers.

2 Answers 2


The simplest method of encryption on a mysql server is aes_encrypt() using a randomly generated passphrase.

You should not encrypt user passwords, passwords must always be hashed. Passwords should be stored using bcrypt or sha256.

  • 12
    +1 for "don't encrypt passwords". Passwords should be salted and hashed, not encrypted.
    – Iszi
    Jun 25, 2012 at 18:26
  • The simplest method is not always the best. It appears that aes_encrypt() uses ECB mode.
    – mikeazo
    Jun 25, 2012 at 18:41
  • @mikeazo yeah, and usernames and email addresses are unique and will usually fit in a single AES-128 block. Can you think of a reason why an IV is really necessary for this type of data?
    – Mikey
    Jun 25, 2012 at 18:56
  • @user5621, a lot of my email addresses will not fit in a single 128 bit block (16 characters). That said, let's assume that all email addresses and usernames are no bigger than 16 characters. Are there any glaring issues? No. Still, I'd rather be safe than sorry.
    – mikeazo
    Jun 25, 2012 at 19:04
  • 4
    -1. OP asks about encrypting files too. ECB (and thus MySQL's aes_encrypt()) isn't suitable Jun 26, 2012 at 17:46

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.

  • Excuse me, what is the benefit of using stored procedures instead of application-level algos to process input? It makes deploys more problematic.
    – Renra
    Jun 26, 2012 at 6:10
  • 3
    MD5 with salt won't protect enough. Slow hash should be used instead of MD5. Jun 26, 2012 at 8:41
  • 1
    @Renra once your application is subverted, it makes it more difficult for an attacker to do things like read a table, when they don't have permit on select. Setting exec only on stored procedures means you can be more granular with your permissions.
    – Ori
    Jun 26, 2012 at 17:16
  • 1
    @AndreyBotalov I tend to agree, bcrypt is a better solution for this, but is not available in the standard mysql encryption functions it would have to be implemented in the application layer.
    – Ori
    Jun 26, 2012 at 17:20
  • 1
    It's easy to use library that has slow hash implemented. The fact that it's not implemented in MySQL, isn't excuse. You can just send slow hash's output to DBMS and store it there. Jun 26, 2012 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.