5 ms·

The usual way this happens is accidentally logging passwords. Or even other cases where passwords happen to be included in something else. It can happen more ea

The usual way this happens is accidentally logging passwords. Or even other cases where passwords happen to be included in something else. It can happen more easily than you think. Like for example, if you collect server side crash dumps, are you really taking care that there is no sensitive information sitting in the memory image stored in them?

grayhatter 2y ago
the word you should use is carelessly, as in carelessly logging passwords. When working with data that you can reasonably expect to contain secrets, you should behave as if it does contain secrets. It worries me that you mention you're aware that server side crash dumps may contain sensitive data, but you also speak as if it's reasonable to not protect them knowing they do, or they might. I'd hope or expect anyone would mention or at least imply that it'd be negligent to behave so recklessly with someone else's secrets.
- bongodongobob 2y ago
  What you're saying makes sense for a small startup with 20 people. Have you worked in an org of 10000+ that's been around for 30 years? Where the people who built the systems no longer work there? Where the people who maintain them are 3+ career cycles removed? Things get so baked in "one doesn't simply make changes" because no one person understands how everything works, so you do your best and keep closing tickets. "Hey we should really investigate whether or not passwords are included in memory in our 2000 severs across the globe!" "Lol ok maybe when you close out the 30 tickets on your plate."
  - grayhatter 2y ago
    > Have you worked in an org of 10000+ that's been around for 30 years? yes. Would you still make this argument for something else known to be dangerous? Hey this gigantic lathe doesn't have a safety shut off switch. Ahh yeah the guy that did the wiring for that left years ago so we just don't touch it. It's fine as long as no one puts their hands near it when it's running. Hey, isn't this freshly dug 20 foot hole supposed to have an escape route, and side wall reinforcements so it doesn't collapse on someone? lol ok new guy, let me know when you've finished pouring that concrete and then we'll look at that idea. To go back to the example; Taking steps to protect them could be as simple as restricting who can access core dumps, enforcing they don't get stored unencrypted, and the only people who can copy and inspect them have are already in a trusted role where they can get root on that production server. Or an even better option would be restricting the service that can read clear text passwords. These machines don't crash, and when they do, we don't write a coredump. (but this trusted team can start if we see the system crashing suddenly) > Things get so baked in "one doesn't simply make changes" because no one person understands how everything works, so you do your best and keep closing tickets. This is a super disappointing attitude. It's hard, and it's the way we've always done it, so that means it's impossible, or not worth the effort? Yeah, I'm not likely to buy into that mentality. I believe I can fix things and have a positive impact. It's one thing to say it's impossible because you don't understand how to do it, that's wrong, but I guess if that's what you need to believe to sleep at night, I can pretend to understand. It's another thing entirely if you don't have the autonomy at work to try to improve something you know to be broken, and a risk to users, and the company. If that's actually what you meant to describe, you might wanna consider if you can find another job. You're clearly not an idiot, and there's plenty of companies that wont treat you like a code monkey.

grayhatter 2y ago

the word you should use is carelessly, as in carelessly logging passwords. When working with data that you can reasonably expect to contain secrets, you should behave as if it does contain secrets. It worries me that you mention you're aware that server side crash dumps may contain sensitive data, but you also speak as if it's reasonable to not protect them knowing they do, or they might. I'd hope or expect anyone would mention or at least imply that it'd be negligent to behave so recklessly with someone else's secrets.

bongodongobob 2y ago
What you're saying makes sense for a small startup with 20 people. Have you worked in an org of 10000+ that's been around for 30 years? Where the people who built the systems no longer work there? Where the people who maintain them are 3+ career cycles removed? Things get so baked in "one doesn't simply make changes" because no one person understands how everything works, so you do your best and keep closing tickets. "Hey we should really investigate whether or not passwords are included in memory in our 2000 severs across the globe!" "Lol ok maybe when you close out the 30 tickets on your plate."
- grayhatter 2y ago
  > Have you worked in an org of 10000+ that's been around for 30 years? yes. Would you still make this argument for something else known to be dangerous? Hey this gigantic lathe doesn't have a safety shut off switch. Ahh yeah the guy that did the wiring for that left years ago so we just don't touch it. It's fine as long as no one puts their hands near it when it's running. Hey, isn't this freshly dug 20 foot hole supposed to have an escape route, and side wall reinforcements so it doesn't collapse on someone? lol ok new guy, let me know when you've finished pouring that concrete and then we'll look at that idea. To go back to the example; Taking steps to protect them could be as simple as restricting who can access core dumps, enforcing they don't get stored unencrypted, and the only people who can copy and inspect them have are already in a trusted role where they can get root on that production server. Or an even better option would be restricting the service that can read clear text passwords. These machines don't crash, and when they do, we don't write a coredump. (but this trusted team can start if we see the system crashing suddenly) > Things get so baked in "one doesn't simply make changes" because no one person understands how everything works, so you do your best and keep closing tickets. This is a super disappointing attitude. It's hard, and it's the way we've always done it, so that means it's impossible, or not worth the effort? Yeah, I'm not likely to buy into that mentality. I believe I can fix things and have a positive impact. It's one thing to say it's impossible because you don't understand how to do it, that's wrong, but I guess if that's what you need to believe to sleep at night, I can pretend to understand. It's another thing entirely if you don't have the autonomy at work to try to improve something you know to be broken, and a risk to users, and the company. If that's actually what you meant to describe, you might wanna consider if you can find another job. You're clearly not an idiot, and there's plenty of companies that wont treat you like a code monkey.