from the deep-seated-insecurities-and-paranoia dept.
Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years
Hundreds of millions of Facebook users had their account passwords stored in plain text and searchable by thousands of Facebook employees — in some cases going back to 2012, KrebsOnSecurity has learned. Facebook says an ongoing investigation has so far found no indication that employees have abused access to this data.
Facebook is probing a series of security failures in which employees built applications that logged unencrypted password data for Facebook users and stored it in plain text on internal company servers. That’s according to a senior Facebook employee [ . . . . ]
My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords. [ . . . . ]
Both Github and Twitter were forced to admit similar stumbles in recent months, but in both of those cases the plain text user passwords were available to a relatively small number of people
[ . . . . ] the issue first came to light in January 2019 when security engineers reviewing some new code noticed passwords were being inadvertently logged in plain text.
If I had a Facebook account, I would be reassured by Facebook's reassuring reassurances.
Related Stories
Facebook Stored Millions of Instagram Passwords in Plain Text:
Facebook says it stored millions of Instagram users’ passwords in plain text, leaving them exposed to people with access to certain internal systems. The security lapse was first reported last month, but at the time, Facebook said it only happened to “tens of thousands of Instagram users,” whereas the number is now being revised up to “millions.” The issue also affected “hundreds of millions of Facebook Lite users” and “tens of millions of other Facebook users.”
Passwords are supposed to be stored in an encrypted format that allows websites to confirm what you’re entering without directly reading it. But as Krebs on Security first reported, various errors seem to have caused Facebook’s systems to log some passwords in plain text since as early as 2012. Facebook noticed the problem in January and said in March that the issue had been resolved.
Who could ever imagine imagine FaceBook treating users' passwords as if it were a game.
(Score: 4, Funny) by JakeLight on Friday March 22 2019, @02:29PM (13 children)
Phew...that was a close one! Thank goodness they didn't abuse that data!!
(Score: 2) by Runaway1956 on Friday March 22 2019, @02:35PM
I am also reassured, LOL!
(Score: 2) by DannyB on Friday March 22 2019, @02:39PM (11 children)
Facebook employees did not abuse any data. Or any squirrels.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Touché) by Booga1 on Friday March 22 2019, @02:44PM (2 children)
The squirrels are probably pretty safe.
It's the llamas that had to be worried, at least over at AOL's Winamp department.
Radionomy bought Winamp but it remains to be seen how they'll treat the llamas.
(Score: 4, Funny) by looorg on Friday March 22 2019, @03:48PM (1 child)
I would assuming there will be some kind of spanking of the buttocks area involved for the llamas.
(Score: 3, Funny) by cmdrklarg on Friday March 22 2019, @03:54PM
That was Winamp's job.
The world is full of kings and queens who blind your eyes and steal your dreams.
(Score: 1, Funny) by Anonymous Coward on Friday March 22 2019, @02:47PM (7 children)
Once you make the all-important distinction between (epistemic) data space state and (ontic) configuration or phase space state in (applied) non-classical cryptographic analysis, then do you stand by your words?
(Score: 1, Funny) by Anonymous Coward on Friday March 22 2019, @03:04PM (2 children)
Um ... let me get my decoder ring and figure out what you just asked. In the mean time, would you like to keep yourself busy by accessing our user data via this "secure" (wink wink) API?
(Score: 4, Funny) by DeathMonkey on Friday March 22 2019, @06:07PM (1 child)
Well I don't know exactly how we're going to fix it but it'll probably involve reversing the polarity of the dilithium crystals.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @08:33PM
Don't forget to wear your anti static wristbands.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @03:10PM
That's what she said.
(Score: 2) by DannyB on Friday March 22 2019, @03:30PM (2 children)
Let me run that through my genetic adversarial monte carlo generative quantum deep neural network Bayesian filter simulation algorithm. Then I'll get back to you with an answer.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1, Funny) by Anonymous Coward on Friday March 22 2019, @04:50PM (1 child)
The meaning of the data has not changed just because the reality of the data's state (abused vs not) has been altered. It is mathematically impossible for us to "abuse data". It is very simple: the (ontic) phase space state is a TOTALLY DIFFERENT THING than the (epistemic) data space state.
(Score: 0) by Anonymous Coward on Saturday March 23 2019, @01:27AM
"it's a duck."
"no, it's a rabbit."
link: https://commonsenseevaluation.com/wp-content/uploads/2015/05/Duck-Or-Rabbit.jpg [commonsenseevaluation.com]
(Score: 4, Funny) by Snow on Friday March 22 2019, @03:01PM
Shocked I tell ya! Facebook has always been at the forefront of user data security and privacy. I can't believe that they didn't properly protect private user data.
FAKE NEWS!
(Score: 2, Insightful) by realDonaldTrump on Friday March 22 2019, @03:05PM
Facebook, if you're listening, I thank you. Christopher Wray, my top G-man, thanks you. And the American "people" thank you. The only responsible encryption is NO encryption. No more San Bernardinoes!!!!
(Score: 2) by Freeman on Friday March 22 2019, @03:10PM (8 children)
Not storing your users' passwords in plain-text is what I would call very basic security practice. It could almost be forgiven, if this happened near the beginning, and fixed later. As opposed to just extremely poor customer privacy standards. Of course, considering, they're selling your data anyway, it's more like par for the course.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Insightful) by Runaway1956 on Friday March 22 2019, @03:23PM (1 child)
Well, you have a word out of place there, it seems. Facebook values your privacy, and mine, but not NEARLY as much as they value their CUSTOMER's privacy!! We both know who their primary, secondary, and tertiary customers are, right? 1. US/5eyes intel communities 2. corporations with deep pockets 3. corporations and governments with less deep pockets. Joe and Jane Sixpack and their stick figure families of fifteen kids and a poodle are PRODUCTS.
http://66.media.tumblr.com/4c40c4673c59f19a613067631aa5cc01/tumblr_mzaqpgXs3J1qznswqo1_1280.jpg [tumblr.com]
(Score: 2) by Runaway1956 on Friday March 22 2019, @03:35PM
Forget the tumblr link - unfortunate stick figure family is much more fun! I may put them all together, and loop them for entertainment! https://www.youtube.com/results?search_query=unfortunate+stick+figure+family [youtube.com]
(Score: 3, Interesting) by DannyB on Friday March 22 2019, @03:39PM (3 children)
I THINK that Facebook stores passwords in a non-plaintext form. At least that's how I read TFA.
That is why someone had to implement plaintext password logging in some code somewhere to capture the passwords. This was then discovered in the code review.
Once you start massively logging plaintext passwords, then you've completely defeated the purpose of encrypting or hashing passwords. (Hint: hash, don't encrypt. Also hash with salt and pepper)
Next best practice: Once you've hacked the login procedure to store plain text login passwords, then create an API to make them widely available. It won't be abused. I promise!
But the way that I did it in my project was to hash the password in the browser before it ever goes to the server (over TLS). I could always change the code to send the password over TLS to the server where it could be hashed. Any opinions about the tradeoff of hashing the password at the browser vs the server?
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @05:11PM
So, if this secondary file that was generated with the user's plaintext password was then encrypted with a different algorithm that someone else has a key to.... same thing as a plaintext file of passwords, or different? And RDT's description above notwithstanding, this does indeed seem like a very nice way that certain TLA's could have freedom to operate. Makes me wonder if it has been determined yet precisely why this mechanism was enacted - for what purpose? Maybe enough so to make me go read TFA..... Nah!
(Score: 3, Insightful) by tibman on Saturday March 23 2019, @12:10AM (1 child)
I'd say the downside of doing it in browser is you are giving the secret sauce away. Anyone who can read js will know the hashing algorithm used. Salt (and Pepper) is also used before/during hashing so you'd be giving that away too.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by DannyB on Monday March 25 2019, @01:48PM
Login should be a 2 step (eg 2 page) process.
Page 1: Enter user id / email address.
* this page might be pre-configured by the user for this browser to store a cookie per each different device the user uses. Either skipping the login process entirely, or the login page already has the user id / email address entered into the field; independent of anything in the browser that might try to pre-fill your login forms for you. Whether this kind of feature is offered at all is up to the site, whether any particular user chooses to turn it on for themselves, for a specific device / browser they use, is up to the user.
Page 2:
* this page might not appear at all if everything is suitably configured, as per above. Such as if the user picked [x] Remember Me on this device, for XX days. Or if the site supports a 2FA dongle, and that dongle is present on this particular computer.
* this page might ask the user for a password
* or this page might ask the user for a one time code that was just SMS texted to their phone
* or a fingerprint or eye retina scan or blood sample or other medical probing
When the login is a 2-stage process, the 2nd page is what would get the salt / pepper if hashing is done at the browser. So a valid user id / email would have to be entered on page 1, before page 2 appears asking for a password. Assuming page 2 appears at all, or page 2 doesn't use some other operation like an SMS secret code, USB dongle, etc.
If an unrecognized user id / email is entered on page 1, we would still go to page 2, with a fake salt / pepper that is some kind of function of the user id that was entered (so that the same user id consistently generates the same salt / pepper values). An attacker doing a dictionary attack doesn't know whether he entered a valid user id or not, because page 2 for a password is always presented.
I don't think the hashing algorithm is too much of a secret sauce.
If you did know someone's user id, I know jack's user id is 'jack-cough'. So I could send that and see what salt / pepper values I get back. But knowing those doesn't help me unless I can then steal the user login table from the server. Then I still have to brute force trying all passwords with the now known salt / pepper in order to possibly get a valid login. But other policies prevent a brute force login attack, like a mandatory 2 second response time for the login, maximum number of failed attempts, with progressive account lockout times, soon followed by permanent lockout requiring manual reset.
What do you think?
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by looorg on Friday March 22 2019, @03:50PM (1 child)
But just imagine how much electricity they save every year by not using encryption and wasting all them CPU-cycles to deal with that. It's for the environment!
(Score: 2) by All Your Lawn Are Belong To Us on Friday March 22 2019, @05:16PM
They needed the compute cycles for cryptocurrency mining.
This sig for rent.
(Score: 5, Funny) by kazzie on Friday March 22 2019, @03:37PM (5 children)
Have they made any of those? Or was it the usual non-reassuring reassurances?
(Score: 5, Insightful) by DannyB on Friday March 22 2019, @03:48PM (4 children)
* Facebook says an ongoing investigation has so far found no indication that employees have abused access to this data.
That is reassuring.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* The Facebook source said the investigation so far indicates between 200 million and 600 million Facebook users may have had their account passwords stored in plain text and searchable by more than 20,000 Facebook employees.
That is very reassuring. It almost guarantees that the first statement is NOT so reassuring.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* The source said Facebook is still trying to determine how many passwords were exposed and for how long, but so far the inquiry has uncovered archives with plain text user passwords dating back to 2012.
Good thing it only went on for a limited amount of time.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords.
Very reassuring. It assures me that the likelihood of abuse is approximately 100%.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* “The longer we go into this analysis the more comfortable the legal people [at Facebook] are going with the lower bounds” of affected users, the source said.
Not surprising.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* “Right now they’re working on an effort to reduce that number even more by only counting things we have currently in our data warehouse.”
Alter the methodology.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* the company wasn’t ready to talk about specific numbers — such as the number of Facebook employees who could have accessed the data.
Despite that the article's inside source already gave numbers.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* the company planned to alert affected Facebook users, but that no password resets would be required.
Of course not. Resetting passwords would the collected plaintext passwords useless. Someone would have to go re-hack the login procedure to log plaintext passwords and start collecting them all over again!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* “We’ve not found any cases so far in our investigations where someone was looking intentionally for passwords, nor have we found signs of misuse of this data,”
Just because you don't see it doesn't mean it isn't there. Bad actors try to hide what they do. At least if they know what's good.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* “In this situation what we’ve found is these passwords were inadvertently logged but that there was no actual risk that’s come from this.
How do you know that?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* “We have a bunch of controls in place to try to mitigate these problems, and we’re in the process of investigating long-term infrastructure changes to prevent this going forward. We’re now reviewing any logs we have to see if there has been abuse or other access to that data.”
I find this very reassuring.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Runaway1956 on Friday March 22 2019, @04:28PM (1 child)
My favorite bit is "inadvertantly logged". Yet, thousands of employees performed searches which pulled millions of chunks of data. Were those bits, bytes, packets, or maybe more commonly understood Mb - or maybe even Gb?
(Score: 2) by Bot on Friday March 22 2019, @06:25PM
My favorite bit is "inadvertantly logged".
Wow, the only organization which would have benefited from the famed systemd-journald treatment of logs, but no, they just had to actually log data in plaintext.
Account abandoned.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @04:57PM (1 child)
I... I think I love you.
(Score: 2) by DannyB on Friday March 22 2019, @07:41PM
(rewrite
'((When a girl is in love you can see it in her smile)
(When a guy is in love you can see it in his ?x))
'{?x eyes})
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by Bot on Friday March 22 2019, @06:20PM (1 child)
Read a book about web development, or have a try with any full stack web app framework.
See if they don't have login facilities already built in who at the very minimum store a hash of the password. Some have an app wide long secret string, some store a salt for every user, while bloggers discuss the strength of hashing functions or the rationale for adding another secret to the salt (the pepper, LOL).
You can easily understand it with a high school education.
Now you are telling me that an actual pro software engineer would use plaintext in password fields if that wasn't EXPLICITLY wanted? What's next? F1 driver forgets what brakes are for, crashes into barrier? Never attribute to incompetence what you cannot attribute to incompetence.
Account abandoned.
(Score: 2) by tibman on Saturday March 23 2019, @12:15AM
I'm thinking it was something like someone decided to log all api calls (for debugging purposes). Those logs included all parameters/payloads sent to the api. Usernames and Passwords were parameters send to the login api : / really stupid (amateur!) mistake
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @07:19PM
My personal ongoing investigations have found no indication of any NSA spying ever! (rumors, court documents, FOIA revelations, NSA mission statement and common sense aside)
Quite like 'No recollection'...
(Score: 2) by The Archon V2.0 on Friday March 22 2019, @07:55PM
And the Zuckerbot's AI routines needs every cycle they can get.
(Score: 0) by Anonymous Coward on Friday March 22 2019, @08:14PM
At a major research university, passwords were stored in the clear on a highly (more so than others) secured server. For what reason? Perhaps to support integration with old mainframe apps, perhaps to enforce "best practice" policies on password make up and password reuse. Anyway, the academic side heard about it and spent a couple of years doing passwords research on the data.
Most of the Silicon Valley spy outfits have strong academic ties, and operate research divisions. No doubt they at least will also have had access to plain text passwords, since people will probably treat these logins as high-valued, like a banking site password they will want to research them.
(Score: 2) by exaeta on Friday March 22 2019, @09:59PM
The Government is a Bird
(Score: 0) by Anonymous Coward on Friday March 22 2019, @11:35PM
What should happen:
Facebook should be fined, and the CEO should be held personally responsible for failure to properly secure users passwords.
50% of the Zuks personal fortune should be handed over to the government as a fine for this failure to properly oversee the underlings in his organization.
What will actually happen:
A lot of screaming and yelling on various internet forums. But no penalties for Facebook or the Zuck will occur.