facebook data breach

October 4, 2018

Lessons Learned From the Facebook Data Breach

Like around 90 million other people, I woke up to a notice from Facebook that there had been a security “incident”. There had been a major Facebook data breach. I needed to re-login to Facebook and a dozen other sites.

This was before my first cup of coffee, never a good time for bad news.

Yes, I look at Facebook and Twitter while making my first cup of coffee. Don’t judge me.

This sparked some questions in my mind — and, no doubt, 89,999,999 others. We all asked:

  • What happened?
  • How did it happen?
  • Why did it happen?
  • What can we do about it?

So, what happened?

Facebook, and a lot of other major Internet companies like Google and Github, provide a service generically called single sign-on (SSO). Single sign-on simply means that Facebook is providing a service to third parties that allows those third parties, like mobile applications and other websites, to leverage Facebook’s sign on process rather than providing their own.

Reliably identifying users — what is called the “authentication problem“ — is difficult for anyone, and especially for small companies.

SSO authentication depends on the provider — in this case Facebook — generating a piece of data that is difficult to forge. This chunk of data is called a token. The token then becomes your credential for access to these other third parties in place with your password on Facebook.

SSO has a lot of advantages. For websites and applications it means you don’t have to have your own authentication implementation, and your users don’t need to remember another password. (Passwords have horrible security issues anyway, although that’s a topic for another article.)

SSO is more convenient for the users as well, since instead of needing to have their own password, invent and manage different passwords for each site, and then trust that the individual sites won’t be hacked.

It’s an advantage for Facebook as well, of course. If these third parties are using Facebook SSO for authentication, it encourages users of those apps to get Facebook accounts and provides a great incentive to keep those accounts.

In other words, it’s to everyone’s advantage if Facebook can be a trusted source of authentication for SSO.

As long as Facebook can be trusted.

security data breach
Debbie Hudson – Unsplash

How did this data breach happen?

The short answer is that Facebook had a feature with a security hole that no one had expected and so had never tested.

The longer answer is that we don’t know everything yet. What we know is that it worked like this: Facebook has a feature called “view as” that allows you to temporarily impersonate someone else in order to see how your privacy settings modify what they can see from your account. (Imagine, for example, if you’re worried that your diabetes doctor will see your collection of ice cream and cheesecake recipes.)

The flaw was that when you used “view as“, Facebook took it a little bit too literally, exposing the “authentication token“ of the person you were impersonating. A sophisticated attacker could then get that authentication token, which would allow them to impersonate that person on other sites and with other applications.

A matter of trust

It’s gotten to be old-fashioned to use this term in cybersecurity, but the issues of security come down to issues of trust. That is, your willingness to delegate responsibility for something you care about to someone else.

Third-party applications are delegating their responsibility to be sure they have the right user to Facebook. Facebook users are trusting Facebook to manage their identifying information correctly. And Facebook has every reason not to prove that trust unwarranted.

This time, Facebook blew it.

Why did it happen?

Again, there is a short answer: security is hard. This data breach was the result of several code errors that compounded. That kind of problem is very hard to identify or catch. Approaches to solving the problem have been known for decades but they cost money and make systems harder to use. If you think about it, any security means keeping users from doing things they want to do. Security always makes the system feel less usable.

data security breach
Photo by rawpixel on Unsplash

What can we do to prevent another data breach?

One solution that’s being proposed is to use multi-factor authentication. My bank uses this and to ensure that you are you, they send a code in a text message. Shon Gerber, chief information security officer for a major multinational corporation, points out that these text messages aren’t particularly secure either.

They sell ‘this is your secure solution’ – but it’s just more secure. They are still trusting you to do your part, and you are trusting your bank to do their part. If your account was compromised, it’s still compromised.

The fact is that security really can’t be added on to a project. Security, like other “non-functional” requirements such as performance and usability, doesn’t come from a single component or feature. It must be considered from the beginning. Development teams with experience in secure systems —teams like our team at Flint Hills Group, he said modestly — have the experience and training to factor these into projects from the start.

Security is hard but it can’t be ignored.

Part of the solution is to encourage more research and development in security. Originally cybersecurity research was largely funded by the Department of Defense. There’s still a place for government funding, but cybersecurity is no longer just an issue of protecting classified information. Companies should be investing in security research as well.

The problem is, companies like Facebook don’t have a very strong incentive to pursue better security. Oh, Facebook has been embarrassed by this, and responding has no doubt cost millions — but Facebook has a lot of millions to spend, and anyone who is actually injured by a data breach can have a very tough time recovering any real damages. Most terms of service — you know, those 14 page legal documents to which you have to agree in order to access your cat pictures — disclaim any liability

The more often these things happen, however, the more pressure there will be for the government to act. No company wants that, but unless companies find a better solution, the government will have to act.

Charlie Martin
Consulting Software Engineer

Charlie Martin is a consulting software engineer and writer in Erie, Colorado, with interests in systems architecture, cloud computing, distributed systems in general and innovative applications of blockchains in particular. He is available for consulting through Flint Hills Group.

Charlie-Martin-Flint-Hills-Group-Software-Developer
Charlie-Martin-Flint-Hills-Group-Software-Developer

Charlie Martin
Consulting Software Engineer

Charlie Martin is a consulting software engineer and writer in Erie, Colorado, with interests in systems architecture, cloud computing, distributed systems in general and innovative applications of blockchains in particular. He is available for consulting through Flint Hills Group.