Just when you thought Facebook has put the worst of its troubles behind, the social media giant revealed on Friday that it had experienced a new security incident that possibly affected 90 million users.
However, unlike previous scandals, in which malicious actors used legitimate features of the Facebook app and APIs for their evil ends, this was a hack involving a security flaw that allowed hackers to hijack user accounts.
Facebook is far from being the first company to expose user accounts to unwanted parties. Last year, we saw how credit rating agency Equifax give away the sensitive financial information of 143 million customers to cybercriminals in a massive data breach. And perhaps dwarfing both is the huge 3-billion-account hack of Yahoo.
However, every security incident is also an opportunity to learn from our past mistakes and think about solutions for the future.
While Facebook is at the center of this latest security fiasco, the incident tells us much about the general vulnerabilities of our current user authentication methods, which give unlimited access to users after they sign into their accounts. Unless we find a remedy, similar incidents can happen at other online services we use every day.
How the Facebook vulnerability works
Without getting too much into the details, we will quickly skim over the mechanism that allowed hackers to gain access to user accounts.
Facebook discovered the problem in the “View as” section, a feature that allows you to check your privacy settings by verifying what kind of information and posts other users can see when they visit your profile.
The hack involved three separate flaws, which generated an “access token” and embedded the token into the HTML response that it returns when you use the “view as” feature.
Access tokens are pieces of data that are generated when you sign into an application with your credentials. The token remains valid until you sign out and lets the application server verify your identity.
The problem with Facebook’s flaw was that it generated a token for the user you chose to view your profile as. This means that anyone could use the feature to generate an access token for another user and gain access to their account.
The vulnerability existed for over a year, and Facebook only found out about it after it detected an influx of suspicious activity, likely due to an application using Facebook’s APIs to automate the process of generating access tokens.
The problems with access tokens
The reason security tokens must be exchanged has to do with the way HTTP (and its secure sibling, HTTPS), the protocol that underlies most web services, works.
HTTP was initially designed as a stateless protocol. This means that an HTTP server treats every request independently has no way to remember that any two requests belong to the same user. This was a model that perfectly served the purposes of the first generation of web, which was mostly consisted of static content pages.
Application servers (PHP, ASP.Net…) work around this shortcoming by introducing session tokens, included in all exchanges made between a client and server, to identify which requests belong to which user.
This enables them to provide dynamic content specific to each user instead of serving the same page to everyone. This is why your version of Facebook is different from that of your friends. It’s also why the browser of every Gmail user points to the same address but shows different content.
Access tokens have the single purpose of tracking your session. As long as you’re signed into Facebook, your device sends the token to the application on every interaction to confirm your identity. When you sign out, your server invalidates your session and its associated token.
Without an access token, using Facebook would be impossible, because you would have to enter your credentials for every button or link you clicked on in your application so that it Facebook could confirm your identity and provide your personalized content. Nearly all web applications (think Gmail, Twitter, Instagram…) work in the same manner.
Most services do a good job of protecting session or access tokens by exchanging them through encrypted channels. However, every once in a while, some hacker discovers a flaw that allows them to either steal or reproduce those tokens.
Called “session hijacking,” this kind of attack enables hackers impersonate users of a targeted service and to use their accounts and access their information as if they were the actual user.
(To be clear, the Facebook hack was slightly different; instead of hijacking an active session token, it generated a new valid token for the target user.)
Session hijacking attacks are especially dangerous because they take place post-authentication. This means that if a hacker finds a vulnerability that allows them to steal or spoof session tokens, they can bypass passwords, two-step verification, biometric authentication and any other technology that protects the entrance to the victim’s account.
Single sign-on makes the hack even more critical
For services like Facebook, Google and Twitter, stealing access tokens becomes even more problematic. Several services enable users to log in to their applications with their Facebook account. This is called “single sign-on” and is meant to simplify the user experience.
Single sign-on has several distinct benefits. It spares users of the pain of managing yet another password for their online accounts. It also enables developers to defer the critical task of authenticating users to a company that has a track record of maintaining the security of billions of users.
However, the downside of single sign-on is that when the trusted third party (in this case Facebook) suffers a data breach or a hack, attackers will gain access to all those linked accounts.
Following the disclosure of the Facebook hack, the company admitted that hackers might have also gained access to Instagram accounts, which Facebook also owns, as well as any other service linked to the victims’ Facebook accounts.
This is because when users log into their Facebook accounts, the same token that the service generates will give them access to all those other applications.
What the Facebook hack tells us about the flaws of password-based authentication
Facebook’s recent hack only accentuates the fundamental flaws that our authentication systems have. Despite having talked about the flaws and threats of password authentication for many years, they still remain the main method of identifying users.
Aside from their inherent flaws, passwords are also very impractical, and can take anywhere between 15 t0 45 seconds to enter (unless you choose a very poor password, which opens up another Pandora’s box of security threats).
When you add two-factor authentication (a must if you’re serious about your account’s security), login time becomes even longer.
Developers are always trying to strike a balance between security and convenience, and they usually err on the side of convenience to avoid annoying users.
That’s the entire idea behind the long-term security token. Users hate to enter their password every time they want to access their apps, so developers provide them with security tokens that they can use indefinitely.
Users hate to have separate passwords for different accounts, so developers provide them with single sign-on and security tokens they can use across multiple accounts.
And when that token becomes hacked, the attackers can take over all those accounts, as Facebook’s recent scandal proves. And since we’re tying an increasing amount of sensitive data to these accounts, account takeovers are becoming more and more damaging. It only needs to happen once.
Developers only require an extra authentication whenever the user wants to perform a sensitive operation. For instance, in the case of Facebook, if you want to change your security settings (password, 2FA…) it requires that you re-enter your password.
That’s why the recently discovered Facebook vulnerability didn’t enable the attackers to change victims’ passwords and assume total ownership of their accounts (though Facebook officials did recommend to change your password for good measure).
Why we need new authentication mechanisms
No matter how secure your security token is, as your software becomes more and more complex, there’s a likely chance that hackers will find some hidden flaw to steal it. The only way we can fix the problem is to have seamless and frictionless authentication mechanisms that would verify the identity of the user more frequently.
An ideal scenario would be to verify the user’s identity in every interaction that takes place between a client and server. Such a mechanism would obviate the need for long-life security tokens and would make session hijacking attacks impossible.
But that is not practical with current authentication technologies. Obviously, with passwords being the main authentication method of online services, asking for too much login entries would not only be bothersome, it would also be insecure, because it would involve sending passwords over the network again and again.
Passwordless authentication would be a move in the right direction. Ditching passwords and replacing them with biometric authentication or security keys would make the identity verification process much more user-friendly.
It would also remove the need to store and exchange secrets. Users will be able to confirm their identity through zero-knowledge proof mechanisms, which would make the exchange more secure.
Current passwordless authentication mechanisms are still not frictionless enough to transition to the authentication-per-request model, but they would allow developers to ask users for identity verification more often.
For instance, every time the user wants to go open a new section of the application (messages, settings, profile page, news feed…), the application would ask them to verify their identity without causing too much trouble.
More advanced biometric authentication technologies, such as Apple’s Face ID, might even provide transparent authentication, though they can have their own security and privacy considerations.
A solution would be to have some sort of NFC-enabled security key that would be unlocked with a fingerprint scan, would pair with the user’s device and transparently generate cryptographic hashes of each request the application sends to the server without requiring any intervention on the part of the user.
This would be a seamless, frictionless multifactor authentication (two linked devices and biometric verification).
This is really just a wild thought and might not be practical or cost efficient. But what’s for sure is that we need to move away from the “authenticate once and use indefinitely model,” and this requires new technologies and a healthy dose of thinking outside the box.
