3 ms·

You're right, the impact is just as bad. I think people in this thread (including myself) are downplaying it because it's a very easy mistake to make, rather th

You're right, the impact is just as bad. I think people in this thread (including myself) are downplaying it because it's a very easy mistake to make, rather than a terrible design decision.

newaccoutnas 8y ago
A mistake that should have been found very quickly, given the eyes. Not for years without ever apparently being known (I find that hard to believe)
staticassertion 8y ago
The major difference is that we don't have standard patterns for protecting against one attack, vs the other. With password storage everyone knows the patterns, or we expect them to. With everything between the request and password storage, we don't. This type of attack could easily be prevented. When secrets come in, immediately store them (ideally at the web framework level) in a type that overrides print/debug formatting. Then add a "get_raw" to it, and you can now grep for that being used anywhere outside of storage to a DB (and your DB libs should take the Secret type too). Or don't use a `get_raw` and instead use a `hash` method that returns a safely hashed version of it. Further, your secret type could at the very least add a round of SHA256, maybe even with a pepper?, just to be sure. This isn't hard, I've done it before. The problem is that it isn't something that people feel embarrassed not to do, vs storing plaintext creds. Impact is the same - creds are plaintext in a DB. Attackers always expect sensitive data in logs, so it isn't as if you'd get lucky and they'd miss this.
- deleted 8y ago
  [deleted]
- aeorgnoieang 8y ago
  > When secrets come in, immediately store them (ideally at the web framework level) ... But, in practice, a lot of this stuff is being logged by things like proxies that could be several layers in front of the "web framework level".
  - staticassertion 8y ago
    Do proxies usually log POST data? Are these proxies terminating TLS? Either way, yeah, you're right - it is not a perfect solution. But it means that for any system your engineers build, so long as they build them using your web framework that imposes this password type, you can grep your codebase for bugs. You could implement client side hashing as a best-effort "in transit" mechanism but that has obvious downsides. Not sure how I'd feel about that approach in practice, but I can't see a big downside.
EpicEng 8y ago
When you're FB, Google, ADP, a bank, whatever, you have failed if this sort of thing is "an easy mistake to make." Responsibility should never fall on a single dev or team to begin with. This was going on for _years_. It's either ametuer hour over there or the organization simply doesn't care enough to invest heavily in the protection of their users.

You're right, the impact is just as bad. I think people in this thread (including myself) are downplaying it because it's a very easy mistake to make, rather than a terrible design decision.

newaccoutnas 8y ago

A mistake that should have been found very quickly, given the eyes. Not for years without ever apparently being known (I find that hard to believe)

staticassertion 8y ago

The major difference is that we don't have standard patterns for protecting against one attack, vs the other. With password storage everyone knows the patterns, or we expect them to. With everything between the request and password storage, we don't. This type of attack could easily be prevented. When secrets come in, immediately store them (ideally at the web framework level) in a type that overrides print/debug formatting. Then add a "get_raw" to it, and you can now grep for that being used anywhere outside of storage to a DB (and your DB libs should take the Secret type too). Or don't use a `get_raw` and instead use a `hash` method that returns a safely hashed version of it. Further, your secret type could at the very least add a round of SHA256, maybe even with a pepper?, just to be sure. This isn't hard, I've done it before. The problem is that it isn't something that people feel embarrassed not to do, vs storing plaintext creds. Impact is the same - creds are plaintext in a DB. Attackers always expect sensitive data in logs, so it isn't as if you'd get lucky and they'd miss this.

deleted 8y ago
[deleted]
aeorgnoieang 8y ago
> When secrets come in, immediately store them (ideally at the web framework level) ... But, in practice, a lot of this stuff is being logged by things like proxies that could be several layers in front of the "web framework level".
- staticassertion 8y ago
  Do proxies usually log POST data? Are these proxies terminating TLS? Either way, yeah, you're right - it is not a perfect solution. But it means that for any system your engineers build, so long as they build them using your web framework that imposes this password type, you can grep your codebase for bugs. You could implement client side hashing as a best-effort "in transit" mechanism but that has obvious downsides. Not sure how I'd feel about that approach in practice, but I can't see a big downside.

EpicEng 8y ago

When you're FB, Google, ADP, a bank, whatever, you have failed if this sort of thing is "an easy mistake to make." Responsibility should never fall on a single dev or team to begin with. This was going on for _years_. It's either ametuer hour over there or the organization simply doesn't care enough to invest heavily in the protection of their users.