There is a healthy debate around a series of stack overflow posts that refer to the "RunAs" command. Specifically the discussion is in reference to design decision that the folks at Microsoft made a long time ago, to users of this command to enter the users password in one specific way, Raymond Chen accurately summarizes one side of the argument quite clearly:
The RunAs program demands that you type the password manually. Why doesn’t it accept a password on the command line?
This was a conscious decision. If it were possible to pass the password on the command line, people would start embedding passwords into batch files and logon scripts, which is laughably insecure.
In other words, the feature is missing to remove the temptation to use the feature insecurely.
If this offends you and you want to be insecure and pass the password on the command line anyway (for everyone to see in the command window title bar), you can write your own program that calls the CreateProcessWithLogonW function.
I'm doing exactly what is being suggested in the last line of Raymond's comment, implementing my own (C#) version of this application that complete circumvents this restriction. There are also many others who have done this as well. I find this all quite irritating and agree with sentiment expressed by @AndrejaDjokovic who states:
Which is completely defeating. It is a really tiresome that idea of "security" is invoked by software designers who are trying to be smarter than the user. If the user wants to embed the password, then that is their prerogative. Instead all of us coming across this link are going to go and search other ways to utilize SUDO equivalent in windows through other unsavory means, bending the rules and wasting times. Instead of having one batch file vulnerable, i am going to sendup reducing overall security on the machine to get "sudo" to work. Design should never smarter than the user. You fail!
Now while I agree with the sentiment expressed by Microsoft and their concern with "embedding passwords into batch files" (I personally have seen poor practice myself way too many times), it really does strike me as wrong what Microsoft has done here. In my specific example I'm still following best practices and my script won't store credentials, however I'm forced to resort to a workaround like everybody else.
This decision really follows a common pattern at Microsoft of applications acting in ways that are contrary to the needs of the specific users with the intention of "helping" the users by preventing them from completing a action that is viewed as unfavorable. Then obfuscating or purposely making the implementation of workarounds more difficult.
This leads us to a broader question, extremely relevant to this issue, who is the true responsible party when it comes to security around credentials, the user of the software or the designer of the software? Obviously both parties hold some responsibility, but where is the dividing line?
When you create tools for other developers should you seek to the best of your ability to prevent them from using your application in an insecure manner, or do you only need to be concerned about the application itself and whether it's secure internally (irregardless to how the user invokes it)? If you are concerned about "how" they are using your application, to what extent do you need validate their usage (example: should "RunAs" fail if the system is not fully "up to date" i.e. insecure in another way), if that example seems far fetched, then define that line, in the case of "RunAs" the intention is quite clear, the developers who created it are not only concerned about managing credentials securely internally with their application but also care deeply about the security implications of how you use it. Was their decision correct in validating the usage in this case, and if so/or not where should that dividing line be for the applications that are created in the future?
