Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

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.

share|improve this answer
    
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 '12 at 6:10
3  
MD5 with salt won't protect enough. Slow hash should be used instead of MD5. –  Andrey Botalov Jun 26 '12 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 '12 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 '12 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. –  Andrey Botalov Jun 26 '12 at 17:40
add comment

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.

share|improve this answer
10  
+1 for "don't encrypt passwords". Passwords should be salted and hashed, not encrypted. –  Iszi Jun 25 '12 at 18:26
    
The simplest method is not always the best. It appears that aes_encrypt() uses ECB mode. –  mikeazo Jun 25 '12 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 '12 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 '12 at 19:04
3  
-1. OP asks about encrypting files too. ECB (and thus MySQL's aes_encrypt()) isn't suitable –  Andrey Botalov Jun 26 '12 at 17:46
show 6 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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