Share encrypted web.config between developers

Question

Here at the job, we're working on an ASP.NET MVC application for a proof of concept. Some of the operations that the application performs require transmission of credentials, so we're storing those creds in an encrypted section of the web.config. The difficulty we're having is that when one developer encrypts the data and commits it, the next developer who updates his local copy and tries to use that web.config gets exceptions because their machine can't decrypt the config for use.

How ought we to handle this?

I think there's a way to separate the encrypted section off in another file and include it into the main web.config. I'm not sure exactly how to do it, but that would allow you to pass around the main web.config with its changes, and encrypt just the parts you need locally. — ekolis, Aug 27 '12 at 16:43
Don't store or retrieve the webconfig, or if the contents change regularly, encrypt after retrieval. I think you can trigger the an application after checking it out from source control. Only as hint as I'm not an expert regarding webconfig. — Maarten Bodewes, Aug 27 '12 at 16:48

score 1 · Answer 1 · answered Aug 27 '12 at 16:59

1

In the past, I've used the machine.config for sensitive credentials i.e. connection strings and such. It's located at C:\Windows\Microsoft.Net\Framework\V4.0.30319\Config

This will allow you to omit the credentials out of commits altogether. Just make sure each developer and/or server has its own machine.config with the required credential settings.

answered Aug 27 '12 at 16:59

Justin Soliz

2,781
3
25
33

As machine.config is a global file, that can have bad side effects in some environments. – Andrew Barber Aug 27 '12 at 17:04
Understandable, namespaced keys also help i.e. company.projectname.db_connection – Justin Soliz Aug 27 '12 at 17:13

score 1 · Answer 2 · edited May 23 '17 at 11:56

I'm assuming that you are using aspnet_regiis.exe to encrypt the section. If this is the case the reason that you are having problems is that the keys used for encryption/decryption are different on the machines.

You can either use the same keys on all of the machines, from a configuration perspective this would be similar to a farm setup so you can use the information in this SO question.

Alternatively since there's an inherent assumption that the developers have access to the credentials leave it decrypted until the app is deployed to the production server and then encrypt that section. This is a common solution when the username/password are specified in the web.config as part of the connection string for database connections, the connection would be updated to reflect the production DB server as part of the deployment process just prior to encryption.

I guess that makes the most sense, develop using plain webconfig, then encrypt on deployment. — Maarten Bodewes, Aug 27 '12 at 18:31

score 0 · Answer 3 · edited Mar 16 '19 at 16:46

In first place not sure why you chose this option when there are other much better ways to handle keys secrets in DevOps best practices. That seems classic way. Also during debug time any developer can peek into actual value or spit out in log?

Anyways, if you put entire dilivery life cycle as context to this problem may here what I would do to achieve what you are trying to protect keys secrets:

Do not store anything even encrypted keys secrets which team doesn't need to run locally except dev or local environment.
In web.config have local or remote keys secrets
In release transformation, clean up all keys secrets to accidental use to environmental
Use release time variable replacement pretty common on any deployment tool to choose e.g Azure/TFS DevOps deployment support it with many different ways - deploy definition level, stage level, library variable or even better key valut store with software+hardware encryption options

Hope this helps in your design approach at least.

Share encrypted web.config between developers

3 Answers3