0

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!

  • Someone could maybe make a better answer than me, so I'll just give you a comment. What you suggest is OK. The link you give is a better way to do it, because (1) you can easily handle the encrypted data (for example when users change their password) and (2) it uses a PBKDF to avoid brute-force attacks. There are multiple ways (encryption modes) to use AES, some of them insecure. In your case, AES-CTR would be a good choice. Maybe you need to also authenticate your encrypted data, in this case, please edit your question or ask another one. – A. Hersean Oct 22 '18 at 7:43
-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

  • What you describe is not in the linked article, and it would be an insecure scheme. – A. Hersean Oct 22 '18 at 7:27
-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.

  • 1
    In your scheme number 2, the server has all the needed data to decrypt the users' sensitive information. – A. Hersean Oct 22 '18 at 7:30
  • 1
    "something that users hardly forget" is also something that non-authorised people would also know. This is the same problem as "what is your mother's maiden name?" That's why passwords need to have some level of uniqueness. Emails, though, is a very, very poor example, especially if you ask for it directly. – schroeder Oct 22 '18 at 8:38
  • the web app is using email address and salt to generate a key but it is not keeping the email address! He can also use mobile number @A.Hersean – daygoor Oct 22 '18 at 8:49
  • He is not using the email as password .. never said that in the answer! read carefully! Email + salt is a combination used for encrypting the real password used for login and encrypting data. Email known by user and salt known by server! @schroeder – daygoor Oct 22 '18 at 8:51
  • Please read again schroeder's answer. The user's email is a public information, it is not a secret. – A. Hersean Oct 22 '18 at 8:53

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.