Encriptación de secciones y configuraciones en un archivo App.config que se redistribuirá

Question

Estoy creando una aplicación de Windows normal que se distribuirá a varios usuarios en mi departamento. Tendré que incluir algunas contraseñas de conectividad en el archivo App.config, y obviamente no quiero que los usuarios finales simplemente activen el bloc de notas y observen las contraseñas.

Varios artículos señalan cómo cifrar/descifrar las secciones de configuración, pero parece que tiene que compartir/enviar algunas claves con la solución implementable.

¿Hay una forma más simple de cifrar algunos de los ajustes para que no sean legibles por el usuario, pero que no requieran pasos o archivos adicionales al redistribuir el programa? Una gran ventaja sería que el acceso a la configuración de configuración sigue siendo transparente dentro del código .NET. Siempre podría simplemente crear un método personalizado para saltear/cifrar la cadena y en mi código personalizado descifrarlo, pero me pregunto si hay algo más simple.

Cualquier respuesta o enlaces a los artículos sobre cómo hacer esto son muy apreciados. Gracias

Answer 1

Si está intentando encriptar su cadena de conexión en su App.Config/Web.Config, puede hacerlo a través de la clase de configuración:

Configuration config = ConfigurationManager. OpenExeConfiguration(ConfigurationUserLevel.None); 
ConfigurationSection section = config.GetSection("connectionStrings"); 
if (section != null) 
{ 
    if (!section.IsReadOnly()) 
    { 
     section.SectionInformation.ProtectSection    ("RsaProtectedConfigurationProvider"); 
     section.SectionInformation.ForceSave = true; 
     config.Save(ConfigurationSaveMode.Full); 
    } 
} 

Hay dos métodos: RsaProtectedConfigurationProvider y DPAPIProtectedConfigurationProvider

Ver este ->http://www.codeproject.com/KB/cs/Configuration_File.aspx y http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx.

Answer 2

De cualquier manera, el cifrado y descifrado del archivo de configuración de la aplicación no tiene sentido ya que el .EXE se puede examinar por Reflector!

Claro que puede ofuscar el código, pero eso hará que la depuración sea una pesadilla en un entorno de producción donde un extraño error desconocido/no descubierto se infiltró porque no podría decir qué/dónde/por qué/cómo controlar un extraño error que solo se mostrará en la versión ya que la pila y los mensajes de error se ofuscarán también ...

Eso es algo a tener en cuenta y una trampa potencial ... el usuario puede no ser conocedor de la tecnología, pero seguro podrían, en teoría, pedirle a un amigo/pariente/compañero que la piratee/rompa sin su conocimiento ... Esta respuesta no pretende desanimarlo, y espero que no se sienta ofendido por mi respuesta ...

Espero que esto hel ps, Saludos cordiales, Tom.

Answer 3

En resumen, la criptografía no es una varita mágica que puede reparar mágicamente un programa inseguro.

Un atacante intentará obtener contraseñas de la memoria utilizando un depurador mientras se ejecuta la aplicación. Las contraseñas también existirán en el binario y se pueden obtener fácilmente. El uso de cualquier cifrado se puede omitir porque la contraseña debe estar en texto sin formato en el momento del uso. Siempre que se utiliza memoria, también se puede observar con un depurador.

La respuesta está en contra de depuración: http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx

Más ventanas avanzados anti-Depuración:

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/

http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/

http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/