c# - startinfo - Uso seguro de SecureString para el formulario de inicio de sesión

string to securestring

Question

Así que hay una clase que parece muy poco utilizada: SecureString . Ha existido por lo menos desde 2.0, y hay algunas preguntas de SO, pero pensé que me haría mis propias preguntas específicas:

Tengo un LoginForm; diálogo simple de WinForms con nombre de usuario y campos de contraseña (enmascarados). Cuando el usuario ingresa ambos y hace clic en "Iniciar sesión", la información se pasa a una clase de autenticación inyectada que hace una capa de estiramiento de la clave, y luego procesa la mitad de la clave estirada para su verificación, mientras que la otra mitad es la clave simétrica para el usuario cifrado. datos de la cuenta. Cuando todo esto termina, el loginForm se cierra, la clase de autenticador se desecha y el sistema pasa a cargar el formulario principal. Cosas bastante estándar, tal vez un poco más complicadas que el hash-the-password-and-compare, pero la contraseña con hash simple sería derrotada en mi caso al almacenar los datos del usuario en texto plano, porque esos datos incluyen credenciales para un tercero. sistema de fiestas (y todos sabemos cómo a las personas les gusta reutilizar las contraseñas).

Aquí está la primera pregunta; ¿Cómo usaría SecureString para recuperar la contraseña del cuadro de texto Contraseña, sin que se exponga como un System.String normal a través de la propiedad Text del cuadro de texto? Supongo que hay una forma de acceder a la ventana GDI no administrada para el cuadro de texto que están envolviendo las clases CLR y extraer los datos de texto usando la clase Marshal. Simplemente no sé cómo, y parece que no puedo encontrar buena información.

Aquí está la segunda pregunta; una vez que tengo la contraseña como SecureString, ¿cómo la paso a un proveedor de hash desde el espacio de nombres System.Security.Crypto? Supongo que usaría Marshal.SecureStringToBSTR (), luego Marshal.Copy () del IntPtr devuelto de nuevo en una matriz de bytes. Luego puedo llamar a Marshal.ZeroBSTR () para limpiar la memoria no administrada y puedo poner a cero la matriz administrada con Array.Clear () una vez que tenga el hash. Si hay una forma más limpia que me permita un control total sobre la vida útil de cualquier copia administrada de la memoria, avise.

Tercera pregunta ¿Es todo esto realmente necesario, o es la inseguridad inherente de System.String en un entorno de memoria administrada un poco exagerada? Todo lo que se use para almacenar la contraseña, encriptada o de otro modo, debe estar fuera del alcance y en su camino hacia el recolector de basura mucho antes de que el sistema operativo considere la posibilidad de intercambiar la aplicación en la memoria virtual (permitiendo que la contraseña sea rastreada del archivo de intercambio después de un apagado duro de la computadora). Un ataque de arranque en frío es una posibilidad teórica, pero en realidad, ¿qué tan común es esto? La mayor preocupación son los datos del usuario ahora descifrados, que se mantienen como parte del usuario durante toda la vida útil de la aplicación (y, por lo tanto, serían un candidato principal para el uso de SecureStrings, ya que, excepto por un par de usos básicos, permanecen bastante inactivos).

Answer 1

En primer lugar, me gustaría decir que estoy de acuerdo con nosotros, no se moleste.

Ahora a los detalles:

• This respuesta proporciona un gran fondo para la discusión.
• This es un control TextBox que utiliza SecureString. No he usado esto, así que no puedo comentar sobre la calidad, pero al estar en el blog de MS no espero que sea todo menos apropiado.
• Para responder a la pregunta acerca de pasar los datos a System.Security.Crypto, básicamente no puede y ninguna cantidad de almacenamiento de memoria no administrada lo ayudará, ya que durante el proceso de tal cálculo de caracteres, la cadena se descifra. Tiene que hacerlo porque de lo contrario no puede ser consumido por la API de destino. Si está utilizando CSP o X509Certificate, puede usar SecureSctring porque estos están soportados en el marco, pero eso es todo.

Answer 2

Si cree que necesita SecureString , debe creer que un atacante también puede leer la memoria de su proceso. Si esto último es cierto, puede leer los caracteres de la contraseña a medida que se escriben, leer directamente desde el búfer interno de caracteres del cuadro de texto o leer píxeles de la pantalla.

Este es un escenario poco realista. No utilice SecureString . Ayuda poco y te roba el tiempo.

Los ataques de arranque en frío son más reales, pero extremadamente infrecuentes. Requieren acceso físico a la máquina que generalmente es totalmente propietario de la máquina. Leer por el atacante es la menor de tus preocupaciones en este caso.

Básicamente, tiene que idear un caso en el que su tiempo de desarrollador se SecureString uso de SecureString .