5

I'm looking to create a system where a lot of the data is encrypted within the database. The encryption method will be a currently accepted strong algorithm.

To access this data, a user would need to log in and then the data will need to be decrypted with some key. There will be many users who should all have access to the same data.

I don't want to store this 'master' key in the source code (PHP), on disk, or anywhere else in plain text.

So, I thought I could encrypt the 'master' decryption key with each users' own password and store it alongside their user record. Upon login, they get the decrypted master key, which is then available in memory for them to decrypt the application data.

My initial concern is that if there is a data breach of source code and data, then an attacker would see that the same key was encrypted many times (once for each user). Could this then reduce the security of the 'master' key? Either by patterns in the encrypted data or by testing that a decryption attempt on one record matches that of another?

Or, am I simply barking up the wrong tree and there is a better method already out there?

4

You are describing a few different problems.

Storage of credentials and other secrets

I don't want to store this 'master' key in the source code (PHP), on disk, or anywhere else in plain text.

You are correct that hardcoding secrets is a bad idea, you may want to try using something like hashicorpo-vault (This particular article may be related to your workflow as well) or a Key management service like Amazon KMS.

Multi-user Encrypted Access

There are a few different strategies to this type of setup. You can encrypt the data with a shared key and then encrypt that key for each user using the user's public key. You would then need to update the per file key and re-encrypt with each user's public key again if there was any change in the access group's membership.

Deriving a key based on the password can be complicated because you need to ensure you properly update all of the keys and redo all the encryption if the user's password changes.

You may want to look at MIT's Mylar project, as it tries to accomplish something similar to the storage and access model you described.

Breach scenario

My initial concern is that if there is a data breach of source code and data, then an attacker would see that the same key was encrypted many times (once for each user). Could this then reduce the security of the 'master' key?

If you are ever decrypting server side and the attacker has access they can grab the decrypted copy of the data.

If you are creating user's private keys using the password as the seed then you have some risks especially if the passwords can be identified by stealing them or reversing the hashes.

More Generally

Could this then reduce the security of the 'master' key? Either by patterns in the encrypted data or by testing that a decryption attempt on one record matches that of another?

I believe you are asking if encrypting the same value with multiple different per-user keys would make it easier to get back to the original plaintext value (?).

If you happen to know the plaintext value you may be able to figure out the other encryption values. This is known as a "known plaintext" attack. However, this does not mean it works if you just happen to know two different encryption outcomes and know the input was the same, but you don't know the actual input.

Your question may also be that given encryption function f(key, masterkey) and then running it once with key1 and then with key2 would comparing the two outcomes allow you to figure out masterkey or would knowing the output of f(key1, masterkey) allow you to figure out key2?

It may be possible, but would depend on the specific algorithms, if there is padding, etc. If there is significant entropy in the algorithms then slight changes in inputs should give very different outputs that do not show patterns. You may also want to read up on "weak keys" and chosen-plaintext attacks.

  • Thanks Eric G, some good points to look into. Yes, my original concern was whether it would be easier for an attacker to determine the master key, having figured out that it was encrypted and stored and many times with the same algorithm, albeit different keys – Chris Rutledge Jan 5 '18 at 22:03
2

What's important to look at in a hypothetical like this is where your weak-points are, and what a breach of that will mean.

So in this case, we have a very strong master decryption key.

Obviously, we are storing this encrypted with something Sufficiently Strong (TM).

Now we come to the worlds oldest cryptographic weakness of user passwords. Say you have 1000000000 users. All of them are security/comp sci PhDs who've written dissertations on good password management. One is Jim. Now, Jim is the owner's son. When it comes to security savvy he's about a 3 watt. His password is passworddrowssap, and he thinks he's very clever for thinking of that.

Some day your database gets breached. Exfiltrated off-site, no less. They throw all of the User_tbl data into hashcat and go away for a few hours. They come back to one breached password - Jim's. Now they can decrypt the master key using Jim's password. Now they have complete access to all the sensitive, encrypted data in the database. Thanks, Jim.

Your solution isn't terrible, and I can't think of a real good solution, but it offsets all of the database security down to the weakest password your users use.

  • So, lets say I don't store the user's password in the database, so there's no list of hashes to be send off to hashcat (see answer at security.stackexchange.com/questions/23409/…)? I concede that the encryption of the password is still available to the attacker and that there maybe a similar service to try to decrypt...but I'm guessing this would take longer than guessing/computing hashes? – Chris Rutledge Jan 5 '18 at 16:15
  • @ChrisRutledge Assuming you're properly using a KDF like PBKDF2 then decrypting something with the key is not nearly as expensive as the key derivation. Idk if hashcat would support it but it probably wouldn't be very different performance-wise vs just comparing the hash directly. – AndrolGenhald Jan 5 '18 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.