Keeping Secrets Out of Logs
tl;dr: There's no silver bullet, but if we put some "lead" bullets in the right places, we have a good shot at keeping sensitive data out of logs.
"This is the blog version of a talk I gave at LocoMocoSec 2024. It’s mostly a lightly edited transcript with some screenshots, so if you’d prefer, you can watch the "This is the blog version of a talk I gave at LocoMocoSec 2024. It’s mostly a lightly edited transcript with some screenshots, so if you’d prefer, you can watch the video or just flip through the slides ."
This post is about how to keep secrets out of logs, and my claim is that (like many things in security) there isn’t a singular action or silver bullet that lets you do this. I would go so far as to say that there’s not even an 80/20 rule, where one action fixes 80% of the problem. It’s not like preventing SQL injection with prepared statements or preventing buffer overflows by using memory-safe languages.
What I will offer instead, are lead bullets, of which there are many. I’m going to talk about 10 of them. They are imperfect and sometimes unreliable things that, if put in the right places and with defense-in-depth, can still give us a real good chance at succeeding. My hope is that by the end, you’ll have a slightly better framework for how to reason about this problem and some new ideas to add to your kit.
Table of contents:
The Problem
With that, let’s dive in and set the table by talking about the problem with secrets in logs.
So, there are some problems that are annoying. And there are some problems that are difficult.
This is both. I’m gonna level with you: I absolutely hate this problem. But I’m not going to gaslight you and tell you that this is the most important thing to work on worry about, because it probably isn’t!
... continue reading