13

As a sort of follow-up to this question on handling password-reset functionality when dealing with encrypted user data, is there any good method for resetting a user's password in an encrypted web application without using security questions?

From a security standpoint, the problem boils down to needing a second key to unlock the data in case the first (the password) is lost, leaving:

  1. Security questions

    • I would rather not implement these due to both security and user-experience concerns (in my experience, either the questions will be so obscure that the user likely won't remember them, or the answers will be publicly-available information, defeating the whole purpose)

    • This is certainly the approach that most users would be familiar with, and will be the one I implement if I can't find any other good solutions

  2. A backup key

    • An example being Apple's "Recovery Key", which you are supposed to print out when you enable two-factor authentication for your Apple ID

    • This is an extra step that the users will either not take, or will take and later lose their recovery key, leading to confusion and a poor user experience

    • Other possibilities include an app on the user's mobile device that stores a second key until needed, but that seems like overkill to me, and likely a step that the users will forget about, leading to the app not being re-installed when they get a new phone, for instance

  3. Some form of key escrow

    • My first thought here was to allow users to connect an external account with OpenID Connect, but none of the common providers (Google or Facebook, for example) return any sort of unique, stable, and secret value that would be useful as a second key into the account (the closest thing from Google is a unique account identifier, which every site requesting access to their Google account will receive)

Are there any options that I've overlooked here, or any clever solutions anyone can think of that don't involve security questions?

EDIT: To clarify, for this specific application, it's a requirement that I (or any other developer or administrator of the system) not have access to any of the unencrypted data, at any point in time. This means that methods such as sending a one-time code will not be sufficient, as it requires that, at some point, I have access to the key to decrypt the data. (This restriction excludes the brief amount of time that the key is in memory when the user submits it in order decrypt their data. I'm more concerned about offline decryption of a dump of the data than the application itself being compromised to leak/store keys)

Mike Lewis
  • 230
  • 1
  • 7
  • 1
    Just an opinion, unsupported by facts: Key escrow is the way to go. As you point out, security questions or backup keys require some degree of responsibility, which is unlikely to be met. You can control the key escrow system, which obviously represents a significant risk, but it's probably your best bet wrt to the user experience. – Jesse K Mar 29 '16 at 19:03
  • Another note...The examples of escrow you provide are not actual escrow, which involve a trusted third party. An app on the users device would be a (fairly heavy) backup or recovery key mechanism, and data from an existing account would simply be a alternate key. – Xander Mar 29 '16 at 22:04
  • @Xander, yeah the app certainly isn't key escrow, and I'm not entirely sure why I put it in that section. For the account from another service, how would you classify it then? It wouldn't be something that the user has access to, or anything stored in their account, but something effectively released by a third party when both parties agree to it being released (the user by approving an access prompt, and the server by requesting the key in the first place). I agree that it's a gray area in that it's tied to something under the user's control, but I'm not sure what else to call it. – Mike Lewis Mar 30 '16 at 00:34
  • @MPLewis To be honest, I don't know what I would call it. It's novel, in my experience. To have an escrow you need a trusted third party who knows they're responsible for your key, and for validation the conditions under which it is to be release, and trusted to not release it under other conditions. In this case, you'd be relying on secret, secure data from a provider that would have no idea they were involved in key management for there system, and it would be the user alone responsible for providing the key from the third party. – Xander Mar 30 '16 at 20:34
  • That said, it's a very interesting idea, and I do believe that it could work. I just don't immediately know how, or what the security considerations would look like. It'd be fun to investigate and think about. – Xander Mar 30 '16 at 20:35
  • I don't mean to shill my own product too much, but this problem irritated me enough over the years that I decided to build [Bunkyr](https://bunkyr.com) to solve it. Bunkyr provides a lightweight API to deterministically generate encryption keys from an OAuth/OpenID Connect account and unclonable cryptographic hardware. If you're having the same problem I did all these years ago, feel free to reach out! – Mike Lewis Jan 12 '22 at 20:48

1 Answers1

1

I agree with you on the security questions issue.

How about having the users give you their mobile number as a backup so that you can then text them a one time code, which they will then enter to prove they are who they say they are? It is actually how Yahoo does this now. You can create a free account there (or probably already have one) and test this feature.

The only issue is that it requires your users to have mobile phones. Though, you have already mentioned mobile phones in your Key Escrow solution so I am guessing your users will be expected to have them.

V_RocKs
  • 19
  • 2
  • While I do like the idea, it's part of the application's requirements that I not have access to the unencrypted data at any point (aside from the small amount of time between when the user submits their password to decrypt it and it actually gets sent in an HTML page, which is unavoidable). Please correct me if I'm wrong, but there doesn't seem to be any way of accomplishing this without effectively storing a second key to the account somewhere. – Mike Lewis Mar 30 '16 at 00:26
  • To help further I would need to know you would have handled security questions if they were used? Because if you could have asked me which color my car was in college, you could also ask me to verify a phone number you have stored under my account with a token you create and send to me via text messaging. – V_RocKs Mar 30 '16 at 15:36
  • The answers to the security questions would be concatenated and run through a key-derivation function (like PBKDF2) and that key would be used to decrypt the contents of the account. At no point in this process would the plaintext security answers be stored on the server. The only way I could send you a token that could be used to access your account would be for me to have the key necessary to decrypt your data in the first place, which is something that I cannot do. – Mike Lewis Mar 30 '16 at 18:40