Originally created 08/30/98

Number not in directory web page



Several astute readers have noted that I've been writing for several weeks now about how neat it is to have my personal phone directories posted on the World Wide Web so that I can get at them from most anywhere. So, where are the numbers, Mr. Smartypants? They're not on your Web page.

Well, of course they're not. You think I'm going to trust you with the home phone number of Bill Gates' cleaning lady? Janet Reno's hairdresser? No way.

No, until this week, I had this stuff stashed away somewhere safe, where you couldn't find it if you tried. This week, I decided to set the whole thing up correctly, with passwords; try clicking on some of the URLs listed under "Personal" on my page, which can be seen at www.dolinar.com.

Now, I'll try to impart some of this newfound wisdom to you, dear reader, although I must warn you right now that this isn't simple. If UNIX and shell accounts leave you cold, correctly setting up password protected links will set your teeth on edge. You might just as well spend the next two weeks at the beach. But if you're game, I am.

What do I mean by correctly? We'll make a big assumption to start with -- namely that your Internet service provider has set up security in a reasonably tight fashion.

A little background into UNIX security is in order here, as well: When you're dealing with your shell account and World Wide Web pages, you have a password. The password gives you the ability to add, delete and modify files in the directories you control. It also gives you permission to read from directories that are otherwise sequestered from the public -- your mail directory, for example. And finally, it allows you access to the "/www" directory where you put your Web pages and files that you want the public to see.

Anyone on the Internet, assuming they know the address for that directory, can read those files, but you are the only one who can modify the files because you have the password.

If you only have files in that directory, anyone who looks at it with a Web browser will get a listing of the files. If, on the other hand, you have created a Web page named index.htm or index.html, that page will automatically load when someone accesses the directory. The directory listing will no longer be available to a Web browser, and you'll have to use your FTP (file transfer protocol) program to look at what's there; other FTP users will be blocked too. You can also create subdirectories with the FTP program that also will be available to to the public, assuming they know where to look.

Looking at my directory structure, you'll see that "/Mail," "/News," and "/www" are all subdirectories of the account "/dolinar"; "/topsecret" is a subdirectory of "/www." This subdirectory contains the file "/index.html," and its own subdirectory titled "/reallytopsecret/."

For the purposes of a Web brower's URL, such a setup is typically abbreviated to the domain name and user name. For example, www.li.net/dolinar/ is read the same way as /export/users/disk1/dolinar/www/ so that browsing at www.li.net/dolinar/topsecret/reallytopsecret/ will give a listing of the files in that directory -- in this case, jenny.html, jenny1.gif, jenny2.gif, and jenny3.gif.

We can take advantage of this scheme to prevent the rest of the world from looking at private directories and files. (This week, we'll look at how I've done it in the past relatively simply; next week, we'll address how the experts say it should be done.)

My first suggestion follows the traditional mainframe saying "In obscurity lies security," which is to say, it's pretty hard to hack something you don't know exists. To accomplish this, you create a wacky set of nested subdirectories and stash all your secret files in the last deepest directory.

In the example above, for instance, the directory /topsecret sits beneath our regular Web directory, "/www." Since the Web page "index.html" is also in the "/www" directory, it blocks anyone from viewing the actual directory contents, including the subdirectory "/topsecret."

Let's try that again: If someone knew the directory existed, they could browse directly to it, but since "index.html" blocks the contents of the directory "/www," they have no way of knowing it is there. And the "/reallytopsecret/" subdirectory is even more obscure. In theory, you could give a friend or two access to "/topsecret," and still keep "/reallytopsecret," well ... secret.

The problem with this approach is that you have to remember the wacky path listing, and type it in correctly, which isn't easy to do even with simple URLs. Or you bookmark the path, at which point you can lose the bookmark, or others can find the bookmark if they're using your computer. And of course, you still can't do what we'd really like to do, which is embed a link to it on your home page.

Finally, such directories are subject to being guessed. We won't get into the slightly complicated exploits that can compromise such directories, except to observe that there are 30,000 or 40,000 sociopaths who do understand them. Still, this worked pretty well for me until I started to use my personal home page as an example in this column.

Would that I trusted you more.

Which brings us to the second dumb form of security. If you've decided that hidden directories are good enough for your security purposes, you can crawl a bit further out on a very creaky limb and create hidden links to them from your home page.

To embed links on your home page that no one else can read, you have to create hidden links, and remember where you put them. The simplest way is to use any old image-editing tool (Paintbrush works fine) to create a tiny image, say, 10 by 10 pixels, that's the same color as the background of your Web page -- which is to say it will be invisible against the background. Insert this invisible image somewhere on the page, and link your hidden directory or file to it.

Who's gonna know, huh? The fatal flaw here is that every hacker worth his salt does know that you can find these links by downloading a copy of the page and examining the raw HTML of the document. The approach is probably OK if you're the only one who's using your page, but as soon as you invite the public in, well, the party's over.

The right way, of course, is to use real password security, although this not a trivial job for beginners. While far from perfect -- I know way too many people who could shred this stuff like a Cuisinart shreds cabbage -- it is probably good enough for most of us, especially if we work under the assumption that using the Internet is like taking a shower in public.

We'll look at passwords and other security ideas next week, in eye-glazing detail.

Dolinar can be reached by e-mail at dolinar@newsday.com