Implementing password recovery in my app

Question

I have an Android App that stores encrypted data using a key derived from user entered password (PBKDF2). If any user forgets their password, they loose access to all their data. Hence, I am trying to implement a password recovery feature that is hacker resistant, including in cases where the phone may be rooted and the sqlite database is accessible.

Here's my solution. I randomly generate and store an internal password in the app. I then encrypt the user's password using this internal password using AES, and further encrypt the output and the user's email using my RSA public key. I store this RSA encrypted value.

If the user forgets their password, I submit the RSA encrypted value to my website. The website will decrypt the value using my private key and will email the app encrypted user password value to the email address found, as an attachment. On clicking the attachment, the user password is decrypted using the internal password, user is logged in and made to change their password.

Do you foresee any weaknesses with this approach? I guess if the user's phone is compromised, then the person holding the phone can check emails and retrieve the password. So perhaps adding a secret question and answer would help, but some people end up forgetting the answer to that as well.

Answer 1

Encryption is not enough for password storage, even if the decryption key is not stored on the same device.

Encrypting the passwords twice and storing two decryption keys in different locations, one on the client device and one on the server, does increase security but it isn't foolproof. One could imagine a scenario where a server admin gets hacked and attackers both get access to the server and can push out an update to the app to clients, compromising both client and server in one go. So it's best to just follow security best practices and hash the passwords before encrypting. And it doesn't impact the password recovery you suggested besides the fact that users would recover a password hash instead of the password, which could then be used to reset their password.

A common different approach to make password reset less difficult is to use a separate generated key for data encryption (DEK) and protect that key with a key derived from the password (KEK). A password reset then means to change the KEK that we encrypt the DEK with, rather than changing the DEK and having to decrypt and re-encrypt all stored data with a new DEK.

To enable password reset in E2EE setups, some services gives the user a secure password reset key when signing up that the user is expected to write down and store somewhere safe. This is in essentially a second KEK that can be used to decrypt the DEK just like you could with the password. This can be combined with a regular email authentication to add extra security in case the user didn't store the reset key securely. This approach also doesn't require the user password to be stored anywhere, except in a securely hashed form.

An example setup could look like this: We have a $DEK$, a password derived $KEK_{pwd}$, a password reset key stored by the user $KEK_{reset1}$, and a password reset key stored by the server $KEK_{reset2}$. If the user remembers the password then they can calculate $KEK_{pwd}$ and simply get the $DEK$. If the password is forgotten they can get their safely stored $KEK_{reset1}$, authenticate with the server to get $KEK_{reset2}$, and then combine them to get the $DEK$ and choose a new password. If the user loses both the password and the $KEK_{reset1}$ then they lose all their old encrypted data. The $DEK$ encrypted with the $KEK$s could be stored locally on the user's device or on the server, doesn't matter too much since it's encrypted anyways.

Additionally you probably want to use a memory hard or cache hard key derivation function for your passwords rather than PBKDF2 as that would offer much better protection.