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.
Jonathan leffler
source share