.Net Encryption

Question

Lo que me gustaría saber es el enfoque definitivo para encriptar cadenas de conexión en un archivo de configuración. Aquí están mis preguntas:

1. uso de la encriptación a nivel de máquina, no pueden acceder a mi servidor a nadie escribir un pequeño programa .NET para leer el contenido de las cadenas de conexión?

2. Si estoy implementando mi aplicación en máquinas de usuarios en un entorno empresarial, y la aplicación tiene cadenas de conexión en un archivo de configuración, ¿cómo puedo asegurarme de que solo mi aplicación pueda descifrarlo? El escenario es especialmente interesante en un escenario de implementación de ClickOnce. He leído acerca de personas que almacenan la configuración sin encriptar en el servidor editor y encriptan a nivel de máquina cuando la aplicación se descarga, instala y ejecuta por primera vez. Esto suena tan mal para mí: las cadenas de conexión se comprimen sin protección a través del cable y se sientan sin protección durante un breve período de tiempo entre la descarga y la ejecución de la aplicación.

3. ¿Puedo tener una clave pública y privada, firmar mi aplicación, encriptar el archivo de configuración con una clave, y cuando el usuario la ejecuta, el descifrado solo sería posible desde la aplicación firmada?

4. Dado que estoy usando ClickOnce, podría tener mi información confidencial encriptada en el código o incrustada, porque ClickOnce no detectará un cambio a menos que la versión # cambie. Entonces, si necesito volver a compilar si cambio mi cadena de conexión, el punto de un app.config está silenciado. ¿Qué otros enfoques puedo tomar, fuera del uso de un archivo de configuración, para lograr la protección de las cadenas de conexión en el servidor, el cliente y en el medio?

Answer 1

1. Sí. Los secretos cifrados con la clave de la máquina se pueden descifrar mediante cualquier proceso con acceso a la clave de la máquina.Los secretos cifrados con la clave del usuario se pueden descifrar mediante cualquier proceso iniciado por el mismo usuario.
2. Esto no es posible. Todas las afirmaciones contrarias son aceite de serpiente. Tu aplicación necesita un secreto para descifrar algo. No hay esquemas conocidos para ocultar un secreto dentro de una aplicación. Hay varios esquemas de ofuscación, pero nada a prueba de balas. Lo mejor que puedes hacer es subir el listón.
3. No. O la aplicación tiene la clave secreta para descifrar algo, en cuyo caso vuelve al punto 2, o su aplicación tiene la clave pública, en cuyo caso cualquiera puede descifrar el mismo secreto, por lo que básicamente hace una validación de la configuración (no fue alterado), pero la configuración no es secreta.
4. No puede implementar secretos integrados en una aplicación de forma segura. Es solo cuestión de qué tan alto es el precio; si su activo protegido (el secreto) lo vale, un hacker lo obtendrá.

La infraestructura de cifrado está diseñada para proteger los secretos del usuario actual de otros usuarios. No está diseñado para proteger los secretos de una aplicación del usuario que la usa. Lo que pides no es encriptación, es DRM, y necesitas buscar respuestas en la infraestructura de DRM. No conozco una biblioteca administrada en el DRM API.

Answer 2

Buena pregunta en realidad,

No se puede estar seguro de nadie descifrará la cadena de conexión (o contraseña). Por supuesto, puede cifrarlo, pero las personas podrán descompilar su aplicación y ver qué algoritmo de cifrado utiliza y qué clave utiliza para descifrar su cadena de conexión/contraseña. Tal vez es más como un escenario extremo, pero es posible (yo era una malvada galleta en los años de estudiante :)). Entonces, si tiene miedo de tal escenario, debe proteger su aplicación y dificultar el desmontaje. Es un tema para otra discusión, pero por ejemplo puede usar Dotfuscator u otro buen ofuscador: hará que sea más difícil para un cracker entender lo que sucede dentro de su aplicación.
Entonces, una posible solución puede ser "encriptar cadena de conexión + usar obfuscator", pero, como dije, no le dará 100% de protección.

Answer 3

Almacenar secretos con un cifrado simétrico siempre es problemático siempre que no desee solicitar una contraseña o utilizar otra solución técnica para descifrar su secreto (como hardware especial). Cuando tenga que almacenar la clave completa en cualquier lugar del sistema, habrá una manera para que otras personas la recuperen.

Definitivamente intentaré usar el mecanismo del sistema operativo. Cuando trabaja en un entorno de Windows puro con MS-SQL, debe usar la seguridad integrada en lugar de usuario/contraseña. Otras bases de datos pueden tener capacidades similares, también.
Otra opción (más débil) es asegurar el archivo de texto sin formato con la configuración de seguridad del sistema operativo: solo el usuario tiene acceso al archivo. Sin embargo, usted y sus usuarios deben confiar en los administradores. En este caso, debe usar encriptación simétrica además. Pero vea mis primeros argumentos: no será realmente seguro.

Answer 4

Gustavo es posible que pueda implementar esto, (este es mi plan para mi aplicación, que está basado en el inicio de sesión).

Credenciales de las entradas de usuario en la aplicación .Net. Las credenciales pasan a una aplicación .php del lado del servidor que las usa para iniciar sesión en la base de datos, recuperar una clave y volver a pasarla a la aplicación .Net. Luego, la clave se utiliza en las cadenas de conexión codificadas y codificadas en la aplicación .Net para permitir el acceso completo a la base de datos.