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…
A Facebook engineer abused access to user data to track down woman
41–50 of 108 posts
Re: A Facebook engineer abused access to user data to track down woman
#42> 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.
Re: A Facebook engineer abused access to user data to track down woman
#43I 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…
We should not rely on the goodwill or internal guidelines of a single company in such a sensitive topic.
Re: A Facebook engineer abused access to user data to track down woman
#44Earlier quoted context omitted.
Only the hashed versions should ever be stored. Like the OP said there is Zero reason to store plaintext user passwords.
IMO, it's likely that the article was confusing "passwords" with "hashes" here. No company the size of Facebook is going to be storing plain-text passwords in 2021.
We've seen stories where the servers were logging the plain text data it received where those logs persisted for some time, but the plain text was never "stored" in the database.
Re: A Facebook engineer abused access to user data to track down woman
#45I 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…
A friend of mine worked at a large bank in customer service and this was also a big part of their training, and there was even a speech trainees were given before going to their desk at the end of training. He said, almost invariably, that at least one person from every class was fired within hours for looking up the accounts of someone they knew or a celebrity.
Re: A Facebook engineer abused access to user data to track down woman
#46Earlier quoted context omitted.
Is it not possible to only have the hashes or does it have to get persisted somewhere in the process?
Only the hashed versions should ever be stored. Like the OP said there is Zero reason to store plaintext user passwords.
Re: A Facebook engineer abused access to user data to track down woman
#47> 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)
Re: A Facebook engineer abused access to user data to track down woman
#48I 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…
Which explicitly also includes yourself, because looking yourself up would e.g. let you see who has you blocked.
You're also fairly unlikely to access personal data by accident. You have to explictly go look for it in the internal tooling, which has pretty good signage around interfaces that could potentially expose you to personal data by accident so you know to be careful (I did a couple of tickets for the abuse team and testing that stuff was riddled with interstitials asking if I was sure I wanted to access personal data). "Oops I didn't notice" just doesn't fly.
They're also fairly good at removing the semi-legitimate reasons you'd have for accessing personal data. If you have friends or family that are having some sort of issue, they have a separate priority queue you can submit requests to so they'll look into those issues for you, for example. If you need test data, there's great tools to generate test users with all sorts of weird configurations (so you don't have to rely on finding a live one that meets your criteria)
Re: A Facebook engineer abused access to user data to track down woman
#49Ideally, your data should be encrypted and no one at Facebook should not have access to it. Only those people whom you have chosen to then share that data should have access to the degree given (crypto wise, maybe this means you decrypt and broadcast to those people like email). Any reason why a Proton-like model wouldn't work for technical reasons? Facebook could still make money off ads, but those ads would be less targeted. Good. We need less targeting.
Re: A Facebook engineer abused access to user data to track down woman
#50I 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…
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…
(Messenger had stronger protections than OP is describing)