Cifrado.Net

encryption clickonce (4)

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 encriptados con la clave de usuario pueden ser descifrados por cualquier proceso iniciado por el mismo usuario.
Esto no es posible. Todas las afirmaciones contrarias son el 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 la barra.
No. La aplicación tiene la clave secreta para descifrar algo, en cuyo caso regresa 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 realiza una validación de la configuración. (no fue manipulado), pero la configuración no es secreta.
No puede implementar secretos incrustados en una aplicación de forma segura. Es solo una cuestión de cuán alto es el precio, si su activo protegido (el secreto) lo vale, entonces 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 solicita no es cifrado, es DRM, y necesita buscar respuestas en la infraestructura DRM. No tengo conocimiento de una biblioteca administrada alrededor de la API DRM .

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

Al usar el cifrado a nivel de máquina, ¿no puede alguien acceder a mi servidor escribir un pequeño programa .Net para leer el contenido de las cadenas de conexión?
Si estoy implementando mi aplicación en las máquinas de los 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 descifrarla? El escenario es especialmente interesante en un escenario de implementación de ClickOnce. He leído acerca de las personas que almacenan la configuración sin cifrar en el servidor del editor y la encriptación a nivel de máquina cuando la aplicación se descarga, instala y ejecuta por primera vez. Esto me suena muy mal: las cadenas de conexión se deslizan sin protección a través del cable y permanecen sin protección durante un breve período de tiempo entre la descarga y la ejecución de la aplicación.
¿Puedo tener una clave pública y privada, firmar mi aplicación, cifrar el archivo de configuración con una clave y, cuando el usuario la ejecute, el descifrado solo será posible desde la aplicación firmada?
Ya 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 cambie la versión #. Por lo tanto, si necesito volver a compilar si cambio mi cadena de conexión, el punto de app.config se silenciará. ¿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?

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

Definitivamente trataría de usar el mecanismo del sistema operativo. Cuando trabaje en un entorno 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 simple con la configuración de seguridad del sistema operativo, solo el usuario tiene acceso al archivo. Sin embargo, usted y sus usuarios tienen que confiar en los administradores. En este caso, debe utilizar además el cifrado simétrico. Pero vea mis primeros argumentos: no será realmente seguro.

Buena pregunta en realidad,

No puede estar seguro de que nadie descifre su cadena de conexión (o contraseña). Por supuesto, puede cifrarlo, pero la gente podrá 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 sea más como un escenario extremo, pero es posible (fui un malvado en los años de estudiante :)). Por lo tanto, si tiene miedo de tal situación, tiene que proteger su aplicación, haga que sea más difícil desarmarla. Es un tema para otra discusión, pero, por ejemplo, puede usar Dotfuscator u otro buen ofuscador, ya que será más difícil para un cracker entender lo que está pasando dentro de su aplicación.
Por lo tanto, una posible solución puede ser "cifrar la cadena de conexión + usar el ofuscador", pero, como dije, no le dará una protección del 100%.

Es posible que Gustavo pueda implementar esto (este es mi plan para mi aplicación que se basa en el inicio de sesión).

El usuario ingresa las credenciales en la aplicación .Net. Las credenciales se transfieren a una aplicación del lado del servidor .php que las usa para iniciar sesión en la base de datos, recuperar una clave y devolverla a la aplicación .Net. La clave se usa luego en las cadenas de conexión cifradas y codificadas en la aplicación .Net para permitir el acceso completo a la base de datos.