I've been wrestling with them for turning off access via their Graph API to a public resource on a Page where the Page has access to that resource, and their rationale was due to the great privacy changes they're making to protect users privacy. While they're busy breaking the apps that businesses rely on to manage their Facebook Pages (without prior notice, ala the whole Instagram API fiasco), they aren't protecting the one thing that allows access to a user's privacy - passwords.
So Facebook "determined" that the passwords were not "internally abused" or "improperly accessed". But, they could have been accessed. When employees have access to passwords, how does FB know that they were not transferred outside of FB? An employee could have taken pictures, or have a photographic memory and remember a large number of passwords.
If they were sitting in a log file somewhere, you could probably audit who had accessed them. The file permissions might have allowed access, but the audit logs could show that nobody did.
P.S. I have no knowledge of what actually happened.
How do you know that the platform engineers at Instacart haven't surreptitiously inserted a memory debugger into their app servers and recorded all the passwords people log in with? Does that sound far fetched to you? It's something teenagers have done for fun.
Funny that you mention Amazon, because open S3 buckets have been implicated in dozens of security breaches.
It's not so much that Amazon is the culpable party in those instances, but so many times, have I encountered a headline citing a "massive exposure of protected data" and somewhere in the body of the article, someone had dropped everything into an S3 bucket marked open read for public everyone.
So, is it Amazon's fault? This sort of thing was an FTP server thing, before S3 reduced the hardware infrastructure overhead of setting up and maintaining your own secure FTP server...
But, then again, lowering the technical bar meant letting in more and more non-experts, and naive, or otherwise less competant people. This, of course, broadens market penetration, and increases revenue. So, to add barriers, irritating warnings, nanny-goat advisories, hazard alarms to such a versatile and useful product might seem tantamount to leaving money on the table. After all, the goal of the product is ease of use. And, by the way, how does one solve the problem of bone-headed users?
But, you know, there's the real distinction between an AWS S3 data breach and a Facebook data breach: with S3, you've shot yourself in the foot. Facebook, on the other hand, is pointing a gun at you.
Which other large company store plain text passwords? How long before they start trying to re-use the passwords to log in other services without your consent
> Which other large company store plain text passwords?
That's not really what Facebook is saying they did. They accidentally logged passwords to a log file somewhere. They're not saying they stored them in the users database in plain text.
Irrelevant. The point was that "we accidentally logged something sensitive" is something any big tech company can (and is likely to) do. Deliberately storing passwords as plaintext in the users table much less so.
> Also, I guess they don't look at their log files?
If they were temporarily logging something for a particular reason, and forgot to turn it off, there'd be no reason to.
I work at AMZN and am actually a "security certifier" who is in charge of making sure that services don't do stuff like this. There are numerous policies about what customer information you can handle/log/store and how to handle/log/store it. In addition, before your service can serve traffic, a certifier will go through and audit your code to make sure that you aren't logging any PII or other dangerous-to-log data.
Plenty of fallible human actors involved, but the processes are definitely in place to prevent behavior like this.
I think you're assuming the passwords were stored in readable format as a matter of design. That would get reviewed and flagged at any moderately competent tech company.
I think it was probably something more inane like a POST body being logged. That could slip through a reviewer's crack easily.
Gateways filter that before internal services see anything. There's not any reason to be playing with passwords beneath the Authentication layer. Credentials should be exchanged for the customer identity and expirable nonce. If that mistake happened in the authentication/authorization layer then it becomes a big question of competence.
I really want to be a fly on the wall at the meeting where the inevitable "you shouldn't have done this" statement is countered with "but you said we should move fast and break things".
We have had the cryptographic technology for year that allows us to authenticate ourselves to third parties without giving them secret information. Why are we still using passwords?
I will say here what I said on security Slack just a few minutes ago:
Security people see shit like this all the time. Facebook found a raw request log, which inevitably contained lots of passwords. Rather than doing what most tech companies would have done --- delete the log and pretend nothing ever happened --- they disclosed the log in a fashion that guaranteed a whole news cycle about it.
I don't like Facebook. Facebook is bad. But Facebook handled this about as well as I've seen anyone handle this. Cheers to them for that. This story is not a good reason to single Facebook out.
As a very large and very public tech company, they assume they have whistleblowers' eyes on anything that gets discovered, even internally. I assume they go public with it precisely so that no one else can do so first.
It is more like if they don't respond, repeatedly.
Also, it isn't clear if there is PD (Personal Data) there--just a password would not be enough to identify a person. If it were in combination to user ID or email, it would be.
This is an odd defense. You're in essence arguing this is a non-story because no one is capable of securing large amounts of user data over time.
I think that's significant in itself, and at odds with claims the big five make in public and to regulators about the viability of their core business model.
I think that is a totally fair criticism of giant tech companies, that it's relevant, and that it's valid.
I do not think people can pretend to work in an industry where this isn't a norm, and that Facebook is somehow handling this far worse than everyone else is.
I don't know about the rest of the crowd here, but the fact that this is the norm is what makes this a story. How many leaks like this have to be revealed before we change our ways in this industry?
My main issue is that they're not issuing a mandatory password reset for this leak, likely to save face from all their users who are completely unaware of this debacle.
Dont you think calling it a leak is disingenuous. Passwords were available and NO evidence points towards them being accessed. Thats a vulnerability that was not exploited, as far as they know. A leak would mean the data WAS accessed.
And a leak doesn't need evidence that it was accessed to be deemed a leak. They were stored in plaintext, potentially accessible by internal employees. That's enough to warrant a password reset. It's not asking for much.
One should only entrust their password to a hashing algorithm.
I guess if there's such a thing as an "internal leak", that's what this is. The word "leak", by itself, connotes an exposure that is not in evidence, and given the sensitivity of the topic, I think precision is called for.
Yes, when it comes to this sort of sensitive information, there is such a thing as an internal leak. We've had PCI-compliance to ensure companies handle credit card information properly. Then we have GDPR and similar laws for personally identifying information.
Access to account credentials for a large social media platform definitely falls into the sensitive & personally-identifying category.
I think the logs were accessible to anyone in the company, probably vendors also. So disclosing seems appropriate, I dont think this kind of wide sharing of sensitive data is the norm, I have seen this mostly at startups (but also some others) that move fast and see security as developer productivity friction.
Companies that take security serious wouldn't give access to logs to everyone in the company in the first place.
41 comments
[ 5.2 ms ] story [ 75.7 ms ] threadI've been wrestling with them for turning off access via their Graph API to a public resource on a Page where the Page has access to that resource, and their rationale was due to the great privacy changes they're making to protect users privacy. While they're busy breaking the apps that businesses rely on to manage their Facebook Pages (without prior notice, ala the whole Instagram API fiasco), they aren't protecting the one thing that allows access to a user's privacy - passwords.
P.S. I have no knowledge of what actually happened.
It's not so much that Amazon is the culpable party in those instances, but so many times, have I encountered a headline citing a "massive exposure of protected data" and somewhere in the body of the article, someone had dropped everything into an S3 bucket marked open read for public everyone.
So, is it Amazon's fault? This sort of thing was an FTP server thing, before S3 reduced the hardware infrastructure overhead of setting up and maintaining your own secure FTP server...
But, then again, lowering the technical bar meant letting in more and more non-experts, and naive, or otherwise less competant people. This, of course, broadens market penetration, and increases revenue. So, to add barriers, irritating warnings, nanny-goat advisories, hazard alarms to such a versatile and useful product might seem tantamount to leaving money on the table. After all, the goal of the product is ease of use. And, by the way, how does one solve the problem of bone-headed users?
But, you know, there's the real distinction between an AWS S3 data breach and a Facebook data breach: with S3, you've shot yourself in the foot. Facebook, on the other hand, is pointing a gun at you.
That's not really what Facebook is saying they did. They accidentally logged passwords to a log file somewhere. They're not saying they stored them in the users database in plain text.
Also, I guess they don't look at their log files? The passwords were there in clear text for 7 years apparently: https://techcrunch.com/2019/03/21/facebook-plaintext-passwor...
Irrelevant. The point was that "we accidentally logged something sensitive" is something any big tech company can (and is likely to) do. Deliberately storing passwords as plaintext in the users table much less so.
> Also, I guess they don't look at their log files?
If they were temporarily logging something for a particular reason, and forgot to turn it off, there'd be no reason to.
Anyways, what other companies should we avoid, according to you (the ones that you referenced in your previous comment)?
Are you protecting your friends at Facebook, and yourself, because you know that you are likely to do the same mistake?
Plenty of fallible human actors involved, but the processes are definitely in place to prevent behavior like this.
I think it was probably something more inane like a POST body being logged. That could slip through a reviewer's crack easily.
Not defending this breach in any way.
Security people see shit like this all the time. Facebook found a raw request log, which inevitably contained lots of passwords. Rather than doing what most tech companies would have done --- delete the log and pretend nothing ever happened --- they disclosed the log in a fashion that guaranteed a whole news cycle about it.
I don't like Facebook. Facebook is bad. But Facebook handled this about as well as I've seen anyone handle this. Cheers to them for that. This story is not a good reason to single Facebook out.
1. Aren't they legally required to under GDPR?
2. Let's not give them too much credit. They updated an old blog post on the day the Mueller investigation report got released.
Yeah, if they get caught. Which they don't have to be.
Also, it isn't clear if there is PD (Personal Data) there--just a password would not be enough to identify a person. If it were in combination to user ID or email, it would be.
I think that's significant in itself, and at odds with claims the big five make in public and to regulators about the viability of their core business model.
I do not think people can pretend to work in an industry where this isn't a norm, and that Facebook is somehow handling this far worse than everyone else is.
And a leak doesn't need evidence that it was accessed to be deemed a leak. They were stored in plaintext, potentially accessible by internal employees. That's enough to warrant a password reset. It's not asking for much.
One should only entrust their password to a hashing algorithm.
Access to account credentials for a large social media platform definitely falls into the sensitive & personally-identifying category.
At incompetent startups with no expertise in security
> found a raw request log, which inevitably contained...
But the existence of the log is not inevitable! Is it so inreasonable to hold Facebook to a professional standard?
> they disclosed the log in a way
They snuck in an amendment to a previously posted press release while the press was in an uproar about the Mueller report!
They handled this in about as clumsy and dishonest a way as possible. Knowing the executive team, I dare say that -is- as good as we can expect.
Not exclusively.
Companies that take security serious wouldn't give access to logs to everyone in the company in the first place.