Handling passwords in production config for automated deployment

Question

I have seen related questions here, but they don't seem to be answering exactly what I need.

We use Powershell scripts to deploy our applications and the info like passwords in configuration files for most of the environments ( UATs etc. ) are in plain text. It is not a big issue, but when it comes to PREPROD and PROD, it is a big issue. So we had some markers in the config like "{{prompt-password}}" which will give a login dialog (Get-Credential) and the person doing the deployment can enter the credential and the deployment continues.

But this doesn't really help for automated deployment ( meaning one-click deploy through tools like TeamCity )

Should I go for Asymmetric encryption ( http://msdn.microsoft.com/en-us/library/as0w18af.aspx ) where the password is encrypted using a public key, entered in the config, and private key is stored (as described here http://msdn.microsoft.com/en-us/library/tswxhw92.aspx ) in the "agent" ( as in a VM from where TeamCity will trigger the deployment and which has restricted access ) running the automated deployment and it can decrypt the password? Not really strong on Cryptography and stuff, but does this sound like the way to go? Any other suggestions? How do people handle such automated deployment?

---

Update:

Ok, I have gone ahead and implemented it. I have written a Console Application in C# which uses the Crypography libraries. The app generates the keys:

RSACryptoServiceProvider rsa = GetRsa(containerName);
File.WriteAllText("keys.kez",rsa.ToXmlString(true));

I also get out the public key:

File.WriteAllText("public.pke", rsa.ToXmlString(false));

Give the public key to anyone who has to encrypt the password and ask them to enter the password in the config. Put the keys.kez file in any agent that has to run the deployment.

Answer 1

Asymmetric encryption is definitely the winner here from a security and simplicity standpoint. I have deployed production SaaS apps in this manner very successfully.

There are a few tricks. One, as you mentioned, make sure the public/private key pair is installed on the host, not stored in config files or in the code. Two, assume the management and key generation tools provided by MS are weak to terrible and plan accordingly (we created a simple keygen exe for Operations to run during deploy.)