¿Cuánto tiempo permanecen en la memoria los campos de contraseña HTML (enviados al servidor como postdata)?

En cualquier marco web importante del lado del servidor, generalmente hay un mecanismo para leer la entrada del formulario HTML, por ejemplo. en ASP, para un elemento HTML, <input type="text" name="the_field" /> , es Request.Form("the_field") , donde Request.Form es un objeto de tipo diccionario donde los valores se analizan desde los datos de la POST en pares clave / valor.

También hay varias recomendaciones para mantener solo las contraseñas en la memoria por un tiempo mínimo, hasta e incluyendo el uso de una matriz de caracteres mutables en lugar de una cadena inmutable, fijándola para que no pueda paginarse o copiarse, y poner a cero cada elemento de la matriz cuando haya terminado (o usando algo como .NET's SecureString , que hace lo mismo).

Teniendo en cuenta esto, ¿qué mecanismos pueden existir para decirle al servidor web que necesita tratar los datos de formulario publicados como seguros, y para realizar la fijación / eliminación de, digamos, un campo HTML <input type="password" /> ?

Uno podría razonablemente esperar que el navegador haga un esfuerzo adicional para los campos de contraseña (aunque espero que no lo hagan), ya que pueden deducir del marcado que tales protecciones son necesarias.

La capa de transporte está cubierta por HTTPS, y no está en cuestión.

Pero nada de lo que he visto proporciona al servidor web la semántica de los datos de publicación, por lo que puede optar por aplicar protecciones en memoria.

He tenido un par de ideas sobre cómo podría manejarse una cosa así en un servidor web si se diseñara desde cero (tenga en cuenta que no estoy diseñando un servidor web desde cero):

1. Aplique protecciones en memoria a todas las solicitudes: Esto parece ser lo más sencillo, pero puede afectar negativamente el rendimiento de las páginas que no son estrictamente confidenciales pero que se publican bajo SSL (por ejemplo, sitios con todos los SSL o páginas "Mi cuenta" que no tienen campos de "Nueva contraseña"). Podría ser configurable en 'todas las solicitudes' / 'solo HTTPS'

2. Estandarice un encabezado HTTP que define los campos a proteger: mitiga el problema de SSL total, pero proporcionaría un punto de inicio obvio para la inspección (aunque estoy seguro de que txtUser=foo&txtPassword=bar ya es un indicador suficientemente bueno). Tomaría x años para que el W3C acuerde un estándar, y otros y años para que los navegadores lo implementen.

3. Registre los campos de publicación segura en la configuración del servidor (o mediante la integración de idioma): el analizador de flujo de solicitudes del servidor sería responsable de leer cada clave de publicación, verificar la lista interna y aplicar Protecciones de memoria para el posterior valor posterior. Tal vez incluso excluyéndolo del Request.Form normal en lugar de un objeto Request.Passwords con una estructura de datos adecuada para el propósito, o sustituyendo el valor Request.Form con una referencia del objeto al SecureString .

Entonces, ¿hay algún servidor web que ya haga esto (o algo así), o le permita un nivel de acceso lo suficientemente bajo como para implementar estas protecciones manualmente? Pensé que tal vez la canalización integrada de IIS7, pero no puedo ver un evento que se realice con la suficiente antelación.

¿Esas protecciones son incluso necesarias, o es solo una solución que busca un problema? Si es así, ¿qué es lo que hace que esto no sea necesario cuando no se maneja la contraseña en la memoria de una aplicación de escritorio?