Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

News Flash: Spaces are legal characters in both filenames and passwords!

News Flash: Spaces are legal characters in both filenames and passwords!

  • Comments 33

I recently figured out a problem that I've been having with one of our internal tools.  The tool is used to automatically deploy our daily builds (extremely handy when you're doing that every other day to several test machines).  As a part of the tool, you need to include the password for a test account.

We normally use the tool from an automatic test harness, essentially I enter the 4 or 5 parameters to the test and it automatically runs the tool (and other stuff if necessary).

The problem I had was that I would enter my account and password but the tool kept failing after reporting invalid parameter errors.  It worked perfectly when I used a different account that is used by our testers, but when I tried using my preferred test account it kept on failing with some kind of command line parsing error.

Eventually I tracked down the actual command line being passed by the harness into the tool and I was immediately able to see the problem.

 

Being a security geek, my "password" is actually a passphrase - the theory is that passphrases are harder to crack than passwords because they are drawn from a larger dictionary.  So my passwords tend to be things like "The rain in Spain falls mainly on the plain".

In this case, the test harness took my password and passed it to the tool as follows (assuming that the command line for the test tool is "testtool.exe -useuser <username> <password>:

testtool.exe -useuser testaccount The rain in Spain falls mainly on the plain

Doh!  Either the test tool or the test harness wasn't handling the spaces correctly.  I tried an experiment and ran the test tool manually:

testtool.exe -useuser testaccount "The rain in Spain falls mainly on the plain"

and it worked!  So it appears that the problem was that the test harness wasn't correctly handling the spaces in my password.

 

So I went to the maintainer of the test harness and described the problem to him.

His response?  "I never knew you could have spaces in a password!  Wow, I didn't even think of that."

 

Sigh.

On Microsoft operating systems, spaces have been legal in filenames since MS-DOS 2.0 (about 1982) and in passwords since MS-NET 1.0 (about 1984).  I'm astonished that 25 years later there are people who still don't know that.

  • I hear you man.  I encounter this sort of thing (not with passwords, but filenames) all the time.  I sympathize.

  • And thus, "Program Files" and "Documents and Settings" were born - apocryphally, to force the others that didn't know that filenames can contain spaces.  So when you see an app that wants to install in C:\Litware, guess why (often, anyway)?  

    Heh, we had an issue with our app on 64-bit Windows because Oracle didn't like the parentheses in Program Files (x86).

  • (Eh, I don't know if you're as zealous about "don't name names" as Raymond, so bowdlerize accordingly.  I personally don't like to reward vendors with shoddy or lazy things like this and prefer to point them out.  I remember a post on "don't spam the quick launch/system tray/top of start menu with your crapware" and a comment was, "I wondeR who hE's tALking about"

    http://blogs.msdn.com/oldnewthing/archive/2003/09/03/54760.aspx#54762)

  • Mark, I try not to disparage other vendors, simply because it's stupid to point fingers - there's more than enough blame to go around.

    Sometimes you need a forcing function :).

  • Unfortunately, this isn't (to my knowledge) the only internal MS tool that fails at handling passwords with spaces in them - there are so many others that I had to give up on using spaces in my passphrases and instead smush everything up into one word. Makes for an interesting experience when you're trying to type your password out in a hurry. :)

  • Of course.  We all make mistakes, but then there's willful/negligent/lazy stuff (like Apple's new Safari "flaw"/"not flaw").

  • OK, but don't you get tired of typing long passwords? How often do you unlock your workstation?

  • Larry, it sounds to me like normal command line parsing. The -useuser option takes two arguments, username and password. In the unquoted version you have given it a password ("The") and several other arguments ("rain in spain..."). One or more spaces separate arguments on the command line. If you want embedded spaces in your argument, quote it.

    To see the nightmare that results when software tries to figure out quotes that aren't there, look at CreateProcess:

    http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

    "

    For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

       c:\program.exe files\sub dir\program name

       c:\program files\sub.exe dir\program name

       c:\program files\sub dir\program.exe name

       c:\program files\sub dir\program name.exe

    "

  • Dave, the issue here is that the tool correctly handles spaces on the command line but the test harness <i>didn't</i>.  The reason that the test harness didn't was because the maintainer of the test harness had no idea that spaces were legal in passwords.

    That's why I figuratively threw my hands up in exasperation.

  • Adding quotes solves this problem.

    But it would not solve the problem of Unicode characters in user name/passwords, which are also valid :-)

    I know, the console has /U and some level of Unicode support, but it is tough to tell in this case (testtool would need to use wmain, for instance :-)

  • On the other hand, quote marks are also legal in passwords.  Whether or not you can cover that case as well without modifying testtool.exe depends on the details of how it processes the command-line arguments (and arguably on whether those details are documented).

  • Sure, Harry, if the test harness did something like "%password%" (assuming it uses batch file syntax) to call testtool, it could be foiled by a quote. But it is kind of scary that the developer didn't know the args could have spaces. Just don't put him in charge of validating Internet data.

  • "spaces have been legal in filenames since MS-DOS 2.0"

    Hmmm.....while technically that may be true for the underlying FAT filesystem, they were effectively useless as there was no way of escaping spaces on the DOS command line. So such filenames were not usable from DOS. They may have been usable from applications that ran on top of DOS and FAT, but they were not usable from DOS itself. I'm not sure when this changed but I suspect not until maybe DOS 5 or more likely DOS 6.

  • I didn't know spaces were valid in a Windows password until I happened to be watching a Microsoft video a year or three ago.   Oh I knew all about file names having spaces but not Windows passwords.

    I'm a database developer specializing in MS Access for the last ten or fourteen years.  I've been using Windows at least that long.  

    Many, many users don't know that either.  I've asked around. I'd suggest adding some text to the Windows login screen.

  • News Flash: Spaces are legal characters in both filenames and passwords! My comments to that posting

Page 1 of 3 (33 items) 123