The other day we went riding with one of our neighbors in Wawona (that's the part of Yosemite National Park where the giant redwood trees live.) On the hour-long drive to the South end of the park, we fell to talking, as neighbors will.
Mostly we talked about what a great place Mariposa is to live -- and about the sacrifices we'd each made in order to move here. The incredible beauty of the place's natural setting (55% of Mariposa County lies in either Yosemite or the Sierra National Forest) turned out to have been one of the strongest draws for both our neighbor and us. The relaxed pace of life was another.
A feeling of personal safety was a strong third for all of us.
Our neighbor confessed that she'd actually once lost her housekey for six months. It didn't matter to her, since she never bothers to lock her front door, despite the fact that she and her husband both work full-time.
Mariposa is like that. Out in the sticks, where both they and we live, most folks don't trouble themselves to lock their houses. After all, it's a sparsely-populated place with a small-town feel and it often seems like everyone who lives here knows everyone else.
Back in the big city, where anonimity is the rule, the population density is high and so is the crime rate. So you'd automatically assume that people deadbolt their doors -- and maybe have burglar alarms, to alert them when their locks fail.
But you'd be wrong -- at least where wireless LANs are concerned.
You Know My Name (Look Up the Number)
According to Andrew Garcia, of ZDnet's eWeek, unnamed "officials" at Cisco Systems Inc.'s Aironet division (Cisco's wireless arm) estimate that up to 50% of all users never bother to turn on the Wireless Equivalent Protocol (WEP) that is the industry's current -- and, with mere 40-bit encryption, pitifully weak -- standard security bulwark. That is (or should be) a startling figure, even assuming that it is a largely anecdotal one.
(I wonder exactly how those anonymous "officials" came up with their numbers, since Cisco enjoys nowhere near the stranglehold on the wireless space that it maintains in the router market for the wired world. Still, even taken with a barrel of salt, those figures give me pause -- as they should you.)
More compellingly, one-time fugitive and phone phreak uber-hacker Kevin Poulsen -- now gone legit as the editorial director for SecurityFocus.com -- recently took a drive through San Francisco's high-tech SoMa district with cypherpunk security consultant Peter Shipley, casually looking for unsecured WiFi networks. Inside of an hour Shipley had logged 80 of them, including one with the Service Set IDentifier (SSID) "tangentfund" -- an apparent mutual fund in which you might not want to invest.
Shipley, who coined the term "war driving" for his survey method (a reference to the BBS-era practice of "war dialing", which was itself a tribute to the demon-dialing modem of David Lightman, the character played by Matthew Broderick in the 1983 movie "War Games",) plans to map all the unsecured 802.11b networks in San Francisco, Oakland and much of Silicon Valley. His guess is that he will find thousands of open nets before his survey is complete.
Mind you, these open networks aren't consciously trying to be community nets -- networks specifically and intentionally open to all comers as alternatives to commercial ISPs -- like those listed on Apache founder Cliff Skolnick's toaster.net. Instead, they're business and personal WiFi nets that, for one reason or another, have been left unsecured, with no access control or data encryption enabled.
Into the Great Wide Open
The one reason that's so often the case is that all the Wireless Access Points (WAPs) currently on the market are shipped from the factory with WEP turned off. The other reason is that those WAPs' WEP configuration is a pain in the patoot, requiring the network administrator to navigate a maze of poorly-explained options, confusingly distributed across multiple separate pages. Many admins don't bother. Even those who do implement WEP generally choose to allow all their users to share a single password -- and changing that password involves touching every one of their users' machines, so they mostly don't.
Worse still, enabling WEP by itself provides admins the mere semblance of security with no more than a trace of its actual substance. Not only is its encryption strength ridiculously inadequate -- any gigahertz-class processor can break 40-bit encryption within hours, even via the brute force approach -- but a team of researchers from Zero Knowledge Systems and U.C. Berkeley have established at least four known exploits of the gaping holes in its fundamental architecture.
WEP is not the answer -- and that should be no news to regular developerWorks readers. Indeed, it can easily be part of the problem, since it provides a false sense of security -- which is arguably worse than no security at all. (When you know your network is not secure, you're not tempted to become complacent about it. If you think it actually is secure -- and it's not -- you're liable to ignore early indications that your net is under attack.)
The fact is that implementing useful solutions is universally non-trivial. At a minimum, in addition to enabling WEP, it involves setting restrictions on which ports are available to users (no admin in his/her right mind should ever allow wireless users to run ftp or http servers, for instance.) In larger organizations, it may make sense to force all user logins to take place via a Remote Authentication Dial-In User Service (RADIUS) server, using the Extensible Authentication Protocol (EAP). However, the expense in hardware and in technical labor and expertise that's required to set up and configure a RADIUS server is well beyond the capabilities of many small businesses and non-profit organizations.
Not to mention that EAP (and Cisco's proprietary implementation, LEAP,) introduces a major source of interoperability headaches, requiring multiple rounds of firmware upgrades and myriad tweaks to make current-generation, multi-vendor wireless nets behave.
Frankly, the whole problem of wireless security is a mess. And WEP2 isn't going to be that much of an improvement, because, like its forebear, it will be a politically-driven compromise, rather than a solution that springs from bottom-up design.
And, like WEP, WEP2 will be disabled by default.
Begin the Begin
Simply flipping that default value -- shipping WAPs from the factory with WEP enabled -- would be a long step in the right direction. So would debugging firmware for interoperability issues, before releasing it. So, for that matter, would turning WEP2 over to the IETF.
It might take the IETF a while to do it, but it would most likely generate a better-architected solution than WEP2 promises to be. Group E of the IEEE is much too willing to permit vested vendor interests to trump fundamental architectural considerations -- and the result will be a security standard that's just as broken as the one it replaces.
None of which excuses user laziness, of course.
Ideally, one person needs to take ownership of security for every individual WLAN on the air. That someone needs to convince the entire user community -- and the management to which it answers -- that it must accept the inconvenience for the good of everyone. Then, after obtaining a thorough understanding of the local computing environment, performing an analysis of current threats to that environment and conducting a survey of the available responses to those threats, that person should generate a budget and obtain authorization to acquire, install, properly configure, test and document a constellation of carefully-considered, thoughtfully-chosen and cautiously-implemented technologies. Subsequently, he or she should supplement those technological barricades with a disciplined routine of vigilant monitoring.
But a lot of the time -- up to 50% of the time, according to those Cisco "officials" in Robert Garcia's eWeek story -- that's not what happens. Instead, someone in the office has (or knows someone who has) just enough knowledge to unbox the AP and read the setup section of the owner's manual. Once the AP is up and the first client connects to the net, everyone cheers -- and then they just start using the thing and never give it another thought.
The only cure for that problem is user education -- a goal that could more easily be reached if vendors incorporated a basic security tutorial as part of the setup instructions for their WAPs (and shipped them with WEP enabled by default). Then, once they understand the issues, admins will need tools to help them analyze and craft response strategies suited to their particular threat environments.
In that connection, IBM's researchers have built what looks like a very useful prototype appliance they call a Wirelss Security Auditor. It's a Linux-based application that runs on a Compaq iPAQ PDA and something very much like it may just turn out to be one of the more ubiquitous tools of the 21st Century -- assuming that wireless connectivity actually becomes the dominant model, just as we've all been assuring one another it must.
Bring It On Home
In the meantime, last week's horseback adventure in Wawona was uneventful, but fun, as was our hike to the Wawona redwood grove. And we were able to savor those experiences without any concern for the safety of our homestead because, unlike our neighbor, we had locked our doors before we left for the day.
Given the crime statistics for Mariposa County, that might not have been strictly necessary, but barring unauthorized visitors from casually entering our home in our absence made us feel more comfortable about leaving.
Of course, San Francisco folks appear not to be as concerned as we are about things like break-ins, theft and vandalism. They must not be -- or they'd lock the doors to their WLANs.
Kevin Poulsen's SecurityFocus article "War Driving by the Bay"
HTML summary of the security shortcomings of WEP with a link to the full draft report (in PDF format)
Larry Loeb's article, "What's Up with WEP?"
IBM's prototype iPAQ/Linux-based Wireless Security Auditor (WSA)
. . .
A somewhat different version of this work was first published by IBM developerWorks at
(Copyright© 2001 by Thom Stark--all rights reserved)