3

I am writing an app (Java) that stores potentially sensitive data in the cloud using a provider chosen by the user. So I am encrypting the files using AES/EAX + PBKDF2. That's the easy part, or so it seems.

I live in fear of the inevitable question: "I forgot my password, can you help?"

Thoughts so far are:

  1. Nothing can be done: anything I do weakens encryption for everybody. This is the answer a purist would give, I think. But is not really an option since it doesn't actually address the problem of password or data recovery.

  2. Generate a real random password and encrypt that with the users password and a random escrow password that I send to my server. This does not reduce the requests for help, but does provide a resolution but weakens everyones security.

  3. Do #2, but do not send to server, store the escrow password with the data and encrypt it based on the answers to three user-selected questions. This could be optional.

I am leaning towards 3. By being optional, it only weakens your security if you choose to do so.

I'd be really curious to know if there are any known "best proactices" for this kind of thing. Everything I have read is about web/server password resets.

RabidMutant
  • 133
  • 3
  • You can encrypt key with RSA (using public part only), and back it up. There was here recently idea to attach it to the file itself. However once your private RSA key is stolen then you will need to reencrypt everything. – Aria Sep 17 '16 at 12:29

2 Answers2

4

I responded on Stack Overflow, but I see this is posted here as well, so I repeat my answer from there:

You are dealing with a problem that a lot of serious security companies struggle with. Briefly:

You are correct that #1 is the most secure option. Some companies, such as SpiderOak, pride themselves that they are keeping the data so secure that not even they could access it under any circumstances.

If you do #2, then what is the point of encrypting on the client side in the first place? It would make sense if all you want is performance benefits, not security benefits.

For #3: Secret questions do not work.

Another alternative of using secret sharing to allow some type of password recovery. The user's password or the key that encrypts the user's data, is split into a number of shares that are distributed to trusted entities. Recovering the password or key requires these entities to work together. This prevents a single bad player from getting access to user data. Generally, it is better to do this with the cryptographic key rather than the password (passwords are sometimes shared between different systems so a user should not want that anyone sees his password). Unfortunately, this middle ground solution requires a lot of thought and implementation, and comes at an expensive administrative cost.

TheGreatContini
  • 171
  • 1
  • 6
  • I can't upvote here, but accepted because it's a really good response, even though it doesn't strictly answer the question, and I loved reading the references. The secret sharing option may even be viable if the user shares it with themselves: put half on google drive and the other half in dropbox. – RabidMutant Sep 18 '16 at 02:14
  • I particularly liked this bit "Generally, it is better to do this with the cryptographic key rather than the password"; password reuse was not something I had considered. – RabidMutant Sep 18 '16 at 14:20
  • The following links were in your pricing reply: Pitfalls: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/oakland09.pdf , Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google: http://research.google.com/pubs/pub43783.html ,and secret sharing: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing – RabidMutant Sep 18 '16 at 14:47
1

Key recovery is a very old question and on a conceptual point of view has not changed for centuries:

  • if only one key exist (read: only one person knows the secret), only the owner of the key can open the safe, but if the key is destroyed or lost (read: the user forgets his password), what is in the safe (read: encrypted data) is lost (*) => this can be used for personnal data when the risk of compromission is more serious than the risk of loss
  • this can be mitigated by creating a second key (read: a third party has access to the secret). If the key is lost or destroyed, the owner of the safe asks for the copy and immediately builds a new copy => this is used when the loss of data is the higher risk, on when the data is essential for more than one person, for example sensitive files of an organization.

In that latter case, the hard part is not technical, but is only organizational: how can the owner of the key be confident in the third party? For web/server passwords resets, the admins can always do anything on behalf of a user, so conceptually they hold a key and can give a copy to the owner. In medium to large organizations and highly sensitive data, a common usage is to have a safe (physical or numeric) that can only be unlocked by two different keys, and nobody should hold both keys - note: this is more or less how personal safes in bank work, the bank is responsible for the key of the safes room and the owner has the key of its personal safe. For less sensitive data, a security officer can hold copies - that is the way key recovery work with microsoft encrypted folder: the symetric key is crypted twice, once with the user's personal key, and once with an administrative key to allow an admin to recover the data.

So the good question is what is your real security requirement:

  • only user is responsible for its own data
  • the administrator (or help-desk or...) should be able to recover the data if a user was to lose its password
  • you really need two different persons to cooperate in order to recover data

The third way can be simply set up by encoding a symetric key sequentially with two different public keys, but recovery will be more complex because the owners of the private keys will have to work together.

(*) you can always try to break a physical safe, but some can be specially engineered to destroy their content in that case

Let's speak now of your actual problem. The 3 question game is a try for a multi factor authentication system. The problem is that someone knowing the person can guess the answers if they are true (and many people know a lot about celebrities) and the use can forget what he answered it he wants it not to be guessable by anybody. The best way for a user not to forget a particular password is to store it in a password safe like the excellent keypass. The analogy will be: I put a copy of all my keys in a single safe and I keep its key attached to my necklace. To avoid the loss of the passwords file, it is easy to sync a keypass on a desktop with one on a smartphone. Unfortunately it can only be used by educatable users.

If what you need is to allow the users to recover their password, it means that you have to build a copy (either on your server, or in the user's machine) encrypted with a public key for which you own the private part. If the copy is kept by the user, he will have to send it to you so that you unencrypt it and send it back. This part is highly sensitive and you could try to setup a multi factor authentication: a normal authentication and a secondary mail account for example. If the copy is kept by you, you should think about the consequences of your master key being compromised => breaks the whole security of the system.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Thanks you for the analogy, it is interesting as a first order approximation to the problem. I am very wary of such analogies, but I guess my Option #3 is equivalent to saying "I will make a copy of the key and lock it in a box that only I can open using some special knowledge that I possess". To be clear, I have absolutely no desire to involve a third party -- doing so is either cumbersome, or a weakness. What I am seeking to do is allow recovery by the user themselves. And the question is: is there a better solution than the one I suggested in option 3? – RabidMutant Sep 17 '16 at 14:50