I worked at Meta for 8 years and don't know about this from the inside and am commenting from my personal point of view.
I believe this was a bug revealed long ago and the fine is finally decided.
The bug wasn't as silly as it sounds if I remember the press and it was a logging issue and not an issue with the security architecture.
It does go to show that client side apps with access to all the decrypted data can have logging bugs even if the fundamental feature is secure.
u/NebraskaCoder wrote (the comment Michael replied to):
I wish the article would have been more clear on that. I could have made different points.
u/michaelnovatireplied·
Yeah like it's a great learning opportunity if they would have explained it more haha
The engineers working on authentication might have done a perfect job and not even known because the engineers on logging made a mistake.
Ultimately it was also the fault of another team that audits everything for data integrity and tries to prevent leaks horizontally. And that team has multiple sub teams: one that builds frameworks that others use that percent leaks baked in, another that tries to find leaks proactively in the code, and another that tries to educate engineers on good practices.
A lot goes into all this and the press goes for the clicks haha.
Facebook screwed but it's not simple incompetence.
u/cd7k wrote (the comment Michael replied to):
> not an issue with the security architecture.
How is it not an issue with the security architecture? You shouldn't be *able* to know a users password, but you could compare a hash of what they entered with the hash you had stored. At no point, anywhere, should you be able to
u/michaelnovatireplied·
If I remember correctly, I think there was a couple of situations, again, I'm not speaking on behalf of the company and just as a person reading through these articles.
One was that there's a version of Facebook that runs on feature phones that has no ability to make any kind of requests other than get requests and has very minimal client-side processing, No JavaScript, no cookies, or anything.
So if you had that situation where you can only make get requests and you have zero JavaScript that you can run. how would you do authentication? You have to send the password over get but you have to make sure that every level of your back end isn't logging that in any human readable place. So you have to make sure that your server logs don't show it. you have to make sure that any logging systems that the request metadata gets sent to don't show it basically have it completely thrown away.
If you know a solution that works with only HTML no cookies, and get requests to do authentication. I'm all ears.
after the initial authentication is done then every single link on the page can contain a token in it that can be short-term and used for authentication but that initial authentication check is what I'm talking about.
Second, is the logging issue, where client-side tools can suck in every single field on the screen or like whatever logic and those could be accidentally sucked into some kind of logging back-end system that isn't actually used for authentication at all and it would just be like the same as if it's sucked in your name or a comment you made on that same screen with the bug that's being logged.