Explicitly logging a password is one of those practices that doesn't sit on the backlog.
It's probably a bit more complicated than that. Usually the things that I encounter have to do with how HTTP requests are logged.
For example, putting sensitive information in a URL that's loaded over HTTPS is considered insecure because many companies have policies where they log every URL that their employees visit. (Think of a password reset link.)
A lot of inexperienced programmers don't realize this, because they don't realize that you can man-in-the-middle yourself, and that most corporate computers come preconfigured to allow the employer to man-in-the-middle everyone.
So, if a password reset link never expires, it means that some guy in IT can own an account that was reset on a corporate computer.
(This, basically, is how they catch people viewing porn on their work computers.)
Anyway, my point is that the problem is probably something where a junior programmer transmitted a password in a way that they didn't realize was being logged.
> Explicitly logging a password is one of those practices that doesn't sit on the backlog.
If that is your experience, then that's a truly wonderful thing.
Might it be possible that at many companies, teams with deadlines to hit will tend to prioritize feature work over details like this? Perhaps especially so when teams are not rewarded for fixing vulnerabilities and are punished for not meeting deadlines? Particularly when the actual bug at hand is that the full contents of a POST are being logged, and a PM might not read the ticket enough to understand that this includes a password...
Again, you're completely right in every way about what should happen. It just could be possible that this could reflect something other than all experiences all software engineers have had.
What evidence do you have for that? Nowhere in the article does it say facebook "explicity logged" passwords. The logging likely happened through some unintended and roundabout process that is far from explicit.
How many times does a company of Facebook's size get to say "oopsie, we're sorry" before you'll stop giving them to benefit of the doubt? I see this as a malicious disregard for the security and privacy of their users, and their history aligns with that view.
It's probably a bit more complicated than that. Usually the things that I encounter have to do with how HTTP requests are logged.
For example, putting sensitive information in a URL that's loaded over HTTPS is considered insecure because many companies have policies where they log every URL that their employees visit. (Think of a password reset link.)
A lot of inexperienced programmers don't realize this, because they don't realize that you can man-in-the-middle yourself, and that most corporate computers come preconfigured to allow the employer to man-in-the-middle everyone.
So, if a password reset link never expires, it means that some guy in IT can own an account that was reset on a corporate computer.
(This, basically, is how they catch people viewing porn on their work computers.)
Anyway, my point is that the problem is probably something where a junior programmer transmitted a password in a way that they didn't realize was being logged.