Securing application configuration, while still getting shit done | Hacker News Reader

Securing application configuration, while still getting shit done

blog.rainforestqa.com

22 pointsukd120 comments

have you seen the git smudge and clean filters? they provide a way to perform scripts like this automatically on commit and checkout.

No, but that sounds awesome! Just looking for examples :)

Check out the email from Michael J Gruber on the git mailing list: http://git.661346.n2.nabble.com/Transparently-encrypt-reposi...

There's a fairly complete example there, plus discussion. (It's worth mentioning that many of the git maintainers find this to be an odd use of the git filters feature, because it doesn't let you diff things. But of course, that's not the point.)

The first example there uses gpg, which is a very sub-optimal approach because gpg uses non-deterministic encryption. That means that git always thinks the file has changed, because every invocation of the filter produces a different output.

A later example tries to fix this by using deterministic encryption with openssl instead of gpg, but it's insecure because it accomplishes the determinism by using either ECB mode or CBC mode with a fixed IV.

The proper solution is to use a real deterministic encryption scheme (such as CTR mode with the nonce derived from a HMAC of the plaintext), and also use a diff filter so git diffs work. Not only does git work properly, it's actually secure too! My project, git-crypt[1], works this way.

[1] https://www.agwa.name/projects/git-crypt/

GPG is fine, if you don't decrypt and then encrypt unless you're doing an update. So, why would it matter?

If you're using GPG manually, as described in your article, then it's fine, but when you're using git filters you have no control over when encryption/decryption takes place and when it doesn't. Whenever a file is checked out from the index to the working tree, git invokes the the smudge filter, and whenever git needs to check if the file in the working tree has changed (as from `git status`), it invokes the clean filter, even if you haven't actually changed the file in the working tree[1]. If the results from the clean filter are different from what's in the index, git thinks the file has changed. That means the clean filter had better produce the same output if the working tree version hasn't actually changed. GPG doesn't satisfy that requirement.

[1] newer versions of git do some caching here, so the clean filter might not always be invoked, but it's still invoked often enough to cause problems

I'll put in a plug for my project, git-crypt, which implements transparent file encryption in git using smudge/clean filters:

https://www.agwa.name/projects/git-crypt/

Be careful with some of the other git encryption projects out there - most of them get the cryptography wrong, by using either ECB mode or CBC mode with a fixed IV.

This looks cool, the only thing I don't like is that it uses (from what I understand) a single key, not one per developer. Is that planned at all?

Yes, it is planned. I have most of the design figured out and just need to work out a few issues with revoking a developer's access. You're the first person to ask specifically about this feature, which is good motivation to take it off the back burner :-).

In the meantime, you can accomplish this by storing the git-crypt key in the repository, but encrypted using GPG with multiple recipients (much like your approach). Then you wrap `git-crypt init` in a script that first decrypts the key using GPG before feeding it to `git-crypt init`. To add a new developer, you just re-encrypt the git-crypt key with an additional recipient.

I don't entirely understand this:

> We add the sensitive environments to .gitignore; for us this is production.txt, qa.txt and staging.txt. These are never committed.

> We get a history of changes in git (though it’s way more of a pain to use as you have to decrypt different versions)

So you have a history of changes, but only for the dev environment? Seems like that wouldn't be terribly useful, but maybe I'm missing something.

We have the history of changes, but not diff-able. private/env/production.txt is not in git, however private/env/production.txt.asc is. It would be a pain to go through the diffs, but possible. Our production config has only been updated 35 times (this includes non-config updates like adding new keys).

We do this as well. I'd recommend setting it up for all new projects as quickly as possible to avoid having sensitive configurations in your repository history.

For my personal projects, it enables me to host my projects on public github repos, including configuration files, which was traditionally a pain point.

In our framework we simply have a "local" subdirectory in each app which is not checked into version control. There, we keep local environment config including db credentials, facebook app and other api credentials, local pathnames etc.

Solved.

This doesn't meet the principle of least privilege; developers don't need production access, do they?

How do you know? You seem to be attacking a straw man. The developers dont need to have production access.

I saw an interesting approach to this described in a blog comment a while back. I've been pondering it ever since: http://ejohn.org/blog/keeping-passwords-in-source-control/#c...

edit: looks like the #comment anchor doesn't expand the comment section automatically. Search for the comment by "ntnt"

Interesting, resig's approach doesn't work with continuous deployment, unless you want to decrypt stuff each build (which would be less secure). Ntnt's solution sounds awesome but imho over kill - a whole extra server?

Personally, I'd happily deploy an extra server or two (redundancy) to keep from having credentials laying around unencrypted on production machines.

This is dumb. If they need a secret, they request them using another key. Therefore they have access to all the secrets they would have needed anyway. What does this gain? It adds a ton of complexity and a major failure point.

The interesting part to me is leveraging the ssh agent. Yes, the secrets are all behind yet another key, but it happens to be a key that doesn't leave your local machine even when it's being used to get access to a remote secret, plus it's a key that you likely already have set up (and hopefully secured) for ssh access.

Reply on news.ycombinator.com