How to change aes-256 key after encryption?

I have a website where users submit their personal data, and I think about encrypting this data with aes-256, and their password is used as the key for this encryption, and then I store the encrypted data in the mysql database. ..

Now, if the user changes his password, how can I change the encrypted data key

Should I collect all the data from the database, and then decrypt their data using the old key, and then encrypt it again with the new key?

+7
source share
4 answers

You do not need to re-encrypt all user data when they change their password.

Generate a secret key to encrypt user data; call it "content encryption key." Derive the key from the user password; call it "key encryption key." Encrypt the โ€œcontent encryption keyโ€ with the โ€œkey encryption keyโ€. Store the encrypted key along with the salt and the number of iterations used to derive the keys.

If they change their password, decrypt the content encryption key with the old password and re-encrypt it using the key obtained from the new password. You must select a new salt for the new password and make sure that you save it along with the new encrypted key.

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

Not just a hash password, even if you use salt, even if you use an inextricable algorithm. You need to repeat the hash operation thousands of times. There are libraries for this (right) on most platforms. Use the key derivation algorithm (PBKDF2, from PKCS # 5) to create a secret key from a password.

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

+13
source

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

One thing you can do is to encrypt each user file with a random key, and then encrypt that key with a hashed + salted password. If the user changes passwords, you need to re-encrypt the key.

+3
source

You might consider decoupling the key used to encrypt data from the key used to gain access to the data. Very carefully, this allows the user to change their password as often as they want, while you only change one entry in the database. Separately, you can plan changes to the key (s) by encrypting your data at your convenience.

How it works?

  • You are encrypting D data for user U with a randomly generated key, K U, D.
  • You encrypt the key K U, D with a separate key K1 U, K generated from a random salt, S1 U (which you save the record) and the password of the user P1 U (which you can or cannot track). The encrypted key is E1 U.
  • You save S1 U and K1 U, K ready when the user wants to access their data.
  • When user U wants to access his data, they give you their password, P1 U , and you look at S1 U and restore K1 U, K , and use this to decrypt E1 U , giving you K U, D again, with which You will decrypt your actual data.
  • You guarantee that you can determine when the correct password is entered so that you do not spew binary gibberish if the user enters the wrong password.

The advantage of this level of indirection occurs when the user wants to change his password. If you are not using any technique similar to this, you will have to obtain and verify the old password and the new password, decrypt all data with the old password and re-encrypt it all with the new password.

With the level of indirection, you still ask the user for your old password (P1 U ) and new password (P2 U ) and verify them, but you only need to decrypt E1 U and then re-encrypt it with the new key K2 U, K generated from the new salt S2 U , and the new password P2 U. You donโ€™t have to touch encrypted data at all.

With a level of indirection, system S can also store a second encrypted copy of the data key K U, D , encrypted with a system password. If it becomes necessary or desirable to change the key used to encrypt data, the system can use its encrypted copy of the key for this. He can keep a record of which key was last recorded by the user in their key, so when the user returns to viewing the data, he can organize a change to the saved key K2 U, D , because at this time he has his own password (for the rest time is not so).

This is a small variation on some ideas in Database Cryptography: The Last Line of Defense by Kevin Kenan. Kn U, K keys are examples of KEK encryption key keys. You can also read about key families in the book to help manage encrypted data.

+2
source

This is silly.

AES uses a 256-bit key, so when you say that you will use your password for the key, it will not be nearly as long as the key size requirement.

0
source

All Articles