Secrets

Yesterday, I made a mistake that’s unfixable. I committed a database password to a public code repository.

Granted, it was a password to a local database — one that can only run on “localhost” (i.e. the computer you’re working on). And it was for a small project that my manager Justin Rodenbostel is using to teach his students. And, even though it was trivial, I changed the password on my local database out of habit and sheepishness. And, of course, I made a follow-up commit, deleting the password.

None of this obviates the problem that the mistake is irremediable. You can still find the password by trawling through the code repository.

Should I just delete the code repo? Or at least try to rewrite the commit history — fraught with problems as that is? I could. However, even if I did all that, there is no guarantee that in the time that password existed in the wild that someone didn’t clone the repo. There can never be any such guarantee.

Committing a password to a code repository is one of those mistakes that cannot be undone. That’s why it’s important to take steps to both avoid it and quickly remedy it when it happens.

Prevention:

1. Use pre-commit warning tools (like git-secrets)
2. Use an encrypted secrets-repository (like Vault)
3. Program with another person
4. Encourage and teach people in your organization to use password managers to reduce the likelihood of low-entropy passwords.

Remediation

1. Have a swift and smooth password expiration and rotation policy that is backed by actual tooling and practices.
2. Exercise your password expiration process often. Ideally, you should do it every time someone with access to secrets leaves the team or company.
3. Treat all leaked passwords as immediately and irrevocably compromised. Do not waste time justifying to yourself or others that the problem isn’t severe; solve it.

As Ben Franklin said in a morbid quote, secrets have a habit of leaking out. Protect yourselves and your data from the consequences.