Una auditoría de seguridad quiere que el usuario / contraseña estén codificados para iniciar sesión en asp.net. Esto parece inútil o no.

Question

Una auditoría de seguridad quiere que el usuario / contraseña estén codificados para iniciar sesión en asp.net. Esto parece inútil o no.

#1 de Crypt32 (2 votos)

3

Estamos usando asp.net mvc, usando formularios de autenticación. El nombre de usuario y la contraseña se envían al servidor con TLS con un certificado seguro seguro. Su justificación para esto:

amenaza: "el servidor web utiliza autenticación de forma de texto sin formato. Si un atacante con acceso al tráfico de red desde y hacia el host de destino puede obtener credenciales de inicio de sesión al detectar el tráfico de red".

Este es un problema para cualquier sitio web, e imo suena como una pérdida de tiempo. Traté de encontrar la justificación para hacer esto. La mejor respuesta que encontré fue aquí:

¿Es seguro enviar nombres de usuario / contraseñas en una conexión https para autenticar a los usuarios?

básicamente no vale la pena y puede hacer más daño que bien. ¿Alguien puede explicar el daño?

Debido a que es asp.net, creo que tendré que escribir un módulo de autenticación personalizado como aquí:

enlace

Imo, creo que esto introduce más riesgo que beneficio. es decir, el módulo no funciona en algunos escenarios de casos de borde. ¿Qué piensas? ¿Algún otro riesgo que no esté pensando?

password-management authentication tls asp.net

pregunta Neophyte.net 06.12.2017 - 23:30

fuente

1 respuesta

Lea otras preguntas en las etiquetas password-management authentication tls asp.net

¿Cómo se puede acceder a una cuenta a pesar de la autenticación en dos pasos? Malware: ¿Hay alguna diferencia entre el montaje automático y el montaje manual?

score 2 · Answer 1

Lo que el auditor afirma: es un problema para el transporte sin cifrar (HTTP sin formato, sin HTTPS). En este caso, los datos de autenticación se envían a través de la red en texto sin formato. Aquí es donde HTTP S viene a rescatar. Como se mencionó en los comentarios, una vez que los datos llegan al módulo de red (en el caso de la conexión HTTPS), los datos se cifrarán y se protegerán durante la transmisión. Y las credenciales de texto sin formato en el lado del cliente ya no son un problema.

Lo que agregaría aquí es que todo el sitio web debe estar cubierto por HTTPS y ninguna página se carga en HTTP simple. Cuando se autentica, el usuario recibe una cookie de autenticación que se envía al servidor con cada solicitud de página. Así es como el servidor te autentica. Y si un atacante puede obtener estas cookies, podrá hacerse pasar por la entidad almacenada en estas cookies. Incluso sin tener que poseer usuario y contraseña.

Puede encontrar recomendaciones para el uso adecuado de HTTPS y la configuración de seguridad del servidor para mitigar la mayoría de las fallas potenciales en su aplicación web. Por ejemplo, puede consultar este: Hoja de referencia de protección de la capa de transporte .

p.s. y estoy de acuerdo con @joe en que muchos auditores no tienen idea de lo que están hablando. En la mayoría de los casos, simplemente ejecutan ciegamente su software [¿escáner de vulnerabilidad?] Sin excavar y / o analizar lo que dice exactamente.