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
  • I've [asked about the usability of this feature](http://security.stackexchange.com/questions/119029/whats-the-most-secure-way-to-circumvent-encryption-to-enable-password-recovery) on [ux.se]. – ArtOfCode Mar 30 '16 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 Mar 30 '16 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 Mar 30 '16 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? – Mike Ounsworth Mar 30 '16 at 20:15
  • @MikeOunsworth In the cloud, though I don't control the datacenter (for this instance - obviously for a totally secure installation I would have to). Never on the device. – ArtOfCode Mar 30 '16 at 20:19
  • Not asked exactly the same way, but this is pretty close to a duplicate of [Handling “forgot password” functionality with encrypted data without security questions](http://security.stackexchange.com/q/118658/12), no? – Xander Mar 30 '16 at 20:19
  • How about key escrow with a Secret Sharing algorithm? – Tobi Nary Mar 30 '16 at 20:21
  • @Xander Similar, but it doesn't answer my question. Providing a mobile number won't enable me to derive the decryption key! – ArtOfCode Mar 30 '16 at 20:21
  • 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 Mar 30 '16 at 20:31

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
  • 58,107
  • 21
  • 154
  • 209
  • 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