Firesheep sniffs unsecured connections with major Web sites over local networks and lets a user with the Firefox plug-in installed sidejack those sessions. A trope has spread that the way to solve this problem is to password protect open Wi-Fi networks, such as those run by AT&T at Starbucks and McDonald's. The technical argument is that on a WPA/WPA2 (Wi-Fi Protected Access) network in which a common shared password is used, the access point nonetheless generates a unique key for each client when it connects. You can't just know the network password and decode all the traffic, as with the broken WEP (Wired Equivalent Privacy) encryption that first shipped with 802.11b back in the late 1990s.
Steve Gibson, a veteran computer-security writer and developer, suggested this the moment Firesheep was announced. A blog post at security consultant Sophos makes the same suggestion. But it won't work for long.
Gibson notes the key problem to this approach in the comments to his post: every user with the shared key can sniff the transaction in which another client is assigned its unique key, and duplicate it. Further, if you join a network with many clients already connected, you can use the aircrack-ng suite to force a deauthentication. That doesn't drop a client off the network; rather, it forces its Wi-Fi drivers to perform a new handshake in which all the details are exposed to derive the key.
Thus, you could defeat Firesheep today by assigning a shared key to a Wi-Fi network until the point at which some clever person simply grafts aircrack-ng into Firesheep to create an automated way to deauth clients, snatch their keys, and then perform the normal sheepshearing operations to grab tokens. I would suspect this might be dubbed Firecracker
The way around this is to use 802.1X, port-based access control, which uses a complicated system of allowing a client to connect to a network through a single port with just enough access to provide credentials. The Wi-Fi flavor of choice is WPA/WPA2 Enterprise, and the secured method of choice is PEAP. Even if every 802.1X user logs in using PEAP with the same user name and password, the keying process is protected from other users and outside crackers. Update: Reader Elmae suggests "Little Bo PEAP" instead of Firecracker.
Even though 802.1X is built into Mac OS X since about 2004, Windows starting in XP SP2, and available at no cost for GNU/Linux, BSD, Unix, and other variants (as well as for older Mac/Win flavors), it's got just enough overhead that hotspots haven't wanted to use it.
While hotspots aren't liable for people sidejacking with Firesheep or simply sucking down and analyze traffic on their networks (disclosure: IANAL), 802.1X is cheap and easy to implement when there's a single user account and password. It's possible we'll see some uptake. The long-term solution is for all Web sites that handle any data to encrypt the entirety of all user sessions.
Update: Commenter foobar pokes a hole, pun intended, in my suggestion for using 802.1X with a single user name/password: Hole196. This vulnerability, documented by AirTight, afflicts 802.1X networks. It allows a malicious party to spoof the access point for sending broadcast messages, and allows ARP and DNS poisoning. Thus Firecracker could become fARPcracker, and, once again, Firesheep emerges victorious. (I wrote about Hole196 for Ars Technica; it's not that big a deal for the enterprise, but it's perfectly easy to use in a hotspot.) Thus, sites securing all their connections with SSL/TLS becomes the only practical method to ensure privacy and prevent sidejacking.
Photo by Magic Foundry, used via Creative Commons.
