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:
- Ask the user to submit a passcode along with their sensitive info.
- On the server side, I encrypt the sensitive info using their passcode through AES etc.
- I store the encrypted info in my database, and discard the passcode.
- 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.
- 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.
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?