I wrote a short post about this:
http://restafari.blogspot.com/2010/11/cookies-are-gross.html
Thats only when a service checks just for a valid cookie. One can make it secure for users by also considering the IP address while generating the cookie.
e.g: An MD5 of the userid-IPaddress-SecretKey
build a better online identity solution than creaky old HTTP cookies.
We did. 5o9 Inc.
Cheers,
Peter
Just for fun, I turned on a unencrypted router at work (router was not connected to any network). Within minutes I had almost 100 connections. What this suggests to me is that the majority of people have no idea what WEP, WAP, HTTPS or TKIP is. Could this possibly why identity theft continues to rise. To me, education is the only solution. The problem is that only the people who know about Firesheep know about the dangers of unencrypted data.
Github team also commented on this issue, and how they started dealing with it by setting secure flag and https for critical actions: https://github.com/blog/737-sidejack-prevention
Considering that only you and the service provider (i.e. your bank) benefit from security, and that local hardware (WiFi router) is far more vulnerable to attacks than your/bank’s hardware, HTTPS is the best option by far.
I think all web traffic should be encrypted, though we’d need to work on how browsers cache it etc. HTTPS is cheap enough to be used everywhere – it shouldn’t increase your CPU load by more than 1-2%.
I think that a great way to make people use encryption more would be to issue free SSL certificates with every new domain name sold.
- SSL certs can be had for less than $10 these days. Cost is not an issue.
- Hardware impact is negligible.
- Browsers DO cache CSS and other resources, if the correct headers are sent. By default they are not written to disk.
That’s non-sequitur.
Better on-line identity will not solve problem of unencrypted traffic. Any identity solution will be vulnerable unless:
- Browser expects to get secure protocol and will refuse to fall back to an older one. Without this you can do MITM swapping new, secure protocol for old leaky one (e.g. replace Digest authentication with Basic auth).
- Browser can verify identity of server using other/trusted communication channel (SSL does that by storing CA certificates offline). Without this you'll be securely sending your identity to an attacker spoofing a server.
- All traffic has to be encrypted and tamper-proof. If you only protect identity, then attacker performing MITM can perform replay attack, change request parameters, steal data, etc. — you're still exposed to lot of risks.
It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?
To all the comments that says that checking for the IP secure anything :
Firesheep is used with the attacker on the SAME network as the victim, and except if you use a full IPv6 setup to communicate to an IPv6 server they will have the same IP seen from outside the LAN.
"build a better online identity solution than creaky old HTTP cookies. "
Yeah we already have that. It’s called HTTPS cookies, supported by all browsers, secure and has negligible costs to implement.
HTTPS is our only practical solution. Even if this Unobtainable solution were to be invented today, have zero per user cost to implement, somehow magically be simpler than SSL, be universally accepted, we would still have to wait months if not years for it to supported well enough in every browser and web server.
We have the solution, we know it works, we know how to use it, all we have to do is use it.
“Lobby the websites you use to offer HTTPS browsing.”
Jeff, have you ever tried:
https://stackoverflow.com/
?
It greets me with “The site’s security certificate is not trusted!” and then further with Access Denied.
Isn’t it ironic?
HTTPS is not “overkill”. In fact, given the somewhat broken certificate authority model that browsers impose, it’s a bit underkill.
First of all, it’s not too slow. See the links here - http://twitter.com/glyph/status/2958424706916352 - so there’s no real reason to consider it ‘overkill’ if it’s not taking up an unreasonable amount of resources.
Second of all, any “better” identity solution must necessarily involve crypto. So, why go to the massive amount of trouble to create a new cryptographic standard when the existing one is adequate? Keep in mind that if the stuff other than your “identity” isn’t protected, your identity isn’t really protected either. Active attacks aren’t significantly harder than passive attacks on unencrypted traffic; if your authentication is encrypted but the commands you’re performing aren’t, an attacker could just as trivially capture your outgoing commands and modify them rather than modify your authentication.
Or, alternately, if you are concerned about people being able to masquerade as you, and you’re using authenticated, encrypted connections, but the people reading your activity aren’t, then the attackers can just spoof them instead of you.
So, turn on https on stackoverflow, please, and stop advocating for some mythical broken solution when a very real, working one already exists. The biggest problem here is that everyone thinks they understand the problem but very few people really do. So, while “Use HTTPS” is an oversimplification, it’s the only message that is going to get through: if you say “Use HTTPS because there’s nothing better but we should really come up with some better thing” then lots of people are going to take away “Oh, I should wait until there’s a better thing, until then I’ll just use HTTP and ignore the problem”.
Several people have proposed combining and IP check with the cookie check. That doesn’t work, however - many of these open WiFi routers are NATed, so the FireSheep connection will appear to come from the same IP that was issued the cookie. In fact, short of HTTPS or other similar encryption protocols, there is no solution. The required solution must be immune to forgery or to replay attacks; a give set of credentials must be unusable by anyone other than the sender and replaying a set of stolen credentials must not work. Given the stateless nature of HTTP, this is incredibly difficult to enforce, as the protocol doesn’t provide a means to negotiate the necessary changes in magic numbers.
A solution could be approached using cryptographic signatures over some data including a timestamp and a nonce, but the current browsing technology doesn’t make that a viable solution unless everything is done in JavaScript (thereby further breaking the Web).
Hi Jeff,
Great post, thanks for clearly thinking this through and you no doubt understand most of the problem and what’s happening to make it all possible.
Regarding your stance that Stack Overflow should not be SSL to protect the auth cookie, if there were some mechanism to somehow lock a browsing user to their session such that it couldn’t be stolen/replayed/whatever by a passive attacker, what about active attacks? What about Man in the Middle attacks, where someone injects JS in to your page and performs actions as you by those means? This could happen on the local network, at your ISP, or by your government depending on what your personal threat model is. For protection against that, you need integrity and authentication, two things that SSL does very well. Add in privacy with symmetric crypto essentially for free (really, because you’d already be doing public-key operations to get authentication, and SSL/TLS session resumption make this quite fast after those operations are finished initially) - why not go with SSL for this?
Obviously I’m using Stack Overflow as an example here, not to poke and troll at you - I trust you can think about this idea as it applies to many other sites.
Do you have any thoughts on Google’s SPDY (http://dev.chromium.org/spdy)? It stands to fix a lot of the problems with HTTP and streamline things. The security model there appears to just default to having everything be in an SSL channel, vs an option.
Thanks!
Ian Gallagher
Firesheep co-dev/co-presenter
“If you have no other choices except unencrypted wireless networks, browse anonymously”
I think you need to be a little clearer about this statement. In the age of Facebook “Like” buttons on every damn page, if you browse with your regular browser that has the Facebook login saved, then you’re sending Facebook cookies even as you browse other sites that are nothing to do with Facebook. To really browse anonymously you need to use an alternate browser with no saved credentials. Something like Opera is good because you can completely clear your saved data at the end of each session. (And even then, Flash cookies persist…)
I hardly think that all-encrypted traffic is ‘boiling the seas’. As others write - it should be the bare minimum.
The second you tell everyday people that almost everything they read, write, click, view, etc are completely readable by anyone in the middle (governments included) they are noticeably, and understandably, upset.
Like most people, I don’t have anything to hide, but that doesn’t mean we don’t value our privacy.
Maybe it doesn’t matter to you if people know what products you like on Amazon, or how often you visit thinkgeek, or if you have a predilection for anime. Maybe you descend from the Dutch and never draw the blinds on your house. Good for you, but most people expect a modest amount of privacy and do not want someone else linking all their habits together (if they’re lucky, it’s just to sell them something).
Otherwise things become far too Orwellian for my liking. There’s no need for 2-way tv’s in them if you can glean all you need from someone’s online life simply by capturing some of their traffic, or watching the websites they frequest.
SSL is cheap, and for a modestly-size site, SSL offloading firewalls are easy for an experienced sys admin.
So, where do I go to lobby Stack Overflow and the other Stack Exchange sites to switch to https? While I’m only an infrequent user of the site, I can imagine other user’s could be quite irked by the reputation hit that could be caused by someone hijacking their cookies - especially if they’re using that reputation as part of their credentials/CV.
SessionLock and SessionLock Lite (to a lesser extent) present a partial SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/
I assume then you never tried dsniff, which included a program (webspy) that did something very similar and has been around for a decade. It provided tools to sniff out sensitive data on a wired network.
As for a greater use of SSL for sensitive bits, if you want to make the web safer then push for better SNI (Server Name Indication) in servers and clients.