How can I encrypt user content on my site so that even I canโ€™t access the content?

I need to encrypt the contents in my web application for each user.

I, the root user, do not want to have access to the contents of the user, period.

How can I make users the only ones who have access to their content? Perhaps I can make the hash of their login password be used as an encryption and decryption key (then their password is stored in a one-way hash in my database, and the hash / encryption hash is generated from their raw password at login and stored in local cookie)? But what if they change their password? Then I have to update all their contents, which can take up a lot of processing power.

Is there an encryption method that would provide this without having to re-encrypt their contents if their password changes? Perhaps something similar to ecryptfs on Linux? Is ecryptfs exploring a good place to start?

Does it make it so that only a user can access their content on my servers (and even me) is even doable?

+8
encryption
source share
2 answers

Process:

  • Create a random secret to encrypt their contents.
  • Using the provided password encrypts a random secret from # 1.
  • Save your password as a one-way hash (with salt, possibly with multiple hashes).

After changing the password:

  • Re-generate the value from step # 2.
  • Generate the hash cache from step # 3.

After logging in:

  • The hash password and hash check generated in step 3.
  • If the password matches, use the actual password provided to decrypt the random secret from # 2.
  • Use the random secret from # 2 to unlock the data encrypted in # 1.

Notes:

  • No one can decode data without knowing a random secret (# 1). A random secret can only be unlocked with the user's actual password (No. 2) (without brute force). The actual user password is known only in a one-way hashed form (# 3), so you can confirm it the same way, but you can not decode it and restore it # 2.
  • The process of forgotten passwords is impossible (you can regenerate # 3, but the random key in # 2 is now lost, like all those locked in their store).
  • You do not need to re-encrypt everything in step 1 every time they change their password, only the (simple / fast) random secret from # 2.
  • If you cache your provided password or random secret generated in step 1, or their (decrypted) content anywhere, you can cause a data leak.
+11
source share

You noticed that you need to use your password as a key.

I would not be a monkey with ecryptfs, because an encrypted file system is not the best solution. You do not want one user information to be encrypted using the same key used by another user.

When you encrypt data, you must create a random string to use as salt. This prevents someone from using the pre-generated hash list to decrypt your data. It also changes the hash of two people who can use the same password.

When the user changes his password, you will have to re-encrypt the data and create a new salt value. This is the level of security that I would expect as a client, knowing that when I change my password, I re-encrypt all my data so that someone does not try to iterate over my key.

You can save the salt value in your unencrypted database.

-one
source share

All Articles