If you woke up yesterday morning on September 28th, 2018 to find yourself mysteriously logged out of your Facebook account, you are not alone. You are one of the approximately 90 million people who were logged out of their accounts by Facebook in response to a security breach that led to possible compromises of access tokens of a large number of accounts.
An access token is basically a long random string that is generated by a server and sent your browser or app when you login. Your browser or app will then save this access token on your computer or phone and every further request sent to the server will have the access token attached to authenticate the request without you having to enter your password each time. It is effectively what keeps the browser logged into the service for you.
Here's an analogy to help understand this. Assume you're going to a venue for a concert and you have a ticket for the event. The bouncer at the venue will check your ticket along with a piece of ID when you first enter to make sure you are old enough to enter and that you have a valid ticket. However, you might want to leave the venue and re-enter later and the act of checking the ticket and ID is time consuming both for you and the bouncer. To avoid having to repeatedly do it the bouncer, after checking your ticket and identification, issues you a wrist band. After that each time you re-enter you simply show the wrist band instead of your ticket and ID. If somebody else were to steal your wrist band and wear it, they could impersonate you and enter the venue. For this reason, the wrist band is likely to be designed in a way that will make it very difficult to take off your wrist and put on somebody else's.
In this analogy your ticket and identification are your authentication factors used to "log in", and the wrist band is your "access token". This means "logging in" is the simple act of having your authentication factors verified and in return receiving an access token that can used for authentication for a certain length of time after logging in. The "session" is defined as the length of time during which the access token is valid.
In some ways, access token leaks are worse than password leaks. While a password leak will leave accounts with multi-factor authentication (MFA) mostly secure, an access token leak will often not be protected by MFA as requests with valid access tokens attached are often not challenged to provide an additional authentication factor.
Additionally, new logins using a password are often seen as more significant security events compared to a simple request with an access token which happen far more frequently than logins. As a result of this, new logins often result in alerts (by email, SMS, etc.) sent to users informing them of a new login, and allowing them to take action if the new login was not by them.
With access token leaks (basically the same thing as session hijacking attacks), your only hope is that the security mechanisms implemented by the server, in this case Facebook, will notice irregular access patterns (say a sudden change in geographical location based on IP, or user agent change) and challenge the requests by requiring a password or other authentication factor. If that doesn't happen, the attacker can effectively impersonate you and do everything you can do that does not explicitly require additional authentication factors. This is partly why actions like changing a password should always require an authentication factor that is not an access token.
Why End-To-End Encryption Matters
What is the most disturbing part of this security breach? For me at least, it is the fact that someone with your Facebook access token can potentially access your entire private message history on Facebook. Your Facebook Messenger messages are stored permanently on Facebook's servers unless you explicitly delete them. To make things worse, deleting messages is quite difficult to do en masse unfortunately due to poor UI design.
Of course, none of this would be an issue if Facebook Messenger used end-to-end encryption and did not store messages server-side. End-to-end encryption ensures any third party such as your ISP, attackers spying on the network, and in this case attackers gaining access to your account, will not be able to decrypt your messages even if they gain access to the encrypted messages.
Good end-to-end encryption protocols will also offer perfect forward secrecy. This ensures that even in case of a private key leak, previous messages will remain secret due to the use of ephemeral session keys. All of this means a solidly engineered messaging service with end-to-end encryption will provide significantly better protection against intruders trying to access your private messages.
Note: in the case the current Facebook security breach, according to TechCrunch, Facebook is saying it is "unlikely" private messages were accessed but I could not find any other source to verify this. Regardless, even if this security breach did not result in access to private messages, future breaches can easily provide access to your private messages on Facebook Messenger.
The Inevitability Of Breaches
The recent Facebook breach affecting up to 90 million users is not necessarily surprising. Facebook as a company manages an incredibly complex and intertwined set of services and software that are in a state of constant change. Imagine Facebook itself with all its features including news feed, ads, friend lists, privacy settings, photos and albums, videos, Marketplace, Live, and so on, then add to it Messenger and Instagram with all their features. Now think of all the less popular apps and services such as Pages Manager, Ads Manager, and so on. Now consider all the complex ways in which these apps and services interact with each other. The larger and more complex a system becomes, the more "surface area" it has exposed, in the sense that there are more and more potential areas where bugs can be exploited to breach the system. This is especially a problem when a bug in one area is used in combination with another bug in a completely different and unexpected area to form an attack vector, as was the case here (more on this below). In some cases, you might be affected by bugs in features you have never even used or even knew existed. All of this makes breaches a matter when and not if.
The current security breach that motivated this article was, according to Facebook's security briefing, the result of the interaction of three distinct bugs having to do with the "View As" feature which lets you see what your profile looks like viewed as somebody else, and a video upload feature related to birthday celebrations. This combination of bugs resulted in an attacker being able to see the access token of another user through the use of the "View As" feature and pivot from there to other accounts. Based on the briefing it seems possible that the attackers have been using this vulnerability for over a year (since the video upload bug was apparently introduced in July 2017) although the exact timeline is not clarified by Facebook.
To understand why it's hard to prevent this kind of issue, put yourself in the shoes of the engineer working on the video upload feature. It's very unlikely you have in-depth knowledge of the "View As" feature (and even if you happen to, by some miracle, have such knowledge, there are thousands of other moving pieces and features you can not possibly keep in mind as you work on your feature), and therefore it is very unlikely you will be able to keep in mind the complex and unexpected ways in which your code might interact with it. A simple bug in your code might result in a major security vulnerability when combined with another bug or weakness in design somewhere else in the code base.
What To Look For When Choosing A Communication Platform
With the above in mind, it stands to reason to adhere to the following three principles as much as possible when using software and services we trust with sensitive data such as private messages:
- We should prefer small, well-engineered, and self-contained software and services that focus on doing one thing and one thing well
- We should prefer open source software and services that can be audited by anyone, in particular by security experts
- We should prefer communication software and services with strong encryption protocols built-in, ideally with end-to-end encryption
Facebook Messenger does not meet any of the above criteria. Messenger is a very complex set of applications and services that are tied to an even larger ecosystem of apps and services that Facebook provides. Case in point being the how a bug in a video upload feature to wish someone a happy birthday on their news feed can result in attackers gaining access to your Messenger private messages. This makes securing your Messenger data practically impossible given the almost infinite number of attack vectors that could exist for software that complex. In addition, Facebook Messenger does not employ end-to-end encryption, and stores messages on Facebook's servers indefinitely until you explicitly delete them.
Note: a "Secret Conversation" feature exists in Facebook Messenger which provides end-to-end encryption using the Signal protocol, but most users are unaware of it, and it is not fully supported on all platforms to the best of my knowledge). Finally, Facebook Messenger is certainly not open source and its source code can not be audited by anyone who does not work for Facebook.
Signal To The Rescue
- Signal is free, open source, and developed by an organization funded by donations and grants and therefore unlikely to betray the users for as long as this funding model remains in place. And you can audit the source code for it on GitHub yourself.
- Signal uses a very strong end-to-end encryption protocol called the Signal Protocol. In fact, this protocol has become the de facto standard for strong end-to-end encrypted messaging, with many apps that offer end-to-end encryption using variations of it (e.g., WhatsApp, Allo's "Incognito Conversations", Facebook Messenger's "Secret Conversations", Skype's "Private Conversations", and so on). You can read a formal security analysis of the protocol here.
- Finally, Signal is very self-contained and not part of a massive ecosystem of apps and services like Facebook Messenger is.
But... Nobody Else Is On Signal!
Yes I get that. Ultimately the value of a messaging app is determined by who uses it. Which is why you should get on it and convince all your friends to do it too. Be that annoying friend! I even managed to convince a skeptical friend to switch to Signal contingent on my reading one of his favourite book (which happens to be Cryptonomicon, which I think is quite apt).
Why Not WhatsApp?
WhatsApp uses the Signal protocol itself and as such seems to have solid end-to-end encryption. However, given that it is not open source, it is difficult to know the extent to which it conforms to the protocol, or where and how keys and messages are stored. Similarly, it is not possible for security researchers not working for Facebook to audit WhatsApp's security by looking at its source code. As such, I still strongly suggest Signal over WhatsApp.
That being said, WhatsApp is (almost certainly) a significant improvement over Messenger when it comes to security and privacy. If Signal is too much of a jump for you, consider using WhatsApp instead which has a larger user base (and arguably a smoother user experience overall, for now at least.)
What About Google Hangouts, WeChat, Etc.
Realistically any closed source communication software without end-to-end encryption is likely to have more or less the same issues as Facebook Messenger, especially if they are part of a large ecosystem such as those of Google and Tencent. I would still strongly recommend Signal over any of those apps.
Wait, Didn't You Use To Work For Facebook?
Yes. None of what I said above is based on any inside knowledge of Facebook though. Everything mentioned is simply based on what is more or less immediately obvious by looking at the Facebook ecosystem of apps and services. I have absolutely no inside information about the particular security breach discussed in this article.