4 ms·

To the (intentionally?) obtuse responses: intending to store passwords in plaintext usually means storing plaintext passwords in databases and doing authenticat

by oefrha 2y ago

To the (intentionally?) obtuse responses: intending to store passwords in plaintext usually means storing plaintext passwords in databases and doing authentication with that; and that’s what the gazillion of commenters replying to the title are implying. Mistakenly logging credentials because of e.g. badly interacting HTTP middleware is still a very nasty bug, but it doesn’t count as intending to store passwords in plaintext. And something similar has happened to me, and I’m sure many others: logging middleware storing sensitive user data that shouldn’t be visible to engineers with mere access to logs (not as bad as logging credentials in my case, but still).

nomilk 2y ago
hmm.. that's a very sympathetic take. Most frameworks blot out passwords from logs by default, so even a newbie programmer on their first day doesn't make the mistake of logging plaintext passwords, yet facebook somehow made that mistake... It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project.
- yunohn 2y ago
  I think it’s actually much easier to make such mistakes at large companies with sprawling codebases and potential for settings that inadvertently end up logging sensitive data. Especially for nobody to notice either.
  - nomilk 2y ago
    True but they're also better resourced in terms of humans (and their experience) and tooling that should prevent or at least catch any blunders quickly.
    - yunohn 2y ago
      You’d be surprised, but from my first hand FAANG experience that is definitely not the case. Tooling can capture things that are known to it - but not everything is setup perfectly.
- mulmen 2y ago
  > It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project. Facebook isn’t “a billion dollar” company it’s “a 1,435 billion dollar” company. Excuses start to run thin.
- vidarh 2y ago
  Passwords are just data. If said data is not tagged in a way that makes it clear it is a password, finding an algorithm that will successfully blot out passwords in the general case is intractable without being far too aggressive to be useful. All such tools rely on assumptions about what will be logged following certain rules that the logging can check against - it's not hard to accidentally convert data to a format that when logged happens to fail these kinds of tests. They should have caught it. But it's not surprising that it occasionally happens.
  - tjoff 2y ago
    HN does it, if I post my password it will automatically change it to stars, see: *************
    - benmmurphy 2y ago
      hunter2
    - yakshaving_jgt 2y ago
      correct-horse-battery-staple Hmm… Not sure if it worked?
  - nomilk 2y ago
    Not that hard [1]: Rails.application.config.filter_parameters += [ :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn, :cvv, :cvc ] [1] https://github.com/rails/rails/blob/8a2e28d7451d5ae4cb194fccc125a6b9554bb38b/railties/lib/rails/generators/rails/app/templates/config/initializers/filter_parameter_logging.rb.tt#L6-L8 https://github.com/rails/rails/blob/8a2e28d7451d5ae4cb194fcc...
    - vidarh 2y ago
      Assuming, of course, that the data is logged as a parameter rather than as a raw string, or as an instance variable in another object, or any number of other ways. Developers thinking it is "not that hard" is a big red flag to me, suggesting odds are high your logs are full of things that should not be there. Using filters is a first step only.
nicolas_t 2y ago
According to the pci dss auditor I had when doing a pci das level 1 audit. The most common credit card leak vector is logging middlewares logging credit card nunbers
slim 2y ago
unless you are Facebook and tightly collaborating with police and intelligence in countries with no respect for human rights
Mountain_Skies 2y ago
When I did application security I had to argue with developers about PCI and PII data in logs all the time. They would insist that there was "no other way" and that it was secure inside our system. I'd refuse to change the status of the vuln to anything other than critical. I found many similar vulns in our database that had been marked as false positives or non-critical by other infosec people in the company. The common thread was none of them had a background in software development so they just trusted what the developer told them. This seems to happen frequently in places where there's a culture of compliance being more important than actual security.
miningape 2y ago
Can confirm, have broken GDPR before through logging customer (and customer's customer) PII. It lasted for about a month before we realised and I had to go through the logs 1 by 1 over 3 days to remove all the data.
- dangsux 2y ago
  [dead]

by oefrha 2y ago

nomilk 2y ago

hmm.. that's a very sympathetic take. Most frameworks blot out passwords from logs by default, so even a newbie programmer on their first day doesn't make the mistake of logging plaintext passwords, yet facebook somehow made that mistake... It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project.

yunohn 2y ago
I think it’s actually much easier to make such mistakes at large companies with sprawling codebases and potential for settings that inadvertently end up logging sensitive data. Especially for nobody to notice either.
- nomilk 2y ago
  True but they're also better resourced in terms of humans (and their experience) and tooling that should prevent or at least catch any blunders quickly.
  - yunohn 2y ago
    You’d be surprised, but from my first hand FAANG experience that is definitely not the case. Tooling can capture things that are known to it - but not everything is setup perfectly.
mulmen 2y ago
> It should raise eyebrows when the security practices of SWEs at a billion dollar company are outperformed by any newbie developer working a toy project. Facebook isn’t “a billion dollar” company it’s “a 1,435 billion dollar” company. Excuses start to run thin.
vidarh 2y ago
Passwords are just data. If said data is not tagged in a way that makes it clear it is a password, finding an algorithm that will successfully blot out passwords in the general case is intractable without being far too aggressive to be useful. All such tools rely on assumptions about what will be logged following certain rules that the logging can check against - it's not hard to accidentally convert data to a format that when logged happens to fail these kinds of tests. They should have caught it. But it's not surprising that it occasionally happens.
- tjoff 2y ago
  HN does it, if I post my password it will automatically change it to stars, see: *************
  - benmmurphy 2y ago
    hunter2
  - yakshaving_jgt 2y ago
    correct-horse-battery-staple Hmm… Not sure if it worked?
- nomilk 2y ago
  Not that hard [1]: Rails.application.config.filter_parameters += [ :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn, :cvv, :cvc ] [1] https://github.com/rails/rails/blob/8a2e28d7451d5ae4cb194fccc125a6b9554bb38b/railties/lib/rails/generators/rails/app/templates/config/initializers/filter_parameter_logging.rb.tt#L6-L8 https://github.com/rails/rails/blob/8a2e28d7451d5ae4cb194fcc...
  - vidarh 2y ago
    Assuming, of course, that the data is logged as a parameter rather than as a raw string, or as an instance variable in another object, or any number of other ways. Developers thinking it is "not that hard" is a big red flag to me, suggesting odds are high your logs are full of things that should not be there. Using filters is a first step only.

nicolas_t 2y ago

According to the pci dss auditor I had when doing a pci das level 1 audit. The most common credit card leak vector is logging middlewares logging credit card nunbers

slim 2y ago

unless you are Facebook and tightly collaborating with police and intelligence in countries with no respect for human rights

Mountain_Skies 2y ago

When I did application security I had to argue with developers about PCI and PII data in logs all the time. They would insist that there was "no other way" and that it was secure inside our system. I'd refuse to change the status of the vuln to anything other than critical. I found many similar vulns in our database that had been marked as false positives or non-critical by other infosec people in the company. The common thread was none of them had a background in software development so they just trusted what the developer told them. This seems to happen frequently in places where there's a culture of compliance being more important than actual security.

miningape 2y ago

Can confirm, have broken GDPR before through logging customer (and customer's customer) PII. It lasted for about a month before we realised and I had to go through the logs 1 by 1 over 3 days to remove all the data.

dangsux 2y ago
[dead]