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.

  • $\begingroup$ If the user deletes the application, install it, and they don't remember the password? Similarly, the phone is lost, and they got a new phone and don't remember the password. By the way, there is no perfect solution for this and the application doesn't handle this case... And remember if the user has a root phone... $\endgroup$
    – kelalaka
    Commented Jul 7 at 11:33
  • $\begingroup$ @kelalaka if the user uninstalls the app, it is a voluntary data loss and that's OK. Loosing their phone, may also be OK, assuming they have backed up the data to an external file. I am trying to avoid the case where the user still has access to their phone or a backup, but has forgotten their password. $\endgroup$ Commented Jul 7 at 12:09
  • $\begingroup$ This sounds like a key management and "key escrow" problem. Public key encryption, key derivation are your friends. I'm not making a formal answer because analyzing a particular requirement of cryptographic scheme design will be overly verbose for this site (I'd consider discussing the value of requirement analysis questions on meta). But as a topic that interest many people, I'm up-voting this Q. $\endgroup$
    – DannyNiu
    Commented Jul 9 at 5:00

1 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.

  • $\begingroup$ I've voted up this answer not based on merit of the described scheme, but based on the effort spent on it and the insight that it provides. $\endgroup$
    – DannyNiu
    Commented Jul 9 at 4:58
  • $\begingroup$ Actually,I didn't propose storing the user's password with another password and storing both info on the device. In fact the user's password will be encrypted using an RSA public key and stored. So only I'd have the key to decrypt that data, not the device. However, I will come to know the user's password, if they share the RSA encrypted data with me. Hence, they will first encrypt their actual password and the AES encrypted data is RSA encrypted and stored for later recovery. $\endgroup$ Commented Jul 9 at 11:56
  • $\begingroup$ @ShahidThaika Ah okay, I must've misread your question. That does add additional security. Would still recommend that you hash the password first though as it makes for more secure storage without any obvious drawbacks. $\endgroup$
    – n-l-i
    Commented Jul 9 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.