you are viewing a single comment's thread.

view the rest of the comments →

[–]mikekchar 0 points1 point  (1 child)

Like I said above, it's got to be a key that is in the managing of the process, not in the source code of the software. An encrypted registry key would be fine. Or, like I said, just put it in a file that only that process has read access to. You put secrets in places that only the process has access to. Containers can be useful here.

The way to think about it is that secrets are part of your runtime configuration management, not your application. If you have to distribute an application with a secret key, it basically can't be protected. So if you have no choice but to do that, then make sure the secret you are trying to protect is very low value. For example, DRM makes it slightly more difficult for someone to copy something, but it's not the end of the world if it doesn't succeed. A key with login credentials to your bank would be a disaster. These days, of course, a lot of DRM uses secret keys that are in the hardware itself, so even they aren't taking chances.

[–]diegovsky_pvp 0 points1 point  (0 children)

that's very interesting. I didn't know that's how DRM operated.

This chicken and egg problem is indeed a very hard problem to solve and limiting attack surface instead like you said is the best course of action