I coach my son’s PONY League baseball team (13- and 14-year olds), and this past week we’ve been having tryouts: the kids get a chance to field some grounders and fly balls, to take some cuts in the batting cage, to run the 40-yard dash and, if they want to, to show off their skills at pitcher and/or playing catcher. At this age the game is pretty competitive, particularly for the team I help coach. (In
Because the game is very competitive, tryouts are a serious business, and we coaches all find ourselves standing around the batting cages or behind the backstop, surreptitiously writing down our observations. Now, if you don’t have kids you might be thinking, “Oh, I get it, you have to be surreptitious because the kids might take a peek and see what you wrote down about them.” Surprisingly enough, though, the kids don’t care: at this age, they all think they’re superstars. It’s the other coaches we’re worried about, the other coaches who might “accidentally” glance over and see what you had to say about little Bobby over there. (I’ve outsmarted them, however, by not knowing anything about baseball. That way, if they follow my recommendations, they’ll end up taking the lousy players, and we’ll get all the good players for ourselves.)
Note: By the way, because this is a blog and because I can write whatever I feel like writing, don’t be surprised to see a lot of baseball stories and the like show up here. I admit it would be more appropriate to tell you some scripting stories, but the truth is, I don’t have any scripting stories. I have lots of coaching stories, though. For example, a few years ago I helped a friend of mine coach a basketball team (9-year-olds). When it came to playing defense we always told the kids, “Don’t lose your man. Stay with him wherever he goes. Don’t lose your man.” We put a kid named Tony in, and the guy he was guarding promptly scored two uncontested lay-ins. There was a timeout and the team came back to the sidelines. Before either of us coaches could say anything Tony remarked, “Coach, I didn’t lose my man. But he sure lost me.”
By the way, I have lots of stories when it comes to that team. For example, we were shutout three games in a row. In basketball! You’ll probably hear more about that team – and others – as the weeks go by.
Anyway, our need to be surreptitious in writing down notes at the baseball tryouts reminded me of the fact that, as script writers, you occasionally need to be surreptitious, too. For example, we Microsofties always tell people, “Don’t hardcode passwords in your scripts. If you do that and someone gets a copy of your script, why, then they’ll know your password.” That’s really good advice, but it’s not foolproof advice. After all, we tell you not to hardcode the password, but to instead have your script prompt you for the password. That’s great, but how do you do that? Sure, you can type it in at the command prompt (maybe entering it as a command-line argument) or you can type it into an input box, but in both cases the password will – at least until you press ENTER – be sitting out in the open, just waiting for someone to pass by, glance into your office, and go, “Ah, so that’s the administrator password.” All you’ve really done is replace one security vulnerability with another.
What’s needed, of course, is a way to mask passwords, a way to type in a password without the actual password displaying on the screen (just like when you log on to Windows in the first place). Prior to Windows XP, there was no straightforward way to do this. In our Windows 2000 Scripting Guide, for example, we told people they could use Internet Explorer and an HTML password box to mask passwords. That works fine, but it seems like overkill to instantiate an instance of Internet Explorer simply to type in a password.
In Windows XP and Windows 2003, however, there’s a COM object called ScriptPW that only does one thing: it masks anything you type in from the command prompt. (I know, it is weird in this day-and-age to find a piece of software that only one thing, regardless of how useful that thing might be.) Of course, there are two minor caveats: ScriptPW runs only from the command-prompt, and only under Cscript. But that’s OK; just make sure you start your script from the command-prompt, and it will work just great.
Let’s take a look at ScriptPW in action:
Set objPassword = CreateObject(“ScriptPW.Password”)
Wscript.StdOut.Write “Please enter your password:”
strPassword = objPassword.GetPassword()
Wscript.Echo “Your password is: ” & strPassword
Not much to it, is there? But, then again, that’s the beauty of ScriptPW: simple and to the point. Let’s take a look at what’s going on in this script.
In line 1, we create an instance of ScriptPW. (Like I said, ScriptPW is a COM object, so we use CreateObject, just like you would for any COM object.) In line 2, we use the StdOut Write method to write a prompt to the screen. At this point in time, our command window session looks something like this:
C:\Documents and Settings\gstemp\Desktop>cscript test.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
Please enter your password:
Now comes the cool part. In line 3, we call ScriptPW’s GetPassword method, and we assign the value we get back from GetPassword to the variable strPassword. What value do we get back from the GetPassword method? Well, that depends. GetPassword sits patiently at the command-prompt and waits while you type in your password. While you type, nothing appears onscreen; instead, the cursor will just blink at you. It might not look like anything is happening, but it is; after you call GetPassword, ScriptPW will keep track of everything you type until you hit ENTER. As soon as you do press ENTER, GetPassword scoops up whatever is in the buffer and assigns it to strPassword. Your password is safely stashed away in strPassword, yet never once appeared onscreen. Try it; it’s cool.
The rest of the script is there just to prove to you that GetPassword actually works; we’re simply echoing back whatever you typed in. In real life, of course, it would be a bit silly to mask a password and then turn around and display that password onscreen. More likely you would then use the password to connect to something. For example, maybe you want to connect to Active Directory using alternate credentials; in that case, you’d use the value of strPassword to represent the password part of those alternate credentials.
Of course, you aren’t limited to just masking passwords with ScriptPW; in fact, ScriptPW has no concept of what a password is. It just masks whatever gets typed at the command prompt. If it’s a password, great; if it’s not, well, so what? Any time you have a need to mask something being typed at the keyboard, ScriptPW will do the trick.
Ok, so I’ve given you a useful little scripting technique you likely knew nothing about. Now, let’s get back to that basketball team I used to coach. Have I mentioned the time when a blizzard struck while one of our games was going on? When we got back out to the parking lot, one of our parents was stuck in a snow bank. Mark, my fellow coach, and I spent a good 15-20 minutes pushing the guy out of the snow and back onto the road. As soon as we got him back on track, he rolled down the window, gave us a wave – and promptly drove right back into the very same snow bank and got stuck again.
I guess with parents like that it shouldn’t be a big surprise that we didn’t win any games that year.