Case of the Mondays Rant?

By Jake • November 1st, 2010 • 9 Comments

The recent flap over Firesheep (intentionally unlinked) and its ability to intercept unencrypted cookies has renewed several issues worth discussing.

Proof-of-concept hacking
I’m highly uncomfortable with the tacit used by Firesheep’s creator, i.e. releasing malicious code under the pretenses of creating public awareness.

Yeah, I understand that Twitter, Facebook, and all the others would have given him the runaround about this, had they responded at all. After all, the decision to pass unencrypted cookies is an obvious risk taken for a speedier experience. Everyone knows speed is the killer feature.

And sure, I get that real baddies with matching intentions are using this already.

Still, in most cases, all this really does is bounce around Twitter, Digg, Hacker News, Slashdot and the usual outlets, never really accomplishing the said goal of educating the real public at large.  The social media expert crowd picks it up, with good intentions, but without any real impact. Maybe a couple news outlets pick it up, but with understandably mixed results due to its technical nature.

Most people just aren’t cautious with their online lives. Not because they don’t care, but because it’s too easy to fail.

Update: Confirmed, some people just don’t care, h/t Slashdot.

I don’t really have an alternative, but maybe someone should run with the idea of creating PSAs for this type of technical subject.

Free wi-fi
The side-jacking technique used by Firesheep is not in any way limited to free wi-fi networks, but from all the coverage, you’d think it was. See my previous point about coverage.

There is no good reason anyone should be using free wi-fi, password-protected or otherwise, without VPN. Not one. It’s not worth the risk.

If you carry a smartphone, you should be tethering to it and using WPA encryption on the phone’s wi-fi network. Use WPA, not WEP, which can be cracked in seconds, and set your network to hide the SSID. Yeah, I know these aren’t hack-proof, but they are challenging enough to deter most people who don’t have a grudge against you specifically.

No exceptions to that rule. Pony up the extra dough to your carrier, or root/jailbreak your phone.

But what if you can’t get a dependable 3G signal, need to work and don’t have VPN? Your employer will thank you for not using an exposed network.

There are no Facebook or Twitter emergencies, don’t ask.

Security and the internet
First, refer to this helpful digram about your privacy and the interwebs, then never share anything online that you think is private.

No, email isn’t truly private, which is why you shouldn’t send credentials or important information through email. If you’re super paranoid, encrypt your email or using a signing authority.

Anyway, bit of a rant. What do you think? Find the comments.


Possibly Related Posts

  • http://www.esjewett.com/ esjewett

    Interesting post.

    While I am usually very supportive of advocates for a notify-first-release-later approach to security vulnerabilities, in this case I’m actually supportive of the Firesheep creator’s tactics. This particular cookie vulnerability is so well known and so widespread that anyone who really wanted to exploit this vulnerability already had extensive tools at their disposal allowing them to do so.

    The only thing that notifying companies of existing vulnerabilities does is make them aware of the issue and give them time to fix it. In this case, these websites were already well aware of the issue and have done nothing to fix it. (The notable exception is GMail, which turned on SSL by default in January.) Releasing Firesheep had one primary affect: It created a massive publicity storm that *finally* made consumers aware of how easy it was to steal their data if they weren’t using SSL/TLS.

    This publicity storm has in turn resulted in companies finally evaluating the security of their un-protected cookie-based infrastructures. I don’t see how that would have happened any other way. Smart people have been yelling about this for years to no avail. If Firesheep had been created 2 years ago, we would be two years closer to this not being a problem.

  • http://theappslab.com Jake

    I assume you mean “While I am usually very supportive of advocates for a notify-first-release-later approach to security vulnerabilities, in this case I’m actually *not* supportive of the Firesheep creator’s tactics.”

    I have to disagree with the primary effect though. Firesheep has raised awareness among the prankster and semi-technical evil-doer crowd. As you say, side-jacking a cookie has been an known issue for at least a decade.

    So, anyone in-the-know has been doing it or avoiding it for a long time. Firesheep alerted a segment, but mostly just people who want to spy on others.

    The public at-large remains blissfully ignorant and/or they just don’t care or understand. The onus stays with the service providers, who might be more embarrassed now (a good thing), to do the right thing for their users.

    I won’t hold my breath. So, in the meantime, I’ll stay on my own network.

  • http://www.esjewett.com/ esjewett

    No, I meant what I wrote. I’m supportive of the Firesheep creator’s tactics. As you say, service providers have known about this issue for a decade (longer actually) and done nothing.

    Heck, you should have seen the discussions going on among the creators of WRAP and OAuth 2 less than a year ago! Many of these people are key employees of these very service providers, and many were arguing for recreating cookies and allowing transmission over insecure channels because the current cookie implementations were ‘secure enough’. They argued that recommending short-lived tokens (which cookies were supposed to be, but their lives predictably enough got longer and longer) would provide adequate security. Of course, short-lived tokens do almost nothing against this type of exploit.

    Many service providers are now doing something, which is more than we could say 1 year ago for most everyone but Google and financial institutions. Github is blogging about it, which is edifying.

    Just so that you can sleep a little less soundly at night, keep in mind that being on a private network yourself does little against these types of attacks. Sure, no one can sniff the cookie on coffee-shop wifi, but your request gets routed through a large number of servers before it reaches it’s destination, any of which can grab your cookie. This is true even if you are using a VPN, unless your VPN endpoint happens to be in the service provider’s data center.

    The only end-to-end protection is SSL/TLS.

  • http://theappslab.com Jake

    I got confused when you said “while” and didn’t provide a negative. You kinda said while I’m usually supportive, in this case I’m supportive :) IMO providing Firesheep is a total dick move that only serves to a) give that guy publicity and b) give a hammer to a looter to remind him that the windows are glass.In the end, the right thing to do has nothing to do with corporate goals, so we’re all at the whim of these services. This anthem will play over and over throughout the next decade.I understand that a private network does not guarantee security. However, WPA makes it a hard target vs. the other easy ones nearby. And yes, I’m aware that all the hops are similarly vulnerable, but again, these are hard targets.Security is more about making yourself a difficult mark (and not pissing off someone w ninja skills) that it is about absolute protection, which is a unicorn.

  • http://theappslab.com Jake

    Changing my analogy to giving a looter bolt cutters bc the people who used padlocks knew they could be cut.

  • http://www.esjewett.com/ esjewett

    No problem, confusion is fine. I’ll admit my sentence was just a tad over-complicated :-)

    I think the difference is that pretty much everybody knows how secure a padlock is (not very). Similarly most everyone has a feeling for more or less how secure SSL is (pretty secure). But most service providers have pretty much misled their users about how secure access without SSL is, and there is a lot of confusion out there among even very technical users.

    I know, for example, that it didn’t occur to me that a site using partly SSL/TLS and partly non-encrypted communication would be totally vulnerable to cookie snooping because they usually use the same cookies for secure and insecure access. I know now because Github blogged about it. Firesheep was the reason for that discussion, and Firesheep has made it painfully clear to a lot of people exactly what is protected and what is not.

    Yeah, it’s a dick move, but people have been trying to make the point without being dicks for a decade, and it’s been a failure. It’s refreshing to see someone make the point to users and service providers successfully.

  • http://theappslab.com Jake

    Referring back to the OAuth discussion, there must be a way to do this in an open standard way, side-stepping the issues of SSL (cost, speed). I can see a rolling adoption curve for it like OAuth has generated. Failing that, it’s not going away any time soon.

    Raising awareness is a good thing. I’m down for that. I hate the way it was done though.

  • http://www.esjewett.com/ esjewett

    OAuth-signed requests (from OAuth 1.0a) can potentially replace the cookie use-case without sending normal requests over SSL (with the signing secret sent over SSL). Twitter does this for its API, for example, but browsers don’t generally implement support for OAuth, so it’s not possible to replace cookies for browsing in this way.

  • http://theappslab.com Jake

    Sounds like something Google might push with Chrome, especially given how fast they’re iterating. Fingers crossed.