Password Doesn't Shear Firesheep


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.


  1. In theory, using a known key SHOULD work. I am pretty sure that WPA uses something like Diffie-Hellman, which means that an attacker can see EVERYTHING that is communicated between the WAP and the user’s computer, and still now know the keys that they exchanged.

    Now, if an attacker appeared to be an access point, that would be a “man in the middle” attack, and is another story.

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

    1. I’m sure you personally are clear on this point, but I think it bears mentioning in the context of this discussion:

      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.

  2. Open wireless networks are not a security hazard, but badly implemented web sites are.

    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.

    1. You may be making the same mistake that many of the sites that are vulnerable to Firesheep make – these sites (at least some of them) send the password over SSL, but then set an authentication cookie (or equivalent auth token) that they send around without SSL.

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

      1. That would fall in the category of “badly implemented web sites”. of course they should NOT transfer the session cookie in clear text.

  3. 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.

  4. WPA/WPA2 with shared password is better than unsecured. But the real message is that

    (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.

  5. I would say a VPN solution would be the way to go with any public access point, with an extra seasoning of SSL/TLS for the extraparanoid.

    1. Well they CAN, they just choose not to. It’s not like they’ll burst into flame if they put on a cardigan. Also I think most sheep are vegan and almost all of them wear wool.

  6. Helpful info, but I feel like you’ve missed the real problem.

    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.

  7. Several locations in Asia have already adopted WPA(2) Enterprise logins for their public Wi-Fi services. For example, Wireless@SG in Singapore also offers a Wireless@SGx SSID for protected access. Likewise, PCCW offers PCCWx. Even in the Hong Kong airport, the free Wi-Fi provided throughout the airport offers an Enterprise login using a shared username/password.

    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.)

  8. Wow, several technical issues with this post.

    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.

    1. First, everyone has the same shared key. The Beck-Tews and other attacks aren’t really practical, anyway, except for very limited packet injection and perhaps DNS poisoning.

      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.

      1. Point taken, and apologies for my confusion on your attack scenario and suggested remedies.

        However I still doubt a Firefox plugin could interact with the WLAN drivers in the way that injecting a deauth would require. But I don’t know much about developing Firefox plugins/extentions. A quick read thru the documentation doesn’t seem to mention much about getting the deep kernel-level hooks it would require – in the case of graphics, etc, it’s all through a third party API like Flash.

        I would instead expect the hypothetical “Little Bo PEAP”, aka “Firesheep 2” tool to be standalone, and probably only run in linux or OSX – since packet injection in Windows is notoriously picky, and this attack would require decrypting traffic on the fly, two things that are probably a hassle to do within the constraints of a browser plugin.

        That, really, is the main speculative point here – that it’s inevitable that someone will create a ‘point and click’ way to automate the PTK-derivation attack, and then package it with a cookie stealer that reads the decrypted traffic. And this may certainly occur, but probably not in quite such a simple form, due to the hardware-layer interactions required.

        The attack Firesheep performs isn’t new. The entire novelty to it is that it’s cleverly wrapped an existing attack into an easy to use tool, which is great. But talking about the future of it should probably focus more on how best to protect against it, rather than guess about the next way to automate this (or any other) type of attack.

  9. Please keep in mind this is not a security issues associated with wifi. This issue is related to sites sending tokens(cookies) in the clear. The sites are responsible for securing their user sessions. Even if you turn on 802.1x at the access point that traffic has a long way to travel unsecured before arriving at it’s destination. Please stop focusing on wifi networks.

    1. That’s not correct. In this case, it is entirely about sniffers on the local link. There’s a larger issue, yes, about interception outside of a local network, but that’s not what’s being discussed here.

      1. The issue is unsecured tokens being sniffed. If the tokens were secured in the first place, ie only sent over ssl, they could not be sniffed. That is the issue. It is the responsibility of the sites to fix this not your local coffee shop.

  10. Even with WPA Enterprise, you could still perform this sort of attack with ARP spoofing. You have your machine repeatedly broadcast an ARP response claiming that your MAC address is associated with the IP address of the gateway and you can intercept all traffic going out of the local net.

    1. That’s possible–and because it’s possible, it means it could easily happen in an automated fashion. So now we have fARPcracker or something. This would be doable with Hole196, which doesn’t have a great impact in the enterprise (where there are many hurdles to cross and easier exploits exist), but in a coffeeshop, easier. Hole196 lets any party spoof the broadcast key for the network that the access point should be the only device to use (there’s no way currently to secure that) and can be used to spoof ARP.


      1. It’s actually much simpler and more basic than Hole196, and applies to all IP over Ethernet networks, wireless or not.

        When you want to send a packet to another machine (lets say on your local network, your Ethernet driver first broadcasts a packet that asks everyone on the network “Who is using” What’s supposed to happen is that the machine using 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 Most operating systems trust whoever answers first. So if you’re just continually shouting “I’m” 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.


        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.

        1. I’m trying to recall if there’s a mechanism to prevent this sort of broadcast from the LAN to WLAN side of a router–maybe not. If you had network isolation turned on (a feature in some cheap routers), that might not be possible, but then Hole196 would work in those cases.

  11. What I want to know is this: why is security on WiFi so badly implemented? Public key cryptography is nothing new. SSL allows secure communications between two points that have no prior knowledge of each other and it’s over 15 years old.

    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?

    1. Security on WiFi is not so badly implemented. This scenario requires the hotspot model – where everyone would know the passphrase. The way WPA handles authentication is pretty different from public key crypto, so the SSL comparison is not quite apt- but a somewhat accurate analogy here would be if you had shared the SSL private key with every user.

      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.

    2. 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.

  12. If some creative makes a way to filter and funnel authentication packets through your own personal USB mobile broadband 3G device while simultaneously allowing for the other less sensitive packets to funnel through the much faster wifi hotspot. That creative would get my admiration AND money.

    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….

    1. If some creative makes a way to filter and funnel authentication packets through your own personal USB mobile broadband 3G device while simultaneously allowing for the other less sensitive packets to funnel through the much faster wifi hotspot. That creative would get my admiration AND money.

      This would be fairly trivial to do with some additions to your routing table, but there’s a better way to do it that doesn’t require a cellular connection. Just set up a VPN to your home/office connection, and you’re as safe as you would be there.

      1. Just set up a VPN to your home/office connection

        I work on the road and pretty much only on the road (no home office computer running 24/7). Also, what a waste of energy, seriously. Actually what I do instead is use an SSH tunnel with my web server, it’s always running anyway. But it would still be cheaper and easier (and more green) to do it the way I initially suggested, in my opinion.

        This would be fairly trivial to do with some additions to your routing table

        Ok… if it’s that trivial… show me the terminal commands…. lol .. and where’s the app that does this too?

        I mean, yeah, I can get a router to do dual wan… but once again, I already pay for the bandwidth on my usb wireless modem and I want to use it (for better security and speeds).

        If you’ve got some trivial additions to my routing table you’d like to share, please do.

  13. I installed the https anywhere plugin for Firefox. I assumed this would protect all my traffic on FB, Amazon, etc when I’m at a public access point. Seemed like a simple solution to me– what am I missing?

    1. For sites listed in HTTPS Everywhere, you’re fine. (See Tools > Add-ons, select HTTPS Everywhere, click Preferences.) For others, not! Although there are extensions for force SSL/TLS where possible. But some sites simply aren’t set up for this. A VPN is the smartest way to protect the local link.

  14. Gibson’s greatest skill is in self-promotion; take everything he says with a grain of… doubt, though he might be spot-on in this instance. He was loudly and perpetually promoting some kind of security crapware ten or fifteen years ago, which was a laughingstock for those in the know.

  15. I’m a little late on the scene here but I’m going to put in my 2c worth :)

    What foobar above is talking about is ARP poisoning and is very simple to do, whether on a wifi connection or wired. You can do ARP poisoning with a man in the middle SSL attack thereby able to decrypt all SSL traffic (modern browsers show a big warning about this now).

    Even without any fancy ARP poisoning and man in the middle attacks, imagine what you could do using Firesheep and sidejacking someones facebook account or email.

    Say I’m in a hostel, plenty of people around using laptops, I side jack someones facebook. Oh look they’ve posted to someone’s wall that they’re in such-a-such town till Tuesday.

    I now know know their full name plus what date they’re checking out. I go to the desk and tell them I’ve lost me key, they ask full name and checking out date.

    I’m now in their room…

    This is only a small example.

    1. 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.

  16. Most ‘vulnerable’ sites do use HTTPS, but only for your username and password. Once you’re logged in, everything is in the clear. The concern isn’t what a sniffer can see, it’s what they can do as YOU once they hijack your session.

    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.

Comments are closed.