3 Ways to Protect Passwords in WSH Scripts

Rather than reinventing the wheel each time they create a script, scripters often adapt existing code. However, there are many situations in which you might have a script but need to adapt it to run under a specific security context. For example, suppose you need a script to monitor Windows services locally and remotely and you find a script called ServiceMonitor.wsf. This script performs the tasks you want to automate. It uses Windows Management Instrumentation (WMI) to monitor services, restart a monitored service when it stops, and send an email alert if the service doesn't restart. However, you notice that to run ServiceMonitor.wsf on remote machines, users need to enter an ID and password when they launch the script. Because this information is entered on the command line in plaintext, this practice isn't secure. In addition, because the script provides alerts by sending email messages through a specified secured SMTP relay, the security credentials to establish an SMTP connection are hard-coded in the script, which is another insecure practice. Although you could configure the SMTP relay to accept anonymous connections, doing so is undesirable because it introduces other security risks.

Fortunately, there are several ways to work around these insecure practices. Three common solutions for Windows Script Host (WSH) scripts are to prompt users for passwords, encode the script, and run the script as a Windows service. Before I explain how to implement these solutions, though, you need to know a little bit about the ServiceMonitor.wsf script that we'll be adapting.

ServiceMonitor.wsf
Listing 1 shows an excerpt from ServiceMonitor.wsf. You can download the entire script from the Windows Scripting Solutions Web site. Go to http://www.windowsitpro.com/windowsscripting, enter InstantDoc ID 44580 in the InstantDoc ID text box, then click the 44580.zip hotlink.

To launch this script, you use the command

ServiceMonitor.wsf ServiceName  [ServiceName] [/Machine:value]  [/User:value] [/Password:value]

(Although this command appears on several lines here, you would enter it on one line. The same holds true for the other multiline commands in this article.) In this command, each ServiceName parameter specifies the name of a Windows service to monitor. You can specify one or more services. The /Machine, /User, and /Password parameters are optional. If you don't include them, the script will connect to the WMI system on the local host by using the security credentials of the user running the script. If you want to connect to the WMI system on a remote machine, you use the /Machine parameter's value to specify the name of the remote machine, the /User parameter's value to provide the user ID for the remote connection, and the /Password parameter's value to specify the password for the remote connection.

The overall structure of ServiceMonitor.wsf is similar to the structure of the GenericEventAsyncConsumer.wsf script, which I documented in the Exchange & Outlook Administrator article "Exchange 2000 SP2 WMI Updates," January 2003, InstantDoc ID 27211. Therefore, I won't dig into the details of the script here.

Prompting for Passwords
One way to secure passwords is to have the script prompt users for the required passwords when they launch the script. Windows Server 2003 and Windows XP expose a new COM object called ScriptPW.Password. This object works in conjunction with the standard input stream to read any text input. This object doesn't display the input text on the screen, which is perfect for a password prompt.

To modify ServiceMonitor.wsf to prompt for passwords, follow these steps:

1. Delete the code that callout A in Listing 1 shows. This code isn't needed because the script will prompt users for passwords.

2. Add the