Take the 2-minute tour ×

I've a website that users submit their personal data, and I'm thinking of encrypting these data using aes-256 and their password is used as a key for that encryption and then I store the encrypted data in a mysql database...

Now if the user changes his password how would I change the key of the encrypted data

Should I gather all the data from the database then Decrypt their data with the old key then encrypting it again with a new key?

share|improve this question

4 Answers 4

up vote 8 down vote accepted

You don't need to re-encrypt all of the user's data when they change their password.

Generate a secret key to encrypt a user's data; call this the "content encryption key." Derive a key from the user's password; call this the "key encryption key." Encrypt the "content encryption key" using the "key encryption key." Store the encrypted key along with the salt and the number of iterations used for key derivation.

If they change their password, decrypt the content encryption key with the old password, and re-encrypt it with a key derived from the new password. You should choose a new salt for the new password, and make sure you store it along with the new encrypted key.

Because the content encryption key is randomly chosen from a huge space, you can safely use ECB as the cipher mode when encrypting it.

Don't simply hash the password, even if you use salt, even if you use an as-yet-unbroken algorithm. You need to repeat the hashing operation thousands of times. There are libraries for doing this (correctly) on most platforms. Use a key derivation algorithm (PBKDF2, from PKCS #5) to create a secret key from a password.

This concept follows the draft for password-based S/MIME encryption.

share|improve this answer

First, you generally shouldn't use the password as an AES key. Maybe something like a cryptographic hash (not MD5) of the password + a salt (you would store the salt but not the hash in this case).

One thing you could do is encrypt each user's files with a random key, then encrypt that key with the hashed+salted password. If the user changes passwords, you only have to re-encrypt the key.

share|improve this answer

One possibility to consider decouples the key used to encrypt the data from the key used to gain access to the data. Done carefully, this allows the user to change their password as often as they desire, while you only change one record in the database. Separately, you can schedule changes to the key(s) encrypting their data when it is convenient for you.

How does it work?

  • You encrypt the data D for user U with a randomly generated key, KU,D.
  • You encrypt the key KU,D with a separate key K1U,K generated from a random salt, S1U (which you keep a record of) and the user's password P1U (which you may or may not keep track of). The encrypted key is E1U.
  • You store S1U and K1U,K ready for when the user wants to access their data.
  • When user U wants to access their data, they provide you with their password, P1U, and you look up S1U and regenerate K1U,K from that data, and use that to decrypt E1U, giving you KU,D once more, with which you decrypt their actual data.
  • You ensure you can detect when the password given is correct so you don't spew forth binary gibberish if the users types the wrong password.

The advantage of this level of indirection comes when the user wants to change their password. If you don't use some technique analogous to this, you will have to get and validate the old password and the new password, decrypt all the data with the old password, and re-encrypt it all with the new password.

With the level of indirection, you still prompt the user for their old password (P1U) and their new password (P2U) and validate them, but you only have to decrypt E1U and then re-encrypt it with a new key K2U,K generated from a new salt S2U and the new password P2U. You do not have to touch the encrypted data at all.

With the level of indirection, the system S can also keep a second encrypted copy of the data key KU,D, encrypted with the system's password. If it becomes necessary or desirable to change the key used for encrypting the data, the system can use its encrypted copy of the key to do so. It can keep a record of which key was last recorded by the user in their key, so when the user returns to look at the data, it can arrange to to change the stored key K2U,D because at that time, it has their password (the rest of the time, it does not).

This is a mild variation on some of the ideas in "Cryptography in the Database: The Last Line of Defense" by Kevin Kenan. The KnU,K keys are examples of a KEK, a Key-Encrypting Key. You could also read about key families in the book, which would help with the management of encrypted data.

share|improve this answer

Thats silly.

AES uses a 256 bit key so when you say that you will be using their password for the key, it wont be nearly as long as the key size requirment.

share|improve this answer
I will hash their password to give me the 256 byte then use it in the encryption –  Michael harris Jan 24 '12 at 3:33
Ok, so what is your format for building the key? –  Dan Kanze Jan 24 '12 at 3:34

Your Answer


