One way to prevent disaster if the user losses their key is to use a backup key that can be used to decrypt the data without the user's password. When the user encrypts with their primary encryption key, they also need to encrypt to the backup key.
The second key may be an asymmetric key pair, so that the user (or attacker) only have access to the public key to encrypt their data so it can be decrypted by the backup private key, but cannot give the private key itself to anyone else (accidentally or otherwise).
If your data is large, you may also introduce a data encrypting key (DEK). Instead of encrypting the data using the user's password derived key, you create a DEK to encrypt the data and encrypt the DEK with the data with user's password derived key. You'd also encrypt a second copy of the DEK with the backup key.
Now the problem is how to protect this backup key. Various threat models gives various solutions to this. Some possible options:
- Use a hardware security module, with strong audit logging. You'd need to ensure that the physical HSM is located in a secure data center. The HSM ensures that secrets never leaves the HSM without it knowing. You'd need an organizational process for auditing the logs regularly.
- Use secret splitting/secret sharing to split the second key to multiple persons. A secret sharing such as Shamir's Secret Sharing allows you to split a secret N ways and requires at least M parts to reconstruct the secret. You can give one part to the user, one part kept by the system administrator, one part is kept by a third party that you both trust; to decrypt without password, you need at least two parties to disclose their share of the secret.
- Or simply tell the user to write/print the backup key down and keep it somewhere really safe.