MySQL Encryption - where to store the key

I'm going to be encrypting some fields in my database using AES_ENCRYPT() and AES_DECRYPT(), and connecting to my webpage using SSL.

The point of the exercise is that my application will be hosting some very sensitive user information which nobody else - and that should include me or anyone else who somehow gains administrative access to the server - can read it.

I understand the basic concepts of public shared key encryption - but something I don't get is where are you supposed to store the "key" string that AES_ENCRYPT/DECRYPT needs? That seems like te weakest link in the chain, and no matter how strong the encryption is, if the key is easily retrievable it all pretty much counts for nothing.

So how and where am I supposed to store the key for doing the encryption/decryption?
LVL 31
Frosty555Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
stephen_c01Connect With a Mentor Commented:
Ok, so I am partial right, you should use their password as the encryption key. But now, how do you handle multiple access.

Something along the lines of.

You generate a random key say a md5 hash, that will actually be the encryption key for the users data. Now you encrypt the md5 hash with their password. Now, when they change their password you just decrypt and re-encrypt the md5 hash with the new password you and don't have to re-encrypt all of their data. In this method to get multiple users access to the same data you just decrypt the md5 hash; copy it and encrypt it with the other users password so they now have access to the md5 hash, which is the true key to the data.

IMO, you would want to layer this. you might want to use a unique md5 hash for each password in the password vault. So you can share some of the account and not all of the accounts.
0
 
stephen_c01Commented:
You are correct, storing the key will always be the weakest link. Thats why many people use hash's for passwords so there is no way to get them back.

Without knowing your setup, the user or client password can be the encryption key. So when they logon you know have the key to decrypt and only the users knows. Its hard to give other idea's without more information of the who and the what.
0
 
Frosty555Author Commented:
Hi Stephen,

The easiest analogy to give to the system I'm developing is imagine a password vault system - each user registers for an account and then inputs their passwords / sensitive data into the system for safe keeping.  It's important that the security of the website permits only them to see the info, but equally as important for their own peace of mind that me or anyone in my company can't just go in the back-end and look at it either.

The other question is if you have several users who need access to the same piece of data, can you have multiple "decrypting" keys that work?
0
 
Frosty555Author Commented:
I'm still sort of wrapping my head around what you've just said, but I think it makes sense. It also conveniently solves the problem of "isn't it a lot of overhead to reencrypt half the database whenever the user wants to change their password"

Cool, thank you for your help

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.