How can I improve the application administrator's encryption keys security inside database

Question

I am interested in the issue of establishing the security of data of users of a web application in the event of a database leak.

It was decided to use the following encryption chain:

1. User data is encrypted with a user symmetric key (AES)
2. The user symmetric key is encrypted with the user's RSA public key
3. The user's private RSA key is encrypted with a key derived from the user's password (PBKDF2)

This approach is described in https://stackoverflow.com/questions/7529582/how-to-store-private-encrypted-user-data-in-the-database-but-make-them-availabl

Our system provides a superuser who can view the data of all users, as well as help them recover access to the account in case of a password loss. For this, the user's RSA private keys must also be encrypted using some additional key that is available to this superuser. The protection of a cryptographic system is determined by the security of its weakest link, and therefore the security of this entire encryption system is reduced to the cryptographic strength of the superuser's password (and from what I've read, one PBKDF2 key can be brute-forced relatively easily, https://stackoverflow.com/a/16279280/7646189)

The question is how, without removing the concept of superuser, to strengthen the security of the superuser's encryption keys in the database.

The first thing that comes to my mind is for the administrator to use yet another encryption key INSTEAD of a password. But I don't understand how it can be used in this scheme, and how the superuser should store this key then and present it to the database for deciphering.

Answer 1

Compile the encryption key from data outside of the database

Database hacks are more common than application hacks, and application hacks are more common than full system hacks. It is pretty common for your database to be stolen without your whole system being compromised. In most cases, you can simply put a key into a separate config file kind of like WordPress does so that in case of a database dump, the key is outside of the scope of what is stolen.

If you want to take it a step further you can compile your key from system information. So, let's say someone steals your whole application and database and puts it on their computer to reverse engineer, your PHP/ASP.NET whatever may in it's encryption method create your key each time it needs it by hashing some combination of system checks. So maybe it is taking things like your MAC address, Computer name, IP, etc, concatenating them together, and then hashing them to create a key.

Since these system specs are static and unique (in theory), it means that your system will generate the same key every time on your system, but the moment you go to put the data on another system, it will generate a different key because your system specs have changed. Thus nullifying the hacker's ability to read your data.

That said, you should be very cautious about when and where you implement this because it means that your data will forever be tied to the system it is on; so, if your server dies (or your cloud hosting provider changes something on you), then you risk being locked out of your own system. So when you do this, you should write yourself a script for saving your compiled key, put in on a thumb drive or something like that, and then remove the script from your application. This way you can manually unlock your system in the future if you need to.

On many systems, the potential for downtime or total data loose this could create is considered an unacceptable risk compared to the security advantages it provides; so, make sure with your project coordinator that the risk/reward here is worth it to them and/or your client for the project you are working on.