Handling passwords in production config for automated deployment

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.)

Not really an answer, but a suggestion or an other question.

Why don't tou store the password in a crypted string in a config file

$credential.Password | ConvertFrom-SecureString | Set-Content c:\temp\password.txt

As far as I understand the documentation a process running with the same credential can get it back

$password = Get-Content c:\temp\password.txt | ConvertTo-SecureString$credential = New-Object System.Management.Automation.PsCredential `         "username",$password

You can replace $credential.Password by read-host -assecurestring

As you said in your question, your password are kept in PROD in config file in plain text. No amount of encryption can help with that. Also, this is kind of a vicious cycle - how are you going to protect encryption key?

The key think here is to look at what is practical, and what kind of business workflows your organization follows when it comes to deployments.

Let me explain this on an example. Let's assume that the deployment to PROD is executed by an infrastructure team. This team has access to the password that is required in your configs. They will never disclose this password to you (deployment developer) for security reasons. You want to avoid them entering the password during each installation. To think of it this is the best you can do. They will have to enter the password at least once.

Cryptography solution won't really work here because your deployment package will need a way to decrypt the password anyway and if it can do it without user input, so can you (the developer), and this is not acceptable.

Since the password is store in PROD config files in plain text anyway, make the deployment package prompt for the password only if it's not know. Once a infrastructure team member supplies the password, save it in a file locally. Better yet, save it in machine-wide key container. You do not need a password for this. Next installation around the key will already be known, and your installation won't need to prompt for a key again. Of course you need to provide a way to change the stored key too if needed.

The tokenizing approach, that you described, works. I've been doing this for quite some time quite successfully. (I.e. passed external security reviews) Since you do have a plain text password in PROD, PROD must be considered secure (safe) environment. And since it safe, there is nothing wrong about caching (storing a copy of) this secure password within it.