I have a web app (which I've talked about here before). Users can use it to save people's contact details. These contact details are encrypted to ensure that they are difficult to get at if they're leaked.

The encryption system is also designed so that administrators can't access the data either. The encryption key is based on the user's password.

I'm looking into ways to enable password recovery. The problem here is that a forgotten password, at the moment, also entails a total data loss - since the key is based on the password, if you don't know your password then your key can't be worked out, and your data can't be decrypted. Not ideal.

I have a couple of ways to solve this:

  • Store decryption keys. This seems like a terrible idea from a security perspective, so I'd really rather not do this if it's at all avoidable.
  • Have two passwords. One to get into the account, one to be used for the encryption key. This is an impact on the users - they have to remember two passwords.

There may also be other valid methods that I can't think of. Neither of these seems greatly secure - or am I wrong? What secure ways are there of doing this?

  • I've asked about the usability of this feature on User Experience.
    – ArtOfCode
    Commented Mar 30, 2016 at 20:08
  • 4
    I take it that stating very clearly that password loss will result in data loss isn't an option? It's a good proof of your inability to access the data, so can be a selling point.
    – Matthew
    Commented Mar 30, 2016 at 20:09
  • @Matthew I'd rather have a way to recover the data, if it's possible. Of course, if there's no sufficiently secure method then I'll do that, but I think recoverable passwords would be a stronger selling point.
    – ArtOfCode
    Commented Mar 30, 2016 at 20:11
  • Important but nit-picky question: data is stored on the cloud in a datacentre you control, or on the user's device? Commented Mar 30, 2016 at 20:15
  • 1
    @ArtOfCode I guess what I was trying to point out that generally you don't derive the KEK from "something else" but there are several mechanisms for protecting two copies of the DEK with two different KEKs. One of which is derived from the password and used in the normal course of business, and one of which is a secondary mechanism for recovery.
    – Xander
    Commented Mar 30, 2016 at 20:31

1 Answer 1


To continue @Matthew's thought, let's make this very simple: do you want your admins to have access to user data or not?

I have never seen a system that completely prohibits admins from accessing the data, and also allows data recovery in the case of password loss... those two really seem contradictory.

All of the cloud services I can think of with the "we can't access it either" approach also have a data wipe as part of password recovery process. Examples:


The above assumes that you want a standard, light-and-fluffy user registration / recovery process. @Xander points out that if you're willing to put some extra burden on the users then you have options.

As you suggest in your question, you can (for example) put an encrypted copy of the decryption key on the server with the files - as long as you've encrypted this key with something else, like a key derived from a second password, or a key stored in a key file that the app generates as part of the registration process. (but then if the user leaves the recovery key file on the same device that the app is on, you negate all of the security).

At the end of the day, if they forgot their password, who's to say they're trustworthy with this stuff either? I'm not sure it actually solves the core problem of "make your system idiot-proof".

  • I don't think they're contradictory, it's just that solutions are cumbersome, and create their own vulnerabilities that you have to deal with. Giving the user a second KEK encoded in an recovery key file, for instance.
    – Xander
    Commented Mar 30, 2016 at 20:37
  • @Xander Fair. The spirit of the question is really "without adding any extra burden to the user". If you're willing to give users recovery key files, or recovery codes then I guess the game changes. Commented Mar 30, 2016 at 20:41
  • Ah, yes, if the intent is that it be no more effort than a standard password reset, I agree with you.
    – Xander
    Commented Mar 30, 2016 at 20:42
  • But I will expand my answer. Commented Mar 30, 2016 at 20:51
  • 2
    Re: recovery key file. If you're going to tell the user to save a recovery key file away somewhere they don't lose it, why not just tell them to do that with the password in the first place? The recovery key sounds like just another password on the account.
    – Macil
    Commented Mar 30, 2016 at 21:16

You must log in to answer this question.

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