Handling sensitive data for a web application

Question

I'll save you the detail of the issues, but do let me know if you need any additional info that I'm not mentioning here.

The basic set up is that I have a web application, and on the browser the user will enter some relatively sensitive information that will be transmitted to the server through https. Unlike passwords for logins, these information submitted by the users will need to be available/readable to the users in the future, and hence reversibly encrypted.

I have found a few relevant posts, but I am not sure if I completely understand them. My initial thought was as follows:

1. Ask the user to submit a passcode along with their sensitive info.
2. On the server side, I encrypt the sensitive info using their passcode through AES etc.
3. I store the encrypted info in my database, and discard the passcode.
4. When the user needs to see the sensitive info, I ask them to type in the passcode again, which is then sent to the server.
5. Once I get the passcode, I use it to decrypt the info from my database, and send the decrypted info back to the browser.

Bottom line is that, I never store the passcode used as the key for the encryption. Now this is going to sound naive and broad, but can someone give me an idea of whether/how secure this procedure would be? My guess is that, since the key is nowhere to be found on the server, the info is as secure/insecure as the AES encryption method itself.

---

How to encypt sensitive data in database of a web app?

I've been reading answer from the above link, which involves a several additional layers of encryption. I can probably implement it, but are those additional steps necessary for my purpose? And if so, how did those steps make it more secure than what I have described above? For example, worst-case scenario, if the entire server is compromised, would this latter method be more desirable?

Thanks!

Answer 1

I think one main problem for the first approach is that once the passcode is lost by the user, there is no way at all to ever recover it (without brute-force). Depending on the kind of information that might be a requirement though.

So coming to the linked article it will explain how it solves that problem. It has more comfort and lets you implement it in the hopefully already existing change password algorithm to always generate a new KEK and re-encrypt the DEK. The password is more unlikely to be forgotten

Answer 2

You have two problems:

1) If you use a key generated from password to encrypt user's data, you will need to decrypt and encrypt data all again if user resets his/her password.

Solution: Use the approach proposed in the link you posted (DEK and KEK).

2) It is common that users forget their passwords especially if they don't login so often and data decryption always depends on the password.

Proposed solution: Use something that users hardly forget, i.e. their email addresses.

Encrypting:

1. Ask users to enter their email address
2. Concatenate email address with a salt and hash them to generate a key that will be used to encrypt the password
3. All this should be done in the user side (not server side)
4. You keep the salt and the encrypted password in your database (you should not keep their emails, or can you?)

If the user forgets his/her password:

1. Ask the user to enter their email address
2. Verify ownership of the email address by sending a verification email
3. Use the email address along with the salt you have to re-generate the key used to decrypt the password.

You don't want to generate KEK from email address because you will always need to verify the ownership of email every time user logs in your web app.