Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I feel like whenever possible, the answer is to stop storing sensitive information in source control. That solves a whole class of problems, including this one.

If your history has sensitive info, see about rewriting the history. If that's not possible, maybe fork the repo, remove the sensitive info, and get the team to switch to the fork. If that's not possible either, make the sensitive info meaningless (reset your DB passwork, revoke the API tokens, etc).



Source Code is the sensitive information that he's talking about in the article.


If you've got a static site hostable in htdocs directly, then that "sensitive source code" is also accessible in browser dev tools and View Source menus.


You're correct that secrets shouldn't be stored in source control, but it's a problem from management's perspective:

a) how do you search a repository's history, along all branches (including undeployed development branches, which may nonetheless contain production secrets) to find secrets mistakenly stored in version control? b) what happens when somebody stores a secret which isn't easily rotated (because legacy systems have hard-coded the secrets etc.)? How do you deal with trying to rotate secrets which aren't well-managed, because the real problem isn't that your teams are storing secrets in source control but that you don't have proper secret management set up across your organization?

The simpler (and more correct!) way to deal with this is to stop using version control for deployments and to start using proper package management and deployment tooling. Version control is not designed as a deployment tool; it is a poor replacement for proper deployment tooling; and teams which think they only have hammers to hit what are not nails but screws, need to learn that sometimes they'll have to go out and get a set of screwdrivers too.


Even without passwords, just knowing the infrastructure of the target system is candy for a hacker.


This is really true only if you're ascribing to the perimeter model of security rather than defense-in-depth, though. If your systems are (properly, to my mind) constructed, knowing what your infrastructure looks like doesn't provide significant value. That obscurity becomes a nice-to-have, rather than an essential, aspect of your security.

(When building systems for clients, this is something I stress. "We should be operating as if it is assumed that an attacker has a VPN into your network space and has nmapped all your stuff.")


Counterpoint: Knowledge of the infrastructure can be used in social engineering attacks, e.g. to increase the likelihood of success for password spearphishing.


If people with access to your infrastructure can be spearphished for passwords, I would venture to say that you're probably doing other stuff wrong that needs to be fixed first.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: