40

This Stack Overflow question suggests a command which looks as if it should work, but it doesn't (that answer is deleted now, though):

Single line command for Run as a different user on Window 7 that contains a password also

The command would be:

echo PaSsWoRd | runas /user:Administrator cmd

However it says:

unknown user name or bad password.

The details are definitely correct though. For example, if I was to run:

runas /user:Administrator

...and on the next line, if I typed in PaSsWoRd, it would work no problem.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Accendi
  • 627
  • 1
  • 7
  • 15
  • 2
    How about `runas /user:Administrator “cmd” < “C:\pass.txt”` – Kind Contributor Jul 01 '16 at 07:08
  • 3
    You can use `runas /savecred ...`, it will prompt for password once, then remember it. _(see the password storage `rundll32.exe keymgr.dll,KRShowKeyMgr`)_ – Qwerty Oct 10 '18 at 10:18
  • 1
    `/savecred` [doesn't work](https://serverfault.com/q/784616/58957) with `/netonly` though. Most solutions I tried do not work. I didn't try psexec, as it's [rather heavyweight](https://stackoverflow.com/a/49638671/1026) for me, but I [had success](https://serverfault.com/a/999680/58957) with the [RunAs module for powershell](https://github.com/gfody/PowershellModules/tree/master/RunAs) and the built-in Windows ["Credentials manager"](https://dba.stackexchange.com/a/66022/15599). – Nickolay Jan 20 '20 at 16:59

1 Answers1

49

The runas command does not allow a password on its command line. This is by design (and also the reason you cannot pipe a password to it as input). Raymond Chen says it nicely:

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.

Community
  • 1
  • 1
Bill_Stewart
  • 22,916
  • 4
  • 51
  • 62
  • 11
    1) I didn't make this decision, so ranting about it to me is pointless. 2) Microsoft definitely made the right decision. Embedding passwords in a script is an egregiously bad idea, for the main reason already stated in the answer. – Bill_Stewart Sep 08 '17 at 14:59
  • 14
    you could psexec from microsoft sysinternals e.g. psexec -user MyUser -p MyPassword "cmd" – user797717 Jan 27 '18 at 12:27
  • 1) Using that "feature" is a bad idea and egregiously insecure. 2) You still cannot elevate from a non-elevated process without provoking the UAC prompt. – Bill_Stewart Jan 27 '18 at 15:41
  • 2
    If anyone is curious: The "answer" from @N.S (which was, oddly, posted as a separate question rather than as another answer here) suggests using the `WshShell` COM object's `SendKeys` method to simulate typing a password for the `runas` program. That's even more insecure than if `runas` accepted a password on its command line, because it will send the keystrokes to whatever window has the current focus! I hope it goes without saying that this is a very, very bad idea and I hope nobody is actually doing this. – Bill_Stewart Oct 17 '18 at 18:28
  • this topic has closed so i could not send answere so i wrote it as a new post. about security your right i just wanted to give a method to do the job. every one edit the code can read your password , so you can write a function to recive the password or what else needed. – N.S Oct 17 '18 at 18:43
  • here is code in a vbs file – N.S Oct 17 '18 at 18:44
  • 1
    Set oShell = CreatedObject("WScript.Shell") oShell.run("cmd.exe") WScript.Sleep 30 oShell.AppActivate "cmd" oShell.SendKeys "runas /user:poorTarget cmd.exe" oShell.SendKeys "{ENTER}" oShell.SendKeys "password" oShell.SendKeys "{ENTER}" – N.S Oct 17 '18 at 18:44
  • As I already noted, this is a very bad idea. I hope you are not really doing this on a production system anywhere. – Bill_Stewart Oct 17 '18 at 19:27
  • 16
    Some of us have to live in big company hell where horrible hacks are the only way to duct tape things together. – Carbon May 28 '19 at 20:34
  • I refer the honorable gentlemen to the answer to this question and my previous comments. – Bill_Stewart May 28 '19 at 22:34
  • 1
    My intent wasn't to antagonize but to point out that this is an example of [when people ask for security holes as features](https://devblogs.microsoft.com/oldnewthing/20050504-52/?p=35713). There are other secure ways of running an executable without exposing (administrative!) credentials in such an egregious way as embedding them in plain-text in a script. – Bill_Stewart Sep 26 '19 at 17:31
  • 1
    Fair enough, I apologise for going off on an uncalled-for rampage...your comments just hit a nerve as I've struggled with 1000's of instances of "I can't run/do this thing I want to do on **my own** computer that **I paid** good money for" since Windows XP. I do agree however that the average user should not be able to do such things without understanding the full implications. The fact that power users have to suffer as a consequence?? Well it just sucks IMO :-( – Kenny83 Sep 26 '19 at 17:46
  • True power users, IMO, are more than capable of learning how to work with the system rather than against it. These kinds of security restrictions are not arbitrarily put into place to annoy people. – Bill_Stewart Sep 26 '19 at 18:28
  • 1
    @AndrejaDjokovic usability-wise, yes user should be given more control. But the issue why it is prohibited is related to legal and money. When a user's PC suddenly was hacked due to usage of such password literals in scripts that is made by user themselves, the user starts to blame the developer company, and start suing. This is what developers trying to avoid - aka losing money for user's stupidity. – GeneCode Oct 08 '19 at 01:04
  • As an aside: Downvoting this answer is silly, because the answer is correct. Not liking the answer doesn't change the fact that it's the answer. – Bill_Stewart Jan 27 '20 at 15:50
  • 2
    Bill_Stewart +1 for a great answer even though I don't agree with it. I'd side with @AndrejaDjokovic on this one, that said this is a excellent topic for a [separate security specific ticket.](https://security.stackexchange.com/questions/233775/who-designer-or-user-should-be-resposible-for-the-correct-secure-usage-of-a-to) it's a broader question, who's exactly should be responsible for the security of the "usage" of a application? – David Rogers Jun 25 '20 at 16:18
  • As noted already, MS made the decision not to allow a password on the `runas` command line. If you want to write your own program to do it, you're free to do so, of course, but at least MS isn't responsible for potential abuse. (Such a program is a bad idea anyway, IMO, as there are other ways of automating without exposing passwords in plain-text in a file.) – Bill_Stewart Jun 27 '20 at 15:05
  • 2
    Microsoft treats professional developers and system administrators as children. We are not children, we have good reasons to perform tasks such as this ones. If a developer creates a security risk because of negligence, the problem is the developer, not the operating system. The should provide a system to security execute programs as another user, such as the `sudo` in Linux. – Tk421 Dec 20 '20 at 22:31
  • As already mentioned several times, this design decision was intentional, and I guess I would be repeating myself if I said it's pointless to complain about it here. – Bill_Stewart Dec 20 '20 at 23:26
  • Well this is totally possible to do a 1-liner from Dos. Just use powershell. powershell -command "& {&'Start-Process' -Credential (New-Object System.Management.Automation.PSCredential ('domain\user', (ConvertTo-SecureString 'Password123' -AsPlainText -Force))) -FilePath "notepad.exe"}" You can also add -verb runas to force admin rights – Rosski Jul 25 '22 at 14:10
  • 1) A cmd.exe command prompt window is not "Dos". (DOS was a single tasking 16-bit operating system.) 2) Elevation will still provoke a UAC prompt. This is by design. 3) I guess I would be repeating myself if I said it is a very bad idea, for an innumerable number of reasons, to embed any kind of administrative password in plain-text in a script. – Bill_Stewart Jul 25 '22 at 21:17