Meta fined $101 million for storing hundreds of millions of passwords in plaintext
therecord.mediaEuropean regulators fined Meta for an engineering mistake that the social media giant first reported in 2019.
You must log in or register to comment.
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 57 users / day
- 383 users / week
- 1.5K users / month
- 5.7K users / 6 months
- 1 subscriber
- 3.13K Posts
- 78.4K Comments
- Modlog
101 million is too small for such an epic error.
I think the PR fall out could be much worse. Time to get them on the news
Seriously. Didn’t they make billions last year? That number should be much, much higher for Zuck & Co. to actually start giving a fuck.
I think it is just Ireland though (which is why I added Ireland to the title).
Google did it too for a decade
Does anyone remember an article/interview a while back where Mark Fuckerberg shamelessly admitted that he chose not to hash passwords in the original Facebook codebase specifically because he wanted to be able to log into his users’ other accounts that use the same password? I swear I remember reading something like this but now I can’t find it.
Yes, he wanted to stop bad press ironically
Your memory is not far off. Mark used failed logins to access other people’s emails:
https://www.businessinsider.com/how-mark-zuckerberg-hacked-into-the-harvard-crimson-2010-3
I cant say if he intentionally saved passwords unencrypted, but he certainly saved login attempts
Usually these services have god mode where they can see a UI from a given user. They don’t need the password.
This sounds like a rumor spread by someone who doesn’t understand tech
The OP made the argument that Zuckerberg wanted to know their passwords, such that if the users reused the same passwords elsewhere, then he would be able to log in there and check out their accounts.
For example he could have seen a profile he was interested in, nabbed their password and looked into their email.
Not that he wouldn’t have godmode on their Facebook account, and needed their password to access their account, because of course he could have just accessed those accounts without needing the password.
I have not heard this rumor before, though I wouldn’t be completely surprised if it was true.
Well, Facebook did have an auth method that involved promoting you for your password so that they could log into your email and get an OTP iirc
It wasn’t zuckerberg doing something in secret. It was an explicit protocol that was terrible. They got called out and stopped it. Kinda like early days of open graph.
Zuckerburg abused to attack journalists
This is not about facebook not hashing credentials, it is that they appeared in internal logs.
Source: Krebs on Security
Why the fuck would you need to log a password ever? This is absolutely malice and not incompetence.
You are acting like someone checked off a “log passwords” box, as if that’s a thing that even exists
Someone configured a logger to write HTTP bodies and headers, not realizing they needed to build a custom handler to iterate through every body and header anonymizing any fields that may plausibly contain sensitive information. It’s something that literally every dev has done at some point before they knew better.
You should never be sending passwords to a server. That is really bad practice. The right answer is to use cryptography to verify the client knows the password.
Client side verification is just security by obscurity, which gains you very little.
If someone is capable of MITM attacking a user and fetching a password mid-transit to the server over HTTPS, they are surely capable of popping open devtools and reverse engineering your cryptographic code to either a) uncover the original password, or b) just using the encrypted credentials directly to authenticate with your server without ever having known the password in the first place
That assumes that an adversary has control of the browser. The big reason you don’t want to send passwords over https is that some organizations have custom certs setup. It is better to just not send the password at all.
No it doesn’t, if they intercept an encrypted password over HTTPS they can resend the request from their own browser to get access to your account
What is the problem with that? The password is secure and only shared between you and the site you are intending to communicate with. Even if you sent an encrypted password, they wrote the client side code used to generate it, so they can revert it back to its plaintext state server side anyways
How would you verify it then?
If not sending plaintext passwords was best practice then why do no sites follow this? You are literally posting to a site (Lemmy) that sends plaintext passwords in its request bodies to log-in
If you’re working for a multinational tech company handling sensitive user data and still make this mistake, then you are being malicious in your incompetence. This is something that would cause you to lose a significant amount of marks on a first year college programming project, let alone a production system used by literally billions of people.
I can’t tell you how many times I’ve seen passwords appear in logs. Its always a struggle, everywhere.
Use TOTP
Just one open source example … freeradius has an option to log passwords:
Or another example: The apache web server has a module that dumps all POST data, with passwords, in plain text:
I don’t agree that this is “absolutely malice”, it could also be stupidity and forgetfulness.
Riiight, like that’s any better. Jokes aside, it’s hard to imagine what kind of “mistake” results in storing plain text instead of hashing, unless the mistake was in choosing whoever made the security assessment
Christ, the hell I would’ve gotten, in the 90’s, if I’d done something like this.
There was a previous article on this with more explanation that I’m struggling to find.
The gist was that they do hash all passwords stored, the problem was that there was a mistake made with the internal tool they use to do that hashing which led to the passwords inadvertently going into some log system.
“mistake”
I call BS. The reviews I’ve gone through for trivial stuff would’ve exposed this.
This was intentional.
Never assume malice when something can be explained by stupidity
I generally agree.
But any decent code review process would’ve exposed this, or at least a data surveillance system that checks this stuff. I’ve received a few notifications about my logs storing inappropriate data, as a result of a scanning system.
Some manager knew about this during a code review, and signed off on the risk because it was only in-house.
Yeah, cause trivial systems are a lot easier to parse and review. At a base level that’s nonsense logic.
My point being the extensiveness of a review process.
The more important a system, the more people it impacts, etc, the more extensive the review process.
Someone chose to ignore this risk. That’s intentional.
You quite frankly, don’t know what happened and if you’re confident it’s intentional, all that says is that you’re a grump who likes to complain.
A mistake doesn’t mean it’s an accident. A mistake means they made the wrong choice.
Hanlon’s Razor revised: Never attribute to malice what can be attributed to incompetence, except where there is an established pattern of malice.
Then incompetence at a level that’s incomprehensible.
A code review certainly exposed this, and some manager signed off on the risk.
Again, changes I make are trivial in comparison, and our code/risk reviews would’ve exposed this in no time.
Makes sense now, thank you