I have created a utility that encrypts a file (.txt, .dox, so on...). The utility asks for a password from user at the time of file encryption.


Suppose a user has created 1000 encrypted files with different passwords and forgets his password of some file. How will he recover it?

My thoughts

I should log each password (encrypted) somewhere and by the name and size of file we can find the password of the file which can be provided to the user but here are some catches:

  1. There can be many files with the same name and size
  2. User can rename the file so here we will help less
  3. If we try to find the password by only size then there can be many files with the same size, then it will not be a good way to provide user the exact password.

I also thought to send the whole password log to user on his registered email but then I found this LINK and changed my thoughts.


What will be the best way to provide users the exact password of the encrypted file?

P.S: The utility is build using Objective-c, Cocoa for OSX

  • 1
    storing passwords in an encrypted form is generally a bad idea. Similar apps (7zip for example) don't offer a forgotten password option. Could you just display a 'make sure you keep this password safe' type message?
    – Jay
    Commented Oct 12, 2015 at 16:50
  • I have to give an option to user to retrieve its password beause there will be thousands of confidential files and in case if user lost a file just because he forgotten his password then it will be a headache for us. Password rest is impossible. I am just asking for a way to give user his password securely. Even if I log every password how will I come to know which password is for which file Commented Oct 12, 2015 at 16:57

2 Answers 2


It sounds like your main question is about how to be able to match encrypted files with the clear-text password for that file in your database. You can use a secure hash function, say SHA-256 to solve this problem. The algorithm is

  1. Get file and password from user.
  2. Encrypt file using password.
  3. Generate SHA-256 of encrypted file.
  4. Store password in your database using SHA-256 as key. Note that this is where the risk lies. Be sure to encrypt the password with a key that you store in a separate location. You'll also need to record which user encrypted the file as you'll not want to let Bob get the clear-text password of Alice's encrypted file.

When a user requests the clear-text version of their password, you:

  1. Calculate the SHA-256 of the file.
  2. Find the matching hash in your database.
  3. Perform appropriate access checks to make sure that this is their encrypted file.
  4. Return the clear-text password to the user.

Let me first clarify some of your thoughts:

  • You cannot have two files with the same exact name and type. You will have files with the same name but with a different extension. If you intend to store the file names and related encrypted passwords, use the complete file name for e.g. abc.txt/abc.pdf etc.

  • You must build your program in such a way that without decrypting the file you cannot rename it. If you allow renaming the without privileges it violates the principle of integrity and is not recommended. If you still wish to do it, update the name of the file in your stored file as well.

  • Doesn't matter. Searching the complete file name (abc.txt) will provide you with the primary key you need.

Your need to provide a Recover Password feature will have some attached complexity since it will require you to design an authentication system to make sure that the person recovering the password is the same as the person recovering it.

  1. You could use an email based password recovery system which is what a majority of the apps and websites execute. (You will need to store login credentials)

  2. You can use an OTP based system. Again you will need to store login credentials and the mobile number or something.

  3. Don't implement the feature. Stick to an alert stating the importance of remembering the password and the consequences in case they lose it. Have a check box with an I Accept message. :D

Hope I gave some insight. :)

  • Hahaha.. I have just returned to the point from where i had started. P.S: user can have files with same name with same extension at different location. Also, we can not bound user to not renaming the encrypted file :) never mind Commented Oct 12, 2015 at 18:32
  • Ohh true. You can then use the directory path to search for the key. Commented Oct 12, 2015 at 18:34
  • User can change file locations or move to some other location. It's possible that user will encrypt a file on MAC-A and tried to decrypt on MAC-B Commented Oct 12, 2015 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .