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?"

Team Cohesion

Every year Microsoft sends out a survey which the execs and managers use to help get the pulse of the worker bees. One of the areas where our group didn't do as well as we would have liked was around inclusion / team cohesion. My manager asked me what I thought we could do in this area, and here are my generalized thoughts.

Common Goal and Purpose

            To start with, there must be an underlying goal which is understood and believed. If the goal is not clear and concise, then there is no coordinated direction. This leads to wasted work (if it isn't truly important to the vision) and marginalizes peoples' contributions or places greater rewards on other team members. Dissatisfaction and discord can also set in if the team doesn't think the goal is reachable or doesn't agree with its direction. The vision is the foundation which your team needs to rally behind and gets everyone marching in the same direction. Changes are needed if people don't believe or understand why their work is important. Often this can be helped by improving communication or cutting unnecessary features and focusing the team on what is important.

Communication

            Good communication is fundamental in ensuring everybody feels included, this means that decisions which impact team members must be understood and believed. Ensure that decisions are not created a vacuum, at the wrong level, or by the wrong people. This is where strong leaders and program managers pay off, they will help drive the features and make sure all the necessary players are informed and brought in on decisions. Additionally, small changes such as office layouts and organization chart optimizations can help foster easier coordination between the individuals who are working on related technologies.

Rewards and Motivation

            Exclusion is a sure way to alienate someone from the team. Recognition, cool projects, gifts, benefits, etc. all need to be appropriately spread around. Militaries across the world have all used unit citations to help build a collective level of pride in a team. It doesn't matter how much an individual contributed (if at all) because, when recognized, everyone in the unit got them. Individual rewards have their time and place but they can weaken the overall team cohesion. Also, make sure that events, entertainment, food options, etc. are all open and inclusive. You definitely don't want a morale event to do more harm than good by alienating the very individuals you most desperately need to improve the morale on.

All of these things can make an impact to how tightly an individual will be integrated within an organization; all it takes is a good leader to help kick some of these into place. But keep in mind that one of the underlying concepts here is empowerment. Do you encourage the employee to make a meaningful difference, or are they just tools to get a job done?