0

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?

  • I'm proposing to close the question because answers will be primarily opinion based. But to mount a similar question: Who is responsible for car safety: the driver or the manufacturer? And consider when answering this, that unsafe driving impacts not only the driver. Similar there is also in impact to others if a computer is used in an insecure way. – Steffen Ullrich Jun 25 at 19:01
  • @SteffenUllrich I'm certainly running the risk of that, but it's a highly important question, and even with your example, that topic is still one that hasn't been fully answered either, if you take a look at DriverFocus for example, it's bit controversial because it crosses much more into the way the car is used vs the car's safety in and of itself. That said I would hope that there would be a industry guide or best standard for a question of this nature rather than a just series of opinions. – David Rogers Jun 25 at 20:07
3

Many forms of restricted usability exist to protect developers from negative perceptions resulting from widespread misuse. It's a numbers game. If RunAs was less restricted, related security failures would be the fault of the script authors (IMHO), but the industry might believe that the underlying software was insecure. If a junior admin got in trouble for embedding passwords in their scripts, they might also get angry that the mistake was so easy to make.

The "Right to Repair" discussion has a similar reasoning. It's partly about preventing shoddy repairs from being associated with the brand. If a "reconditioned" iPhone breaks easily, it's likely Apple that will be blamed to some extent, even if the reconditioning itself was at fault. It comes down to control over the quality of a product after it's in the hands of the user.

Who is responsible? Whoever is most likely to be blamed when something goes wrong. Perception is reality, especially when money is at stake. RunAs can be used in so many ways... the "misuse surface" is huge, which was likely a factor in their decision. It makes sense, even though the resulting annoyance factor is obvious.

Where should the line be drawn? Where enough users can't reasonably blame the developer for something that the user had control over. This is usually a function of how competent the user/team/company is when it comes to articulating their level of due diligence and ability to mitigate issues that arise. How much risk is acceptable vs. how many users will complain.

What design responsibilities do developers have? Developers should strive to provide idiot-proof security measures, while still allowing super users the flexibility they need. Elegant solutions do exist, and we should have enough empathy for the users to seek those solutions out.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.