Secure websites are insecure – ask Firesheep


An independent software developer in the USA has started his own campaign to push website operators towards encryption everywhere – or, at least, whenever it matters, which turns out to be a lot of the time.

Well-meaning websites use secure http, or https, at least during the login stage. This is vital, since it protects the username and password you submit. Once you have logged in, the site sets a browser session cookie which is unique to your login session.

Using a cryptographic hash tied both to your account details and to a random server-generated session key means that no-one can predict the value of this cookie in advance.

The cookie therefore very conveniently acts as a temporary access ticket to your account, so you don’t need to resubmit your login information on every page. Cookies are needed for this purpose because http is, by design, a stateless protocol. Each request from client to server is considered to be independent of all other requests, so some sort of repeatable authentication token is needed to denote that a series of requests belongs to an individual session.

So far, so good.

But many websites take the easy way out once your session cookie is set, reverting to regular, unencrypted http for the rest of your session. After all, your username and password are not needed again, so the need for encryption has passed. Right?

Wrong.

Reverting to insecure traffic brings its own intractable security problem. It exposes all of the rest of your session to interception, including the session cookie, which is transmitted in the headers of every http request to the site.

Slightly oversimplified, therefore, attackers who can sniff network packets from your PC can extract your website session cookie from the intercepted data, duplicate that cookie in their own browsers, and connect to that website as if they were you. And this sort of interception is easy – trivial, in fact – when you are connecting over an unsecured Wifi network. These are common in areas where WiFi access is provided for free.

Firesheep

Eric Butler’s Firesheep plugin for the Firefox browser implements exactly this attack to allow automated live hijacking of Facebook and Twitter logins, amongst others. This sort of attack is colloquially called sidejacking, for rather obvious reasons.

You can debate the morality of Butler’s open publication and promotion of his session-hijacking software all you like, but he makes a clear and important point. (Just don’t access anyone else’s account with his software, even for fun.)

Many websites, notably those which allow you to access and use any sort of personalised information, or to perform online activities for which you might be held accountable, are shortchanging you by using https only at the start of your session. They should use secure http throughout, protecting both the personal data you choose to upload and download, and the authentication token they use to identify you.

There are some reasonable exceptions to full-time https – for example if a site uses a login merely to limit access to its own unpersonalised intellectual property, such as software downloads or news articles. In general, however, an SSL login should be followed by an SSL session.

The traditional excuse for not using encryption everywhere is that SSL, the cryptographic layer of https, is “expensive”. There are two brisk reponses to that.

Firstly, so what? It’s cheaper to avoid any form of security for your customers. But no-one would accept that. So why should they accept half-baked security, either?

Secondly, says who? Google claims it has enabled https for all aspects of its Gmail service without adding any extra processing power.

This sort of boast from Google can be taken with a small pinch of salt – after all, Google is adding processing power and organisational smarts to its network to improve everything all the time – but it backs up the claim by explaining what it did.

If you’re a social networking site, perhaps you should do the same?