¿Qué debo hacer cuando necesito almacenar contraseñas para usar en software de terceros?

4

Tengo una aplicación WPF de escritorio que se autentica con Dynamics CRM 2011. Solicito el nombre de usuario y la contraseña del usuario y los uso para conectarse a Dynamics CRM 2011 usando CrmConnection.parse("url={2};Username={1};Password{2}",CRMServerUrl, Username,Password) . Esta clase luego se conecta al servidor CRM utilizando las credenciales proporcionadas (autenticadas en Active Directory).

El enigma con el que estoy luchando es que parte del diseño de la aplicación es que la autenticación a CRM solo es necesaria una vez. Todas las autenticaciones pasadas la primera deben realizarse automáticamente utilizando las credenciales que el usuario ingresó anteriormente (y sí, el usuario puede cambiarlas en la aplicación si es necesario). Esto significa que necesito almacenar contraseñas, pero no puedo hacerles hash.

Actualmente, utilizo los métodos sugeridos por Jon Galloway en Cifrado de contraseñas en un archivo de .NET app.config . Un compañero de trabajo lo recomendó. Leí algunas otras preguntas sobre este tema, pero algunos de los conceptos como las claves derivadas, el cifrado de hardware o el envío de un valor derivado son puntos ciegos o no son posibles dentro de las restricciones de diseño.

¿Cuáles son mis opciones?

    
pregunta Nzall 23.04.2014 - 17:12
fuente

2 respuestas

2

Después de leer tu pregunta, pero antes de leer la publicación de Jon Galloway, mi primera reacción fue usar DPAPI. Así que me animé cuando finalmente eché un vistazo a la publicación de Jon.

Aquí es por qué. Como dice Snox, tiene sentido cifrar la contraseña con una clave maestra. Eso es exactamente lo que hace DPAPI. Pero, la clave maestra para DPAPI cambia entre usuarios y máquinas. Así que no tienes que descubrir tu propia manera de hacer esto. DPAPI probablemente ha sido estudiado por criptógrafos, por lo que debería ser bastante seguro.

Dicho esto, DPAPI no es una bala de plata. Sólo ofrece una compensación. Por eso es importante entender los riesgos involucrados. Primero, alguien que haya iniciado sesión como el mismo usuario puede descifrar blobs DPAPI simplemente llamando a la función correcta en el blob. Puede reducir esta amenaza utilizando el parámetro de entropía opcional. Lo recomiendo altamente Ese valor podría ser codificado en la aplicación o leerse desde una clave de registro, etc. Codificarlo en la aplicación podría ser el camino a seguir, ya que el atacante tendría que aplicar ingeniería inversa a la aplicación para recuperar el valor (no es difícil) , pero definitivamente sube el listón). Los atacantes con acceso a su sistema de archivos también pueden descifrar los blobs de DPAPI (suponiendo que conozcan la entropía opcional) usando DPAPIck . Esto también requiere conocer la contraseña del usuario.

    
respondido por el mikeazo 24.06.2014 - 14:04
fuente
0

Una de las razones por las que las contraseñas almacenadas son usualmente se revisa porque es una operación no reversible , esto significa que incluso si se piratea la base de datos, lo único que sabrá el atacante es el hash de las contraseñas y no las contraseñas reales.

Al no poder hacer esto, siempre puede cifrar cada contraseña que almacene , usando una Clave Maestra, solo tenga en cuenta que esta es una operación reversible por lo que será vulnerable a Ataque de solo texto cifrado (modelo de ataque para criptoanálisis donde se asume que el atacante solo tiene acceso a un conjunto de textos cifrados) y su Clave también será un punto de interés, por lo que debe mantenerlo seguro.

    
respondido por el Snox 24.04.2014 - 12:07
fuente

Lea otras preguntas en las etiquetas