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:
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
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
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)