Wasn't that encrypted?

Consumers are advised to "look for the padlock when browsing and your identity will be safe". As security professionals, we all know it's a bit more complex than that, but the principle is sound, isn't it?

Sessions are used by web applications to identify authenticated users. The session is passed with your HTTP request to ensure that only you have access to your account. Make the session value long and random, pass it only over encrypted HTTPS, and you have a secure application. Or at least, that has always been the assumption.

Facebook is an example of how its possible to get it wrong: Logging into the site, you are required to authenticate over HTTPS, but once you've passed the login stage, the communication drops to HTTP for performance reasons. Given that Facebook is often accessed over open networks such as wireless hotspots, it's not difficult to sniff the session and hop into someone else's account.

Worse, Facebook doesn't appear to expire your session after a period of inactivity - until you log out or close the browser, the session remains the same, allowing the attacker extensive access to your account. They may even gain enough data - such as date of birth, place of residence, spouse and work details - to steal your identity.

Facebook is just one example; virtually all social networking sites work in this way. Similarly, iGoogle sessions are also unencrypted, allowing the hacker to view your browser session. Hence, a session is almost as useful as your credentials.

It's not just wireless hotspots where sessions can be sniffed. Any shared network will do for a sniffing attack; typical scenarios might include users of a shared ADSL connection in a shared house, wired internet access in hotels, any hub (rather than switched) network or even a corporate LAN using an ARP spoofing attack.

Facebook and Google are by no means unique. Instant Messenger and many other chat clients have similar problems: authentication is usually encrypted, but the actual conversation goes in the clear.

Granted, you can see why this practice is implemented among these fast growing brands, as HTTPS has a high processor overhead, so can be costly to implement. But it does seem a little rich that these massively valued sites do not invest in additional equipment, SSL accelerators and the like, particularly in the current climate of identity fraud concern.

Fortunately, we haven't yet found an online banking site that drops back to HTTP after authentication.

Another very common problem occurs when a session is issued once the user arrives at the site, almost always over HTTP. The user then authenticates over HTTPS, but the session ID stays the same. We already know what the session ID is, having sniffed it over HTTP. So what if it's now encrypted?

This is bad practice and can easily be avoided by ensuring all sessions are destroyed and reissued when authenticating. Or you could choose to link the session to the source IP address, making it that much more difficult to exploit the session. Sadly some ISPs, such as AOL, have an irritating habit of dynamically cycling the client's IP address, making it impossible to implement this easier solution.

In the meantime, there are some simple steps you can take to protect yourself when online. Don't leave your Facebook account signed in for long periods and log out when you're not using it. The session is destroyed upon logout, preventing the thief from using the stolen session to access your account.

With regards to IM, freeware encryption tools are now readily available for chat clients that can prevent eavesdroppers tapping into your conversation. But until web developers encrypt their sessions more completely, and organisations wake up to the need and cost of encrypting the whole communcation, we should all assume our sessions are not secure.

Ken Munro is managing director of SecureTest. He can be contacted at ken.munro@securetest.com