¿Hay algún beneficio al usar SecureString en ASP.NET?

Question

Si entiendo correctamente, esto es para mantener el texto sin memoria, para que la aplicación sea segura contra ataques esotéricos en la memoria, el montón de basura o la memoria localizada en el disco. SecureString se alimenta con bytes no administrados y consume un byte no administrado a la vez; luego, la cadena se borra de la memoria. (Corregir si me lejos!)

En ASP.NET, el secreto se recoge en un formulario web, que en la parte posterior del poste de HTTPS. Pero luego el objeto Request convierte todos los valores de solicitud del formulario en pares de valores de nombre y los coloca en una colección, p. Request ["TxtPassword"] - por lo que incluso antes de que pueda obtener la cadena, ya se ha escrito de forma insegura en la memoria. Peor aún, si estuviera usando un control, la representación no segura tendrá más cadenas administradas en la propiedad del TextBox.

para hacer cualquier cosa con este SecureString necesito una API que lleva cadenas no administrados - por lo que parece que no puedo usar la cadena segura para un parámetro de procedimiento almacenado o mucho más.

estoy haciendo esto mal o se trata de una misión inútil tratar de usar SecureString y no se escapan copias de la cadena sin garantía en memoria administrada?

Cambiar a autenticación de OAuth o Windows no es una opción.

Answer 1

Como dedujo correctamente, y otros ya mencionados, tiene poco sentido usar SecureString para almacenar datos sensibles a la seguridad que provienen de un formulario ASP.NET, porque esos datos ya están presentes en la memoria en texto plano.

Hay otros escenarios, sin embargo, donde se recomienda el uso de SecureString, porque los datos confidenciales son creados por el programa y no deben permanecer en la memoria una vez que haya terminado de trabajar con él. Por ejemplo, crear un sitio de SharePoint mediante programación o transferir credenciales de autenticación de un sistema a otro.

De vuelta en los viejos tiempos, era más fácil para asegurarse de que la vida útil de los datos sensibles era lo más corto posible.Podría ser asignado en la pila y se aclaró tan pronto como se hizo el programa de usarlo:

char secret[512]; 
generate_secret(secret, sizeof(secret)); 
do_something_with(secret); 
memset(secret, 0, sizeof(secret)); 
// Secret data is now gone. 

Tal enfoque no es posible con cadenas administrados, sin embargo, principalmente porque:

• Son no asignado en la pila,
• Son inmutables, por lo que no se pueden borrar,
• No son desechables, por lo que no hay garantía sobre el momento en que el GC liberará los datos. Puede que nunca se libere, dependiendo de las condiciones de la memoria.

SecureString trata de resolver ese problema por ser mutable y desechable, que permite escribir:

using (SecureString secret = new SecureString()) { 
    GenerateSecret(secret); 
    secret.MakeReadOnly(); 
    DoSomethingWith(secret); 
} 
// Secret data is now gone. 

Answer 2

Creo que tienes lo básico. SecureString está diseñado desde el punto de vista de estar en el lado del cliente. Por lo tanto, para una aplicación WPF/Winforms (y tal vez Silverlight, no recuerdo si está allí) vale mucho, mientras que para una aplicación del lado del servidor, no tanto debido a no ser el primero en manejar la cadena.

Answer 3

SecureString se utiliza mejor para asignar credenciales de red para llamadas directas entre sistemas. Es un hecho en la arena web que si la credencial ingresó a través de la web en texto plano, pero si tiene que devolver esa credencial a través de una llamada de credencial estándar (ftp, servicios de directorio, etc.), entonces usar SecureString no no duele como un método de paso. Aunque tiene razón en que la cadena ya está en su sistema de servidor en texto plano, al menos puede reducir la huella entre los sistemas. Si solo está usando esta contraseña localmente, entonces estaría de acuerdo en que SecureString probablemente no sea muy necesario.

Los buenos hábitos de seguridad, sin embargo, nunca son realmente una pérdida de tiempo.

Answer 4

Si no estoy equivocado, puede utilizar la siguiente solución para mantener la entrada de la cadena la gestión de la CLR: Web API: how to access multipart form values when using MultipartMemoryStreamProvider?

Sólo leyó el FormData en el método ExecutePostProcessingAsync (..) como ReadAsByteArrayAsync() y nunca debe convertirse en una cadena en el camino.

Todavía es necesario https para mantener la entrada segura en el camino.

Answer 5

La única vez que señalo el uso que falta de SecureString al realizar revisiones de código de seguridad, es en casos donde los datos pueden ser encriptados por la aplicación y reutilizados.

Por ejemplo, cuando un backend sitio web tiene que comunicarse con un tercero o de otro recurso interno que requiere credenciales. Dado que estos no pueden ser hash, usaría el SecureString cuando necesite compilar la solicitud (que también debe estar en TLS).

Otra alternativa es utilizar el Windows Data Protection API si es posible.

Tenga en cuenta que el propósito de SecureString es mantener el contenido en la memoria durante un tiempo lo más corto posible.