Reputation: 545
Let's begin with two assumptions:
SECRET_KEY
as encryption key.SECRET_KEY
needs to be changed, because of security problem.What would be the best thing to do in such situation? I assume that I should change the SECRET_KEY
immediately after I've fixed the security hole, however if I do that I'll essentially lose access to all of the encrypted data.
What I have came up with is to first do a migration, which would temporarily replace encrypted fields with simple charfields/textfields + data migration to unencrypt stored values. Then change the SECRET_KEY
. Finally bring the encrypted fields back, again with a data migration to encrypt stored values.
It seems like a great hassle though, is there a better/simpler/faster way to handle such situation?
Upvotes: 0
Views: 1067
Reputation: 174632
Since you only have one secret key, your only resort is to re-encrypt the entire database.
The proper way is to first not use django's SECRET_KEY
for database tasks (even django doesn't use it for things like user passwords) and implement a key-rotation algorithm for your sensitive data.
django-fernet-fields
provides this function out of the box; however it assumes you are rotating keys as best practice and not as consequence of a compromise.
Best-practice key rotation relies on "encryption at use" where a secret is unencrypted with the old key and re-encrypted with the new key upon use. Eventually your most used secrets are re-encrypted and you can do an audit to invalidate or force the re-encryption of the remaining entries.
Upvotes: 1