It’s easy to safeguard against this attack: Always use peer-to-peer SSL/TLS to transfer username and password, never transfer this information as clear-text.

Then it makes no difference whether the network is encrypted or not. Better leave it open.

I am pretty sure that WPA uses something like Diffie-Hellman

Then you are pretty wrong.

As for me, I use a VPN to my DD-WRT router at home, so I am perfectly safe from any eavesdroppers.

Crackable in under ten minutes. Ten seconds if you are using one of the weaker VPN methods like CIPE, more if you force me to use fancy crap like GRE poisoning to get around IPSEC.

(a) one should avoid open WiFi hotspots without using a VPN setup that works,

(b) Don’t trust WPA/WPA2 hotspots either, ask for better (802.11x per Glenn) from the proprietor.

(c) Move a MiFi higher on your wish list or take the plunge. Cut the cord.

Do the WiFi routers typically used by the corner coffee shop (not talking Starbucks here) implement 802.11X? iOS, Android, and Win Phone 7 devices? It’s a non-starter for many without that.

I agree that the sites need to do the right thing.

Using a VPN back to a trusted home site only protects you against eavesdroppers on the local network where your computer is. Of course, that’s where you’re most likely to find the casual punter using Firesheep, rather than someone technically skilled.

An eavesdropper who was eavesdropping at any other link between your home router and the site you’re visiting, still wins. The attacks to achieve that are rather more complicated, but still potentially manageable. I’m aware of documented cases of all but the last one happening.

- An attacker who does any one of a number of tricks with DNS, to redirect your connection to a site they control, wins.

- An attacker who tricks one of your ISP’s routers into sending certain traffic his way, wins.

- An attacker who compromises a server in the same hosting facility as the site you’re visiting, and does the sniffing at that side, wins.

- An attacker on your block who sniffs all the cable modem connections on the block (cable modems are like being on a hub with your neighbours) wins.

The only actual solution, as the Firesheep author pointed out, is for the affected sites to keep all authentication data, including auth cookies, inside SSL. Anything else is just a partial workaround addressing one avenue of exposure of the real problem.

WiFi security has gone through three revs that I know of (WEP, WPA and WPA2) and yet they still haven’t gotten it right. What gives?

Firesheep ignores the password that was used to set up the session – it just steals the session.

This post isn’t discussing attacks against deriving that private Pre-Shared Key – which still is limited to dictionary based attacks. It instead presents the limitations of the security model of having many untrusted users sharing a PSK, which is a critical part of protecting the end user.

If a PSK network has a regularly rotated, suitably long and random PSK that is only shared with trusted users via secure means… your attack surface is greatly diminished, because it would rely on an attacker first deriving that PSK. However, as Glenn rightly points out, 802.1X is still a far preferable way to secure any WiFi network, but it requires some technical and administrative overhead.

Drat.

Firesheep’s purpose is to make people aware that Facebook, Twitter, Amazon, Yahoo, et. al. are knowingly leaving their users vulnerable – because they’re too cheap or lazy to provide proper secure (HTTPS) connections for their users.

And it’s sad, because it’s not even that hard. They’re already using HTTPS – but only to protect user logins (and, of course, any transaction that actually makes money.) When Gmail made the switch to all-HTTPS early in 2010 it required no extra hardware, increased CPU usage by only 1%, and increased network traffic by about 2% (details here). But Facebook et. al. failed to design their sites to protect you, their users. You’ve been exposed for years, and they knew it, and because nobody called them on it before now, they haven’t bothered to fix it.

The onus should not be on individual network administrators to protect Facebook’s users. This is not your local coffee shop’s fault.

Using WPA Enterprise has another benefit: it allows devices to auto-connect without having the user manually enter credentials into a standard hotspot portal page before being allowed access. Wireless@SGx is a great example of this. It makes it easy for mobile phones to connect automatically when within range of a hotspot and the user is none-the-wiser. No more custom login scripts for attwifi (for example) getting burned into the iPhone, BB, etc., operating systems. If attwifi offered attwifix, the login would be automatic AND reliable (something the custom login scripts are not).

I would very much like to see the major hotspot operators in the US start following Asia’s lead on this and offer a WPA2 Enterprise SSID at their hotspot locations. T-Mobile did this in the US, but as T-Mobile hotspots have pretty much gone the way of the dodo, this doesn’t help. (T-Mobile also tried to be secretive about the tmobile1x “hidden” Enterprise SSID to get people to install their custom connection manager, rather than simply publishing the details for it.)

What foobar above is talking about is ARP poisoning and is very simple to do

Er, not if you’re talking about his response to me. I was talking about filtering secure packets and routing them through a USB mobile broadband modem while having the other less sensitive packets route through the vulnerable hotspot.

He said that’d be simple to do, but didn’t offer any commands/code to back that up, of course. Because he’s FOS, actually.

First and foremost… the PSK attack you’ve mentioned is only applicable to networks secured with WPA-TKIP. WPA2-AES-PSK isn’t subject to the Beck-Tews attack that aircrack-ng uses to exploit TKIP-PSK weaknesses.

Secondly, the implication that 802.1X – be it PEAP, EAP-TLS, or some other, is ‘simple’ to deploy and manage is absurd, especially in the context of a ‘low tech’ zone such as coffee shop. Sure there are mechanisms built into the APs that make management of users/keys much simpler, but management of it would require a dedicated administrator for the hotspot. Few cafes or other public hotspot locations have the structure to support the overhead such maintenance would require.

Finally, writing a plugin to Firefox that would interact with the WLAN drivers of a machine (as ‘simply’ integrating aircrack-ng would require) is probably not even possible to do with the permissions that Firefox is normally granted. So you’d need to create a blended, multi-tool attack- in which case, attackers are already doing it and there’s no need for the ‘point and shoot’ tool of Firesheep anyways.

What I want to know is this: why is security on WiFi so badly implemented?

It isn’t. This isn’t anything you couldn’t do on a non-switched wired network, and as I pointed out above, you could do it on a switched network just as easily via ARP spoofing.

Hiding your network traffic from others on the local net has never been a design goal. That’s what SSL is for.

If the site you are on is truly sensitive, HTTPS is a must. If you’re just futzing around Facebook, you’re not reading or posting anything world+dog+marketing partners can’t see anyway (at least, you shouldn’t be… this IS Facebook after all!), but someone who pretended to be you could cause some damage.

So, the issue here isn’t encryption. The issue is authentication. The only thing between an attacker and your account is a cookie….

I can’t figure out for the life of me why cookies aren’t signed.

The idea is simple. A site sets a session cookie when you log in. Whoever has that cookie is you, and there’s nothing in the cookie to prove who actually has it. That’s how FireSheep works, it steals those cookies and lets someone else use them.

Now, your username and password are sent over HTTPS when you log in, and if you are successful a cookie is returned to you over HTTPS. If the cookie is given to you securely, why not include a big, unguessable random number with it? That number is a shared secret between you and the site.

Any time your browser sends the cookie in the future, it never sends the secret part of the cookie. Instead it creates a hash from the session ID, the secret, and another semi-random number, such a timestamp. This hash is a signature. It proves you are the one sending the cookie. On the other end, the site should be able to compute the same hash from what you DO send (the session ID and the timestamp) and what it knows (the secret).

Anyone spying on your traffic with FireSheep or the like is not going to know the shared secret, so they won’t be able to sign cookies.

Apple? You love claiming you’re more secure. Make OS X more secure with hotspots, stat. Call it iSecure or whatever… just do this. And while you’re at it, make it so you can increase your bandwidth by combing bandwidth seamlessly. I paid for my mobile broadband, let me use it all, Apple.

Gawd, I can’t wait till I can get 4G everywhere….

Second, 802.1X with the same user name and login is very simple to implement. There’s no user management if it’s one user name, one password, used entirely as a way to create secured key exchange.

Third, this isn’t a limit I know of if you are the owner and have administrative privileges on the Mac, Linux, or Windows machine on which Firefox is running, but I could be wrong.

When you want to send a packet to another machine (lets say 192.168.1.1) on your local network, your Ethernet driver first broadcasts a packet that asks everyone on the network “Who is using 192.168.1.1?” What’s supposed to happen is that the machine using 192.168.1.1 responds “I am, and my Ethernet address is 00:11:22:33:44:55″. However, there’s absolutely nothing preventing anyone else from claiming to be 192.168.1.1. Most operating systems trust whoever answers first. So if you’re just continually shouting “I’m 192.168.1.1″ that will almost always be you.

If you do this with the IP address of the gateway (ie, the router), you get all traffic intended to go out onto the internets. So long as you then pass those packets on to the real gateway, everything will still work as it should.

TL;DR:

There is no way to prevent Firesheep-esque shenanigans on a TCP/IP/Ethernet network. Period. If you want privacy you have to use SSL. Also, assume anything Steve Gibson says is nonsense.