Securing Chickens and Eggs

I saw a question get posted to an internal discussion group that went something like this:

I have a console application which uses CredUICmdLinePromptForCredentials. How can I add support to allow a user to pipe a password from a file into my tool? For example:

type password.txt | myTool.exe /user:user1

Answer: You don't.

The Long Answer:

The whole purpose for CredUICmdLinePromptForCredentials, its entire reason for existence, is to provide users a slightly more secure mechanism for supplying private authorization information.

• If a password is stored in clear text on your hard-drive, then it is not secure.
• If a password is sent in clear text via the command shell's pipe/redirection mechanisms, then it is not secure.
• If a password is cached somewhere (clear or obfuscated) that can inherently be used by an un-authorized person (replay attack), then it is not secure.

If you aren't attempting to be secure with a user's password, then there is no reason to use CredUICmdLinePromptForCredentials, just read the file or input stream yourself and be done with it.

Public Service Announcement: If you use one of the CredUI*PromptFor*Credential APIs, be sure to either nuke the password (SecureZeroMemory) or encrypt it (CryptProtectMemory) as soon as possible (i.e. immediately after the call and/or after any verification that needs to happen).

Now, the better question revolves around how one should secure credentials such that they can still be used in an automated process. Unfortunately this quickly degenerates into a philosophical question as computers are inherently insecure, especially if you have physical access to it (debuggers, physical analysis of hardware, etc. can expose your secrets). The issue becomes even more philosophical considering that the objective of the tool hasn't been scoped or discussed (and wasn't in the original post).

For the purpose of this (now philosophical) exercise, we assume that we are not on a single computer - as we are dealing with automation and want to distribute the credentials in a file. If we were on a single computer we might utilize the Credential Manager to help store this information locally.

To secure some chunk of data, we need to encode it. In order to decode the information we need a key. Unfortunately we now need to store the private key in a secure manner. Do we encode the key to secure it? If we fast-forward a bit, you can easily see that this quickly turns into a "which came first, the chicken or the egg" type of problem.

Since computers are insecure, the best place to store private information is not in a computer. The typical place is in a human. Now we've come full circle. In order to secure the file that contains a password, we need someone to remember a password (and people wonder why security is tricky). Now you can see that our philosophical exercise is flawed, so really the question is not "how do we secure the file", but "how secure is good enough?"