Tag: Firesheep

Encrypting WiFi with Known Passwords Still Misses the Point of Firesheep

Posted on1 Comment

Slashdot links to the proposal advanced by one security researcher to have safer wireless without necessarily denying access. The reasoning of Chester Wisniewski who works for security firm Sophos isn’t wrong. Firesheep is able to hijack sessions with popular web sites because the communication after login is done entirely in the clear. Using WPA or WPA2 should encrypt that traffic with a distinct key, even for users on the same hot spot. While WPA isn’t one hundred percent secure, it raises the cost of hijacking beyond the point-and-click ease of Firesheep.

Increasing the security of hot spots is a laudable goal in and of itself. Unfortunately, like the variety of mitigation tools that have cropped up, it is distracting from the main point Firesheep’s author, Eric Butler, was trying to make. The simplest, best solution is for web sites to ensure that session identifiers, usually encoded as browser cookies, are not easily snarfed by an attacker. Just turning on SSL encryption and making sure web applications behave well with it would be enough. All reputable online banks already do so. It is unclear why other services are so reluctant to do so, despite many of the costs and limitations of SSL being erased by beefier computers and devices coupled with faster connections.

Glenn Fleishman at BoingBoing has some further excellent analysis of Wisniewski’s proposal. Steve Gibson, a high profile security writer and developer, made the same suggestion but had enough time to contemplate possible flaws.

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.

Fleishman goes on to explain how it may be possible to tweak a hotspot and clients far enough to overcome most of the further cracks, but ultimately ends with the same conclusion. Access points and end users aren’t in the best position to deal with a security problem known and largely ignored by web service developers and operators.

Sophos Researcher Suggests Password ‘Free’ to Spur Wi-Fi Encryption, Slashdot

Mozilla Won’t Block Firesheep Add On

Posted onLeave a comment

The session hijack tool, Firesheep, is rightly drawing a lot of attention. I saw this ComputerWorld article, via Hacker News, that explains remarks from Mike Beltzner, the Firefox project director. Basically, Mozilla will not use its black list mechanism to block the dangerous add on. The reasoning is that it doesn’t directly exploit any security problems within the browser itself. Further the add on is not an approved one listed in Mozilla’s central registry, rather it is being directly distributed by Eric Butler, its author. Mozilla’s black list may not be effective against it as it doesn’t rely on their distribution channel.

Blocking Firesheep won’t help the issues that Butler intended it to raise. In the post about Firesheep on Mozilla’s security blog, Sid Stamm points out that Firesheep is an add on, versus a standalone software tool, is largely irrelevant. The problem has been well hashed over in a number of posts to which I’ve linked. To recap quickly while initial login requests are usually encrypted, subsequent interactions with sites like Facebook, Twitter and others are not encrypted but expose session cookies in the clear. Those cookies are what Firesheep is able to capture and use to hijack users’ sessions despite their actual login being totally secure.

EFF has another excellent write up of the lesson of Firesheep: web sites that rely on persistent identification of their users need to do more than just protect the initial login. They recommend, as I did early, use of the HTTPS Everywhere add on for Firefox. The Mozilla Security Blog post, linked above, has a few other options if you are brave enough to use the Firefox 4 beta like me.

The biggest problem I have run into with forcing SSL where I can is that many sites clearly are not tested with encryption always on. Thankfully, none of the sites I found to be broken, like Facebook, are all that important. Hopefully part of the attention Firesheep draws and the subsequent increase in users forcing SSL will pressure sites that break to provide fixes or better yet default to SSL while their users are logged in.

Mozilla: No ‘kill switch’ for Firesheep add-on, ComputerWorld

feeds | grep links > Towards a Graphene Transistor, Over Broad Child Protection Law Blocked, B&N Caught Deleting Customer’s EBooks, and More

Posted onLeave a comment

Apologies for the second day of just links. I was in a rush to get to the local CopyNight here in DC last night. I took a sick day from work today to try to final get over this cold and have been trying to keep blogging to a minimum, too, in order to maximize my rest.

Thankfully, tonight’s podcast is an interview I recorded last week so will got out with minimum effort as scheduled.