Live data from Hacker News

A Facebook engineer abused access to user data to track down woman

businessinsider.com.au

51–60 of 108 posts

Re: A Facebook engineer abused access to user data to track down woman

#51
post #15

I worked at Facebook for most of 2017 and 2018. In the first week, they made it clear that you would be fired instantly for any improper access of user data. They further said that if you need to access any sensitive personal data, or if you need to log in as a user in order to debug a problem, you need to have approval from your manager _before_ the access, not after. Also, you are not allowed to access the data of…

So did people actually get fired over this? Or do you have any reason to actually believe that they would have noticed?

Re: A Facebook engineer abused access to user data to track down woman

#52
post #35

> At the time, more than 16,000 employees had access to users’ private data, according to the book. > Stamos suggested tightening access to fewer than 5,000 employees and fewer than 100 for particularly sensitive information like passwords. I'm sorry, what? I can tell you the number of legitimate engineers that should have access to user's passwords. It's a nice, round number. It's zero.

"like passwords" probably comes from the journalist and doesn't actually mean that anyone has access to passwords.

Passwords wouldn't be the most sensitive data Facebook holds for most people - private photos sent via Messenger are probably way more sensitive.

Re: A Facebook engineer abused access to user data to track down woman

#54
A lot of the commenters here are rightly not surprised about this. A few years down the line this is going to be a similar thing with voice activated devices like Alexa. Employees, contractors, advertisers will all have access to the voice data of not just the person using these devices but of those who just happen to be in the vicinity. And no one will be surprised about it.

Re: A Facebook engineer abused access to user data to track down woman

#55

Pretty inexcusable by 2015. FB was hardly a new company at that point. Every Googler gets the message that you keep your mitts off private information in logs (or get terminated) drilled into them in their first week of training. Logs access is a) restricted b) audited c) tiered and d) enforced . That was the case in 2011 when I started and it's the case now. Not saying Google is perfect, but it's not like companies…

I know an engineer, a security engineer at Google who is pretty well-known, who went to work at Google specifically so he could get at peoples personal data. I don’t know if he actually does it, but he boasted quite openly for years that he wanted to be the “architect“ and see everything and know everyone’s secrets. He is now a highly placed Google security employee.

That’s pretty disturbing.

Re: A Facebook engineer abused access to user data to track down woman

#56
post #39

> At the time, more than 16,000 employees had access to users’ private data, according to the book. > Stamos suggested tightening access to fewer than 5,000 employees and fewer than 100 for particularly sensitive information like passwords. I'm sorry, what? I can tell you the number of legitimate engineers that should have access to user's passwords. It's a nice, round number. It's zero.

Is the password sent to Facebook or does it never leave the client? (Genuine question - I have no idea how modern web apps do authentication)

In the case of a username/email + password login, the password is sent to Facebook. Code on their end uses a one-way encryption to turn it into a unique value that's compared against a value they stored in the database when you set your password. As long as the one-way encryption is done with the same values, the two passwords match, and FB knows that you've typed the correct password without them having to store your plain-text password in their database

Some insecure websites (not Facebook) may not do this, and instead store your credentials in a database without encryption. It's a terrible idea, and GP's comment seemed to be referring to this when they (correctly) suggested that no one should have access to a database of plain-text passwords.

The replies mostly refer to the fact that even if the password never hits FB's database, there is still code running on authentication servers that handles that password in plain text before it's been encrypted. Limiting engineer access to authentication servers is a good idea, but it'd be challenging to prevent ALL engineers from having access.

Re: A Facebook engineer abused access to user data to track down woman

#57

Earlier quoted context omitted.

I'm surprised that this stuff is audit only. At my company, at least in the past five years or so, this type of access has been forbidden to almost all employees. You need to request access to these types of systems and provide justification for why you should have it. Access is controlled on a per-system basis -- it's not blanket access. Many of the most sensitive systems have auto-expiring access for humans. Nowada…

How “sensitive” is facebook user data though? All content in a facebook account is already visible to an average of >100 people - their facebook friends. (Messenger had stronger protections than OP is describing)

Extremely sensitive, by the lights of the organization I work for. The people to whom FB user data is visible are known to the user. Those people have been explicitly authorized by the user to view that data. FB is acting as the user's agent in conveying that data only to authorized recipients, who the user presumably trusts to some degree or another to not further propagate the data. The data is generally not publicly visible, and FB employees are generally not among the list of entities the user intends to convey the data to.

Re: A Facebook engineer abused access to user data to track down woman

#58
I was on vacation in Egypt, this year, with a guy who worked at Facebook, along with a fairly large group of us from the States. He would stalk people's Facebook profiles in our group to find out information on them and even confront them about it, if they made him upset enough. He even messaged them directly on Facebook to tell them off.

As a side note, he was mostly only interested in having hook ups and orgies with Ukrainian tourist women, while in Egypt, made even more bizarre when we found out he has a wife back in the United States, of which, worked at Apple.

He was not a well liked guy and he was very rude to the Egyptian natives, especially towards the Bedouins.

Re: A Facebook engineer abused access to user data to track down woman

#59
post #15

I worked at Facebook for most of 2017 and 2018. In the first week, they made it clear that you would be fired instantly for any improper access of user data. They further said that if you need to access any sensitive personal data, or if you need to log in as a user in order to debug a problem, you need to have approval from your manager _before_ the access, not after. Also, you are not allowed to access the data of…

They had this rule at America Online when I worked there early 2000s. It was routinely violated by the managers, and was really only in place for the rank and file to cover their butts. I just assume bad management and executives of Facebook routinely violate peoples privacy by digging through their information, it’s there, and Facebook hasn’t exactly shown an interest in protecting privacy.

The big problem with a company as large as Facebook, is it's easy for the reality on the ground and the statements executives make to differ greatly: The company policy may be as stated, but there may be line employees and managers who have no issue with abuse of personal data, and even cover for each other.

The idea that people can just go in and access personal data at Facebook without some sort of actual pre-authorization is insane.

Re: A Facebook engineer abused access to user data to track down woman

#60
post #9

Earlier quoted context omitted.

Is it not possible to only have the hashes or does it have to get persisted somewhere in the process?

Usually it's in the logs. So small number of SREs can sometimes access them (if there are logged). And even if they are not logged, they can always show up during tcpdump debugging of network issues and such. Client side hashing could solve this, but almost no one does it.

> Usually it's in the logs.

That is definitely not usual

Post reply on HN