![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Short version: Facebook sucks, Twitter kind of sucks, and if you use Firefox, install this add-on now.
Long version:
A Firefox extension called Firesheep made the news recently in a pretty big way. In a nutshell, it’s a Firefox addon that allows just about anyone to walk into, say, a coffee shop with an open wireless network and capture the cookies¹ authenticating everyone in there with Facebook. Or Twitter. Or…well, any of a great number of sites where you probably don’t want just about anyone to read everything you or your friends have posted, or pose as you.
Of course, Firesheep didn’t create this problem. What it did—and what it was designed to do—was to highlight the problem by creating a tool so easy to use that anyone could do it. Malicious hackers who actually want to steal your credentials and do evil things with your accounts could already do it. The Firesheep people wanted to give the problem more press, and they succeeded. It’s as if all car alarms had an easy way to disable them that the car thieves already knew; Firesheep gave it publicity by selling a simple toolkit to average consumers. (It’s also not, strictly speaking, limited to wireless networks, but open wireless networks are a huge opportunity.)
I won’t go into the technical details in great depth at this point. Suffice to say that you can connect to many servers, including all these big social network, in a secure way. The problem is that it’s not the default. Use a secure SSL connection (you’ll recognise it by the https:// in the URI) and this particular problem goes away.
If you happen to use Firefox, there are actually plugins that you can install that force the browser to use the secure versions of various websites. You can look up ForceTLS on your own time if you are so inclined. I will personally go with HTTPS Everywhere, published by the EFF. Simply install it, and Firefox will connect to Facebook, Twitter, &c. in a way that cannot be eavesdropped upon.
Of course, it has limitations; see the FAQ. Ironically, LiveJournal is an example of a site that doesn’t actually work because it doesn’t really have a secure version.
The real, long-term solution is obvious to anyone who understands the problem and knows anything about authoring websites: No credentials should ever be transmitted over unencrypted channels (except such credentials as are specifically intended for it, like the Diffie-Hellman handshake and what not). If you ever write a webapp with authentication, only allow authentication over SSL, and only send the cookie over SSL. If you’re worried that it’ll be too bandwidth or CPU intensive, by all means serve static content—anything that you explicitly, whitelist-wise know to not matter in terms of security—over plain HTTP, just on a different subdomain or domain or what have you than the one on which you serve the cookies. (There are other reasons, anyway; my own website already serves static content from a separate subdomain because caching rules are very different, and static content can be served up by Lighttpd rather than an Apache instance that runs everything through mod_wsgi and Django.)
Unfortunately, this is not a solution that the client can effect: It’s up to website and service authors. As a user, the best you can do is stick to SSL whenever possible.
¹ The cookies, not the credentials. Even a site with unsecure cookies may transmit passwords securely. Conversely, even if you login through a secure https:// login page, the cookies may be served up for anyone to sniff and steal.
