Preamble: I have been a long time lurker but first time poster to the Information Security site, so please be gentle with me.

The Situation: I ran into a situation where I needed to securely store a password on a file. Now I know that there are currently many best practices and industry standards for doing such a task but - one of my very first fleeting thoughts on the problem - was to store the password in a file that is only accessible if you already have the password that is written on the file.

Doing this does solve a legitimate problem and there are several better ways of doing it other than to save the password in plaintext. I am aware of this, but the question is more of a why not this way? It seems to be simple solution and often the simple solutions are the best.


UserA's password is mypass this password is stored in plain text on the file password.txt.

The folder that password.txt is in is owned by UserA.


The disk is encrypted so that only the User who owns a file can read it.

The relative protection for file permissions and user passwords are the same.

The permissions for that folder and all objects within that folder explicitly deny all access to everything inside the folder except for the owner. (for the sake of argument say that no other users including root/NT Authority/etc) has access to this folder and it's contents; only UserA.


To read the password in password.txt (which is mypass) you need the password mypass.

If you were to crack the password (mypass) to get access to the file password.txt you would effectively be cracking mypass anyways.


So in a theoretical sense, if you could meet all the conditions in the assumptions, would my password be secure if the contents of the file containing my password was in a secured file?

Is there a name for this type of security as described in this question?

Are there any serious logical flaws in a system like this to secure a password on a file?

Keep It Theoretical

I tried to keep this as agnostic to OS as possible because the purpose of this question is not to question whether or not this is a viable method. In fact, there are several popular methods of accomplishing this very task and most will require that any passwords saved to file be encrypted:

i.e. The send-mailmessage cmdlet for PoSh has a parameter

-credentials (username,password) 

but it explicitly will not accept the password in plain text form. This was implemented to actively discourage IT professionals from saving passwords in plaintext on files. I just want to know why it is discouraged.

EDIT 1/16/2016 First of all, thank you all so much for your quick responses and feedback on this question! I have edited my post to clarify a couple of points that were brought up.

Added Comments in the Situation section to explain that this a common practice in SA/Automation work. Also, added a *Keep it Threoretical** section to clarify that I wish to keep this theory as OS agnostic as possible. Thanks!

  • 2
    Why bother reading the password out of a file, if you already have the password before you open the file? The logical flaw would be that the point of storing a password in a file is so you can get the password out when you don't know the password. If you need to know the password to get the password, you put yourself in a catch 22 - if you have the password you don't need the file. If you don't have the password you need the file but can't have it. If you don't need the file, you can have it. If you need the file you can't have it. (Is there a "security by bureaucracy"?) Commented Jan 15, 2016 at 21:39
  • 1
    I'm assuming there's some automated process that needs the password inside password.txt? Otherwise Tessellating is right, it's a pointless catch-22 exercise. Commented Jan 15, 2016 at 22:10
  • Yes @SteveSether , that was the exact scenario. For this particular task, I need to re-enter my credentials in one of the steps required to complete the automated task as the command I was calling has the username and password combination as a require parameter. Once again, I know there are a plethora of established ways to accomplish this, but I am just very curious why this way is not in use as it seems like a very simple solution and I can't -for the life of me- figure out why it is wrong; but it just leaves a sense of "wrongness" about it. Commented Jan 15, 2016 at 23:43
  • 1
    @Get-HomeByFiveOClock because this isn't a solution. At the risk of repeating my previous comment, if you have the password you don't gain anything from the file existing because you don't need to look at the file. If you need the password, you don't gain anything from the file existing because you can't read the file. The file might or might not be 'secure', but it's not useful. (Alternately, if you're saying "I logged in earlier and validated my login, can I unlock the file later to get my password using my previous auth" - I think you're reinventing Kerberos tickets, only not as good). Commented Jan 16, 2016 at 1:54
  • 1
    But it is useful in the sense that it is required to be saved somewhere on the computer for a task I am running! Of course, I know the password in my head, but when "x chron-job" or "y-scheduled task" runs at midnight while I am asleep; the computer does not require me to manually enter the password. Commented Jan 16, 2016 at 2:01

2 Answers 2


The logical flaw in the scheme is that you need to know the password in order to access the password. This nullifies any valid use for storing the password in the first place. So, it's not so much a paradox as a fallacy.

If your real goad is simply to store a password as securely as possible, then your architecture generally makes sense, but replace the construct of a password-in-a-file-that-requires-the-same-password with that of a password manager, when the password is stored in a password manager protected by a strong master password, and a second factor.

  • 1
    It's possible that there's an automated action that uses the password to login to an external resource of some sort. Commented Jan 15, 2016 at 23:27
  • Xander, as @NeilSmithline just commented, the main goal is not just to "secure" the password, per se. It is to store the password in a secure way so as to be capable of referring back to it when the need arises. Commented Jan 15, 2016 at 23:47

This seems weak protection for something as important as a password. Your solution is based on the assumption that just because you are the only user on your computer, everything that you execute is trusted. Unfortunately, this is not the case.

Windows User Account Control was created to help protect against the running of malicious code. But the random directory that you are using is not protected by UAC. So it is open to any process running under your user account.

Generally, passwords are considered so critical that they aren't even stored encrypted. Rather, irreversible hashes are used to store them. For example, Windows only stores a hash of your account's password. So, while I understand that you wish to have automated and easy access to your password, I think any security-conscious solution will require you to encrypt the password and provide a password at time of access.

One could argue that being that you're creating a one-off solution, nobody would think of looking in this directory for your password so you are safe. But this is just the old security through obscurity argument.

  • Thanks for the thoughts! I absolutely agree with you 100% that this is weak protection for a password and I did eventually come up with a better way of solving the problem. The problem is I already know it is weak protection and this "bad solution" is going to bounce around my head for hours (or days) until I can figure out "why* it is a bad solution. Also, I tried to keep this OS agnostic as I am sure any password saving solution using this method would ultimately be bad. Commented Jan 15, 2016 at 23:59
  • @Get-HomeByFiveOClock- Do you have more questions? Commented Jan 16, 2016 at 20:44
  • I'm sorry, come again. More questions about what? Commented Jan 16, 2016 at 21:19
  • I assumed you were looking for something else as you didn't upvote or accept my answer. Sorry to trouble you. Didn't mean to beg for reputation. Commented Jan 16, 2016 at 21:21

You must log in to answer this question.

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