8

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?

Community
  • 1
ArtOfCode
  • 572
  • 3
  • 14

1 Answers1

6

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:

EDIT:

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".

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
  • 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 Mar 30 '16 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. – Mike Ounsworth Mar 30 '16 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 Mar 30 '16 at 20:42
  • But I will expand my answer. – Mike Ounsworth Mar 30 '16 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 Mar 30 '16 at 21:16