Securely storing secrets in hosted source control

Question

Our company has recently adopted private repositories hosted by BitBucket over a local source control system. In addition to source code, each repositories have all necessary components to build, configure, and deploy (scripts, etc). This works well in most regards, but I'm torn on what to do with sensitive passwords, ftp configurations, etc that would normally accompany my build and deploy scripts.

See this similar post outlining the concerns.

In my case, the xml configurations are representative of the code that is used to parse them, so they need to be versioned (schema's anyway).

Clearly, storing secrets on anything other than something local increases your risks, but what are the alternatives? Store them encrypted? Use fancy config section replacements during build, feeding config values in from external system?

Answer 1

Git

Smudge/Clean filters for bidirectional KEYWORD<->CODE replacement

Mercurial

MQ-patch (local), which restore sensitive data in local Working Dir, missing in pushed and published repo

Answer 2

You could locally store a configuration file with the sensitive data. You should sign this file, which contains a private or secret key. The public key to verify the signature should be stored within the code. Now you store the versioned configuration encrypted within the source repository. The encrypted config can only be read if the application finds the signed decryption key at a specified place. If it cannot find them it falls back to plain defaults for testing. Don't forget to add logging which config you are using if you add this additional trick. You might want to sign or perform a MAC calculation over the configuration files as well.

How much security this delivers depends on the rest of the system, but you can keep relatively static data locally and still put the configuration data within the versioning system. Note that many versioning systems like text, so you might want to base64 encode the encrypted configuration files, just to be sure.

This is just one of many schemes of course.