Encriptación C# en la edad del reflector

Tengo un programa, donde la contraseña de una base de datos es establecida por un usuario remoto. El programa guarda el nombre de usuario y la contraseña en una cadena cifrada en un archivo xml que, de otro modo, debería ser legible para el ser humano. Ahora, esto funciona bien, utilizo el cifrado C# DES con una clave, y se cifra y descifra. Ahora, el problema es que cualquiera puede usar el reflector para ver la clave. Incluso con ofuscación, la clave debería ser evidente. Entonces, ¿cómo lidia uno con esto? Ahora, no necesito que esto sea seguro para la NSA, pero realmente me gustaría evitar que nadie mire. Gracias.Encriptación C# en la edad del reflector

EDIT: Gracias por todos los consejos hasta ahora, la información sobre este tipo de cosas no está muy extendida, y realmente aprecio consejos generales, así como respuestas específicas.

Fuente

2009-07-16 Steve

Usted está formulando una pregunta de seguridad. Usted ha identificado el recurso _vulnerable_ - la base de datos. Usted ha identificado la _vulnerabilidad_ - la falta de encriptación efectiva en el archivo de contraseña. No has identificado el _threat_. ¡Es peligrosamente contraproducente intentar descubrir las mitigaciones de la vulnerabilidad sin identificar primero la amenaza! ¿Quién está amenazando tu recurso y cómo? –

Bueno, nadie específicamente, me gustaría codificar mi aplicación para que sea segura y no cuáles son las mejores prácticas. – Steve

La mejor práctica n. ° 1 para codificar aplicaciones seguras es IDENTIFICAR LAS AMENAZAS. No puede estar seguro si ni siquiera sabe a qué amenazas le está protegiendo el código. Quiero decir, supongo que te pedí que diseñaras una casa segura.Probablemente comiences haciendo una lista de amenazas a los ocupantes de la casa como el primer paso, ¿verdad? –

Intente utilizar DPAPI (clase System.Security.ProtectedData). Esto protege sus datos encriptados usando las credenciales de usuario o máquina. Por lo tanto, solo la cuenta de usuario que accede a los datos (credenciales del usuario) o un usuario que puede iniciar sesión en la máquina (credenciales de la máquina) podrán descifrar sus datos.

Fuente

2009-07-16 19:50:49 Joe

este enfoque funciona bien para los programas del lado del servidor, pero no escala bien para el lado del cliente –

@Scott puede aclarar –

Esto funciona especialmente bien para el código del lado del cliente. Es más difícil utilizar DPAPI en una aplicación del lado del servidor (suplantación, acceso a la cuenta de servicio a los perfiles, etc.). En un cliente, el usuario especifica su contraseña en la primera ejecución de la aplicación que está encriptada con su clave DPAPI. Los datos cifrados se almacenan en su sistema para que solo ellos (o un administrador) puedan descifrar esos datos. Cuando el usuario vuelve a iniciar la aplicación, DPAPI usa sus claves para descifrar la contraseña. Obtiene la ventaja de no almacenar una clave de cifrado común en el ensamblaje donde se puede descifrar fácilmente. –

Esto no es realmente un problema sobre Relector o no. Se trata de la gestión de claves. DES y cualquier otro esquema de cifrado se basa en las claves que se cambian con regularidad. La codificación difícil de la clave en código obviamente viola esto. Para evitar esto, debe buscar en la administración de claves.

EDITAR: Para elaborar un poco: Dependiendo de su configuración, puede almacenar las contraseñas hash en el sistema de archivos y confiar en el sistema de archivos/seguridad del usuario o en una base de datos y confiar en los derechos de la base de datos.

Fuente

2009-07-16 19:47:06

¿podría ser más específico sobre cómo se manejaría esto? – Steve

Comenta cuando bajas la votación. Gracias. –

Lamentablemente, nunca hay una forma 100% segura de hacerlo. Puede oscurecer el código, usar código no administrado para áreas secretas, pero dado que su aplicación puede leer la contraseña nuevamente, también lo puede hacer cualquier atacante que ponga suficiente esfuerzo en ello.

Fuente

2009-07-16 19:49:57 chris166

No debe almacenar la contraseña cifrada en absoluto. Debería almacenarlo hash en su lugar, con una función hash de una dirección. Ver:

http://www.codinghorror.com/blog/archives/000953.html

Fuente

2009-07-16 19:50:54 Alex319

No ayuda en la situación del PO, donde necesita la contraseña para acceder a un recurso externo (una base de datos). – Joe

¿Y cómo exactamente presentarías un * hash * en una cadena de conexión? –

Tuvimos una situación similar. Terminamos colocando la clave en un archivo y pidiéndole al usuario que ingrese algún tipo de contraseña (o clave usando hash) para poder leer el archivo. Fue el dolor de hacer que el usuario ingrese más información, pero elimina la clave del programa.

Fuente

2009-07-16 19:53:18 SwDevMan81

No debe encriptar su contraseña utilizando un secreto incrustado en su aplicación, que es la raíz de sus problemas. No importa cuán fuerte sea su encriptación, la clave está claramente expuesta en su código.

Debe preguntarle a su usuario las credenciales, almacenar el nombre/usuario de db y la contraseña en una sección de configuración normal en su app.config y confiar en la clase DpapiProtectedConfigurationProvider respaldada por DPAPI para cifrar y descifrar la sección por usted, utilizando cualquiera las teclas de la máquina o una tecla específica del usuario. Vea el enlace que proporcioné para ver un ejemplo completo de cómo hacer esto.

Fuente

2009-07-16 20:02:58

Encriptación C# en la edad del reflector

Respuesta

Cuestiones relacionadas