0

In order to securely store data for a logged-in user, I derive a key from his password when he connects and use it to encrypt the data stored locally for this user.

Without the user password, which I only get when the user connect (only a hash_mac of the password is stored locally for the login), I cannot decipher the data stored for this user.

However in such scenario, if the user loses his password, no one can decipher his data anymore. How one manage such issue?

  • 4
    You can't if it should be secure. If the password is lost the data is also lost, this is normal. – Daniel Ruf Nov 28 '15 at 17:58
3

Hard to tell how exactly you are encrypting things. In the exact situation you've described user's data is lost and nothing can be done.

However, if you are doing the whole scenario (mind you, there are many pitfalls, and it's easy to devise something that only appears secure), you have some options/

One possible scenario is that the user data is encrypted using a random key. This random key is then encrypted using password-derived key.

Good things about this schema:

  • When user changes password you don't have to re-encrypt all of his data, only the encrypted key, so password changing can finish in a reasonable time.
  • You can have several 'slots', each one containing the actual encryption key encrypted by something different - user password, some master password, whatever, use your imagination.

Bad things:

  • It's much easier steal the encrypted slot, mount an off-line password crack, and then return with known key and steal all data.
  • You have to be extra careful when disposing of a key - if you 'forget' the password, but not completely wipe data from slot, it remains open for password cracking.
  • Your master password/key/whatever is a much better target than user's individual passwords - after all you'll probably have one master password, that can unlock all users' data.
  • You subvert trust in your system - previously only user had access to his data, now the administrator has it as well.
  • Indeed I believe I should warn the user that if he loses his password the data is lost. this is the only truly secure way for me. even if get hacked and all the data is taken from the server it still does not contain enough information to decipher the data. – Nicolas Manzini Nov 28 '15 at 20:37
  • 1
    @NicolasManzini There's no 'magical golden key' that can decrypt it only to the 'good guys'. What's more, in this scenario you should also worry about the contents of your RAM. If someone hacks into your server it's plausible he can read some amounts of RAM. And if the server is seized while online, it's a few minutes at least when the RAM is still readable. Even after reboot, so it's possible to boot from USB and just dump whole RAM. – Torinthiel Nov 28 '15 at 20:48
  • Indeed I did not thought about the RAM access. I will get rid of the key asap from the memory. fortunately I do not need to encrypt a lot of data. – Nicolas Manzini Nov 28 '15 at 21:13
  • @NicolasManzini Wipe the memory before releasing it and look how to lock memory so that OS does not swap it to disk in the meantime. May I ask what project are you developing? – Torinthiel Nov 28 '15 at 21:20
  • I'm creating a payment method that potential client can implement on their own. Thus they need an API Key and secret that I must store and display to them when they connect to their control panel page. – Nicolas Manzini Nov 28 '15 at 22:05
0

One way to prevent disaster if the user losses their key is to use a backup key that can be used to decrypt the data without the user's password. When the user encrypts with their primary encryption key, they also need to encrypt to the backup key.

The second key may be an asymmetric key pair, so that the user (or attacker) only have access to the public key to encrypt their data so it can be decrypted by the backup private key, but cannot give the private key itself to anyone else (accidentally or otherwise).

If your data is large, you may also introduce a data encrypting key (DEK). Instead of encrypting the data using the user's password derived key, you create a DEK to encrypt the data and encrypt the DEK with the data with user's password derived key. You'd also encrypt a second copy of the DEK with the backup key.

Now the problem is how to protect this backup key. Various threat models gives various solutions to this. Some possible options:

  1. Use a hardware security module, with strong audit logging. You'd need to ensure that the physical HSM is located in a secure data center. The HSM ensures that secrets never leaves the HSM without it knowing. You'd need an organizational process for auditing the logs regularly.
  2. Use secret splitting/secret sharing to split the second key to multiple persons. A secret sharing such as Shamir's Secret Sharing allows you to split a secret N ways and requires at least M parts to reconstruct the secret. You can give one part to the user, one part kept by the system administrator, one part is kept by a third party that you both trust; to decrypt without password, you need at least two parties to disclose their share of the secret.
  3. Or simply tell the user to write/print the backup key down and keep it somewhere really safe.

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.