Steve Gibson suggests using WPA/WPA2 Personal encryption on hotspots to prevent Firesheep from working among users on the same network: That's an interesting idea, but only for the moment. Gibson explains the weakness to his solution in a comment below the post. I recommend at the bottom a solution involving WPA/WPA2 Enterprise that builds on Gibson's recommendation.
The shared passphrase version of WPA lets an access point and Wi-Fi adapter (the "station") negotiate what's sometimes called a session key (the pairwise transient key). You can't extract or crack that session key without watching the initial association during which secrets are sent, but which a party with the passphrase could monitor. But not so fast. You just need to force a deauthentication—currently not guarded against in 802.11 or Wi-Fi, but which will be one day—and all the stations will run through their four-way handshake again.
Someone who might run Firesheep, a point-and-click credential theft Firefox plug-in and proof of concept, is likely to not download and install Wi-Fi cracking software that would aid in this. Aircrack-ng, the gold standard, requires some technical know-how to use.
But the code is freely available and licensed under the GPL. Firesheep is also free, open-source, and available. All it would take is an interested party to combine the two into an active attack agent—perhaps called Firecracker. This would move use of the extension from potentially illegal in some jurisdictions (passive scanning may be legal, but sidejacking is probably a crime in most states and many countries), to definitely illegal in most areas (forcing deauthentication in order to obtain credentials). But it could still be a point and click operation.
Thus, a WPA/WPA2 Personal protected network would briefly afford some protection against Firesheep, it wouldn't be long lived.
The more sensible action is one I first heard discussed years ago. Enable WPA/WPA2 Enterprise (802.1X) on a network and give out the same user name and password to every user. This reduces the administrative burden of password management to zero, and allows any savvy visitor to get a higher level of protection. WPA/WPA2 Enterprise in the form of the most common method, PEAP, uses SSL/TLS to protect the handshake between station and access point, protecting the unique key assigned from even those with the same 802.1X login information.
Windows and Mac OS X have offered PEAP clients for years. Free clients for versions of Windows without it can be obtained. Linux has clients as well. There's no technical bar to set this up, just one of education. If you can't get users to employ VPNs, or they don't have access to them, 802.1X is a much simpler way to go.
Unless you can get users configuring PEAP correctly and make the EAP peer do proper server certificate validation, this is just another step in making the attack somewhat more difficult.. Man-in-the-middle attack against PEAP without server certificate validation is relatively simple operation and as such, this does not prevent the attack. Furthermore, there are still unfortunately many client devices that do not actually support WPA2-Enterprise.
Anyway, having an option to use WPA2-Enterprise in hotspots that implement traffic isolation between stations would be a nice option to have at least if there is a reasonable server certificate chain that could be validated by peers (and for which it would be non-trivial to get other certificates/private keys that attackers could use to set up man-in-the-middle attack with).
Though, to make all users able to set this up correctly would likely require tools that could figure out which CA certificate to trust based on the network..
Is it right that I only need a handshake in a wpa network and a static key in a wep network? When it is true..how to realize it under windows? Must it be the same wlan card? Or must one card hear for packets from firesheep and another for example in combination with airserv-ng has to make a handshake?