Towards Secure Facebook Usage (Part 1)

I found out recently that Facebook had a flaw (or, perhaps I should call it a malfeature):  although login takes place over HTTPS, which is encrypted, subsequent pages are then accessed over plain old unencrypted HTTP (with the exception of pages handling some very sensitive information, such as credit card details) . There is no setting in Facebook itself that allows you to force HTTPS to be used for all transactions.

What does this mean? I’m no security guru, but as I understand it, it means, at the very least, the following:

  • Information sent back and forth between you and the Facebook servers via HTTP is open to attack from anyone who can intercept this communication. (On an unsecured wireless internet connection, I’ve heard this isn’t that hard. Until I test this for myself, I can’t say HOW hard). So your news feed, chat messages, etc. are all out in the clear.
  • Facebook is open to Session Hijacking attacks. More on this below.

I feel this is wrong. Why? Although I would consider the traffic between me and Facebook to be of a trivial nature, it’s more of a principle: I should decide what is trivial enough to be sent unencrypted. Moreover, Google Mail (for example) offers the option of always using HTTPS (not just for login). The interface I use to compose articles for this blog seems to do it by default – I haven’t yet run across a setting that allows me to turn it off.

Back the Session Hijacking attack. I can’t possibly hope to describe all the facets adequately here, partially because I don’t know them all. But there are hordes of information about this on the net. Basically, after login, Facebook identifies you using a “Session ID”, which must be sent to the server every time you request a page. If an attacker intercepts this (which is in theory essentially the same as intercepting any of the information mentioned in the point above), then they gain access to everything you could access with this Session ID. There is a limit to what an attacker can do, since this Session ID doesn’t contain your password. In addition, there are sophisticated ways of hampering such attacks. But still, as I understand it, these techniques don’t come close to the security of HTTPS.

So that’s the problem. At the moment I am looking into user-side solutions – the following part of this article should discuss that in more detail. Of course, ideally Facebook would implement this as an option you could select under your account settings, but there are good reasons why Facebook wouldn’t want to do that. More on that next time.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s