0

In my application I would like to encrypt user data in such a way that I do not have access to it. To do this I will follow the following steps:

  1. Generate 256-bit key
  2. Encrypt data with key
  3. Derive second key from password (PBKDF2)
  4. Encrypt 1st key, destroy plain text key
  5. Store hashed+salted password and encrypted key

Now my issue is this: I still need to provide a way to reset the password when it is forgotten.

I realise that following this trust-no-one style scheme directly counters the ability to provide a password reset feature but I am hoping for a solution that can help maintain the spirit of the scheme through a healthy compromise, without requiring a second secret from the user like answers to security questions or a trusted third party.

My ideas:

  • Storing a copy of the per-user encryption key with a key my application controls as a backup, ready to be re-encrypted with their new (reset) password for daily operations. To be clear, I am fine with having access to the data myself - instead I am aiming to limit the potential data a successful hacker could access.
  • On signup, sending a password reset link to thier email that contains a key in the link used to encrypt a backup version of the encrypted key, ready for re-encryption using the new password.
sousdev
  • 3
  • 3
  • 1
    Send a reset link. You should **never** have a password in a recoverable format. – forest May 16 '18 at 23:06
  • @forest Sending a reset link as I describe in the 'my ideas' section could result in the password, and therefore data, being unrecoverable if the email is lost or deleted. That's my issue with that idea. – sousdev May 16 '18 at 23:14
  • Unfortunately, that is the only possible way to do this securely. While you don't necessarily need to use email in particular, storing the password in **any** recoverable format (even if encrypted) is a big no-no and will get you put on the Plaintext Offenders website. – forest May 16 '18 at 23:26
  • @forest I am not storing the password in plain text, ever. – sousdev May 17 '18 at 00:02
  • Remember, anything you can access, a hacker can access. If it is encrypted but not hashed, you might as well be storing it in plaintext. – forest May 17 '18 at 01:03
  • @forest don't worry, the only version of the password that will be stored will be the hashed version :) – sousdev May 17 '18 at 08:12
  • Something similar to Keybase's paper keys could work for you – jrtapsell May 17 '18 at 09:27

1 Answers1

2

All the data that was encrypted by the data encryption key will be lost in this case, because as you said, the password was forgotten. Now if the password was merely changed, but not forgotten, then you could unwrap the data encryption key with the password-derived key upon initial login, store that previously-wrapped key in the session, then re-wrap and store the data encryption key again when the user changes their password. So that's not a problem. It's just that if the password is ever forgotten, then so is the data that depends on that password in order to unwrap the data encryption key. There's no other secure way around this, unless you have some sort of backup scheme, maybe protected by site-wide encryption with keys protected by, say, a KMS. But in that case, why wouldn't you just ditch password-based encryption to begin with, and use the KMS instead?

vrtjason
  • 1,085
  • 9
  • 10