I have a system that stores sensitive user data in a sql database. There are super users who have the password required to decrypt the data, so when they need to see the information the system prompts then, decrypts and shows the data. Now there is a new requirement: normal users should be able to see part of the data, while super users remain able to see everything.

The information about who can see what is already available to the system and it is not a problem for the system to know the master password.

I don't know how to do this in a secure manner. One solution is to put the master password in memory, however if an attack gains temporary access to the memory of the application it can access the entire unencrypted database. Another solution I thought was that the system makes a request to another device (such as the company's CEO) and gets the master password there, this way it doesn't stay in memory for long.

Can anyone suggest me anything or point me in the right direction?

Thanks.

CodePudding user response：

This is an interesting situation that may not have a perfect solution, but I would be happy to share my views on it.

Let's start with the basics. If the system knows the master key, it has to be stored somewhere accessible to the server. We have (as you correctly realized) two choices: on the server, or off of the server. Here, I would argue that storing it off the server would only bring more attack vectors because there are more communications involved. Suppose the master key was stored on the CEO's iPhone. What if the iPhone is compromised by a virus (Pegasus), or stolen, or taken by the FBI? It's best not to involve unnecessary parties here.

Storing the master key somewhere on the server is your best and most secure bet. So now comes the question of how to keep that master key secure. Let's say you're storing user passwords on a server. Don't put the master key there, because if the server is compromised, the master key would likely be as well. Instead, set up a dedicated server with the master key and use HTTPS requests between the main web server and the dedicated server to communicate. This way, the dedicated server can be locked down with only port 443 open, and open to fewer attacks than the webserver which could have a lot more programs running (and thus more attacks possible).

Here's the flow I would envision:

• A superuser wants to read everyone's message
• He authenticates with the webserver
• The web server recognizes him as a superuser
• The web server sends an HTTPS request to the dedicated server with some messages
• The dedicated server reads the master key into memory, decrypts the message, sends it back to the webserver, and erases the master key from memory
• The web server receives the decrypted data and returns it to the superuser

In this case, as long as you can secure the dedicated server, your master key would be safe. I'd recommend keeping the dedicated server on the same private network as the webserver and not making it accessible from the Internet.

There may be a better solution, but since no one has posted anything yet, I might as well lend my thoughts.