¿Cómo debo manejar valores secretos en un proyecto en control de fuente?

Mi pregunta es esencialmente la misma que esta, pero para una aplicación de Windows Store, c # y Visual Studio. Quiero tener una manera fácil de mantener los valores secretos en el proyecto, en un file que se puede ignorar en (no se incluye) el control de origen. ¿Cómo debería estructurar mi proyecto para almacenar el secreto de la aplicación de una manera que facilite el control de construcción / fuente?

Mi primera idea fue almacenarlo en un file XML (no registrado) y cargarlo en time de ejecución, pero esto lo deja disponible para el usuario que lo instala, por lo que debe hacerse en time de compilation. ¿Cómo puedo almacenar un par de valores secretos y hacer que Visual Studio los reemplace en mi código cuando se construya mi proyecto?

En mi empresa decidimos seguir la solución. En el file de configuration, vinculamos secciones con valores "secretos" en configuraciones externas. Las configuraciones externas están en control de fuente. Primero no, pero después de un problema cuando nuestro server de compilation perdió un disco, decidimos que era más seguro almacenarlo en un lugar que tenía una copy de security. La carpeta en el control de fuente (puede estar también en el server de files) está realmente restringida para leer y escribir solo a las personas que lo necesiten. Construya las carpetas de "proyectos" de las comprobaciones del process más la carpeta de "configuration" y construya. Después de la creación de la carpeta "configuration" se elimina. El acceso al server de compilation también está restringido.

Una opción es almacenar los secretos en el control de la fuente, pero almacenarlos en forma cifrada. En sus entornos de desarrollo o construcción, use una variable de entorno para almacenar la key y descifrar sobre la marcha. De esta forma, obtendrá los beneficios del control de la fuente mientras mantiene segura su información.

Es posible hacer esto incluso si está utilizando app.config o web.config, solo necesita modificar la configuration del código al inicio.

Erick

Actualizado
Si coloca un secreto en un área no confiable (por ejemplo, control de fuente pública), es vulnerable. Incluso si está encriptado, con suficiente diligencia puede ser recuperado.

La única forma de mantenerlo fuera de scope es tener un service externo que interactúe con la API de terceros. Eso tiene sus propias compensaciones (por ejemplo, authentication de usuario como mencionaste en los comentarios). Especialmente si tus desarrolladores necesitan utilizar la API de terceros cuando testingn, no veo otra alternativa que limite la exposition del secreto.

Cree un nuevo file de class en su proyecto que tenga ranuras para todos sus valores secretos y contenga valores ficticios / de testing para todos ellos. Revisa eso en el control de la fuente con el rest de tu proyecto, para que cualquiera que lo construya sin acceso a los secretos obtenga algún tipo de versión de testing.

Luego, cree una copy de ese file de class con los valores secretos reales, y colóquelo en algún lugar fuera del control de fuente. Escriba un script por lotes en el evento de preconstrucción que busque este file de class, y si lo encuentra, reemplaza el file ficticio que está incluido en el proyecto.

De esta forma, su proyecto aún puede estar en control de fuente y cualquiera puede verificarlo, comstackrlo y ejecutarlo en el modo de testing. Sus valores / files secretos se almacenan solo en su server de compilation, de modo que solo cuando construya el proyecto tendrá los valores reales.

Recuerde hacer una copy de security de su file de secretos en algún lugar. Y también recuerde que el código .NET se puede descomstackr fácilmente, por lo que sus secretos pueden no ser tan secretos como usted espera: cualquier usuario con un reflector .NET puede ver todo el código en su ensamblado de lanzamiento, incluida su class secreta.