Upto 600m user passwords were stored on Facebook servers in plain text
22 March 2019
Passwords of between 200 million and 600 million Facebook users were stored in plain text on internal Facebook servers for years, indicating major data protection failures on part of the global social media giant, security researcher Brian Krebs has revealed.
A senior Facebook employee recently told Krebs that a number of employee-built applications logged unencrypted passwords of millions of Facebook users and stored them in plain text on Facebook’s internal servers. Over 20,000 Facebook employees who had access to these servers could view these passwords anytime they wanted.
In fact, around 2,000 developers or engineers “made approximately nine million internal queries for data elements that contained plain text user passwords,” said the source.
Facebook discovered password exposure in January
Soon after Krebs made the revelation, Facebook said in a blog post that it had discovered the storage of user passwords in plain text during a security review in January this year, adding that there is no evidence of anyone improperly accessing or internally abusing such passwords.
“As part of a routine security review in January, we found that some user passwords were being stored in a readable format within our internal data storage systems. This caught our attention because our login systems are designed to mask passwords using techniques that make them unreadable. We have fixed these issues and as a precaution, we will be notifying everyone whose passwords we have found were stored in this way.
“To be clear, these passwords were never visible to anyone outside of Facebook and we have found no evidence to date that anyone internally abused or improperly accessed them. We estimate that we will notify hundreds of millions of Facebook Lite users, tens of millions of other Facebook users, and tens of thousands of Instagram users. Facebook Lite is a version of Facebook predominantly used by people in regions with lower connectivity,” the company said.
Having admitted that user passwords were indeed stored in a readable format on its internal servers, the company clarified that it salts and hashes user passwords to encrypt them and also uses a function called “scrypt” as well as a cryptographic key to replace user passwords with random sets of characters. This way, it can validate that a person is logging in with the correct password without actually having to store the password in plain text.
At the same time, the company sends instant alerts to users in case login attempts are made from an unrecognized device or from an unusual location.
Users must change their Facebook passwords immediately
“Although Facebook says there were no signs of abuse, it seems unlikely that none of the alleged 20,000 employees with access to those passwords even once poked around where they shouldn’t have. Facebook says it won’t require password resets until it does find signs of abuse, but I would recommend changing your account password, anyway. Be sure to use a password that’s at least 12 characters, uses a combination of numbers, symbols, and upper- and lower-case letters, and is unique to your Facebook account,” said Paul Biscoff, privacy advocate at Comparitech.
Matthew Gardiner, a cybersecurity strategist at Mimecast, said that the storage of user passwords in plain text is an example of how poor secure coding practices can cause security vulnerabilities to be created and not caught for an extended period. And when an application has the number of users as Facebook, this problem can become very large, very quickly!
“Given that there is never a legitimate technical or business reason for passwords to be transmitted or stored in cleartext and given that Facebook has a set of quite robust password security practices in place, the only rationale is that this problem was created through insecure coding practices sometime in the past.
“The best practice for avoiding this is to employ SecDevOps practices as an integral part of application development. Catching the vulnerability after the fact, but before malicious usage occurs, is good but doing so at the time of development is much better,” he added.