In an episode of the bygone TV series "Banacek," burglars duplicated their intended victim's office in the same floor-plan position on another floor of the same building. A rewired building elevator delivered the victim to the faked floor. When he opened "his" safe, he found it empty, but in the process he revealed its combination to the thieves -- who used it to open the real safe in the real office.
It takes pre-teen willingness to suspend disbelief to make this story line work. No one could possibly construct a convincing duplicate of my office without spending 10 times the street price of all it contains. Where would you even begin to look for well-aged empty Frappuccino bottles? Only an office that's as tidy and clean as a movie set could ever be faked in this fashion.
A Web site, however, is easy to clone, and only the geekiest among us actually look at the status display of a browser to see what physical IP address we're visiting when we type in a URL name. That's why it's so alarming to find security holes in the Berkeley Internet Name Domain (or BIND) server software or in the Domain Name System in general. It's easy, oh so easy, for someone to lead you to a Web site where you'll type in user name and password information -- without even looking closely to see if the site's background colors are a little bit off. The rogue site swipes the data, sends it to the real site and returns the results to you, but retains your personal information for future use. (Invisible background services, like those implied in Microsoft's .Net strategy, will make this sort of thing even less likely to set off alarms.)
Why these attacks work
From the beginning of multiuser computing, there have been ways to induce disclosure of information that people would rather keep to themselves. Unix system administrators, for example, have to be told again and again never to execute routine system commands from a user's home directory: Running the simple "ls" (list files) command, for example, while logged in as the superuser, could actually run some other program that the user has placed in a personal directory to take advantage of that careless slip. The rogue "ls" piggybacks on the administrator's privileges to carry out some nefarious purpose, then executes the real "ls" command and returns an apparently normal list of files.
These Banacek attacks (yes, I just coined that expression; we'll see if it catches on) work because we're used to having a system demand that we prove who we are; we're not yet in the habit of demanding that a system prove its right to ask for our ID, let alone show its own. But authentication has to work both ways.
Not only must systems authenticate their users (not their users' terminals or other client devices, but users as individuals), but a system must also prove that it's the one we believe it to be, or our lives on pervasive distributed networks will be one long detective story -- one where the stolen goods aren't always found by the end of the hour.
