Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the technical security problem here (properly whitelisting parameters in logs) is just a symptom and not the core underlying concern (as the article mentions Twitter and Github just dealt with similar issues)

To me, it seems very likely someone before 2019 laid eyes on these logs and either:

  a) Decided not to report it (implies serious security culture issue)
 
  b) Reported it and no action was taken (implies serious security process issue)

  c) Didn't even acknowledge it was inappropriate (implies a serious security training failure)
If you've already become complicit towards regularly violating the privacy of your end-users, one can easily understand an employee devaluing the seriousness of clear-text passwords in a log.

Are FB employees so regularly exposed to sensitive data that they have become desensitized to the seriousness of clear-text passwords in an internally accessible log?



This is very basic stuff, all user-identifying information should be tokenized before being logged. Controlling access to production login logs or exposing them on only a need to know basis is another basic security principle. Sounds like FB is actually a wild wild west internally.


What is now a common practice was nonexistent a few years ago. 20 years ago you could bypass Windows login with a few clicks. 15 years ago CORS was nonexistent. 15 years ago it was common to send sensitive data unencrypted..and so on.

Ex Facebook people told me that until around 2010 FB management turned a blind eye on its employees digging around their databases. Then they released a warning that people should stop and started locking prod data down. A few months later those who still peeked around prod data were let go.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: