1

In my web application I need to store some (very) sensitive data for my users. This data only needs to be available to the end user for the duration of the active session. The users log into the web application using username/password with 2FA.

I'm thinking about encrypting this data using user's password as the key. When the user logs in to the site, if the password is correct, I can then decrypt the data using this password as the key and store it in the session.

While theoretically this may be an OK solution, I still feel that this may not be very secure. Additionally, strong encryption algorithms like aes-128-cbc or aes-128-gcm require an initialisation vector, which would need to be stored to enable decryption - and I don't have an answer to this just yet.

So, is this approach reasonable or is there a better solution to this?

1 Answer 1

1

I wouldn’t encrypt directly with the user password. Rather use the users password, passed through some key-derivation like PBKDF2 — and use the output of that as a Key encrypting key (KEK)

Then use the KEK to encrypt a unique key that is used for encrypting/decrypting the user data. This also simplified user password changes, but beware, users who lose their passwords will also lose access to the data, for many use-cases this is unacceptable.

The problem with this approach is that someone in possession of the password would be able decrypt the sensitive data. Plus weak passwords will be a weak-link in the setup.

A separate approach would be to generate a unique key for each user, and encrypt that key with something like Amazon KMS. That way you’d be able to decrypt the data using Amazon KMS and the encrypted key.

This way, if someone dumps the database, the sensitive data is still secure since the attacker won’t have access to the sensitive data, because they wouldn’t have access to your key on Amazon KMS.

The downside is that a full-blown compromise of your aws account would compromise the data — but hopefully you’re monitoring to KMS and can see suspicious activity before things get out of hand.

1
  • This does sound more secure, albeit at the cost of more complexity plus the need to store the extra unique keys for each user. Loosing the data in case of lost password isn't a massive problem for me, as it's always provided by the user in the first place. It would be a minor inconvenience at worst.
    – Aleks G
    Feb 4, 2019 at 13:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .