¿Es seguro DIGEST-MD5 si se realiza a través de HTTPS?

Navega tus respuestas
7

Si la negociación DIGEST-MD5 se realiza a través de una conexión HTTPS en lugar de HTTP, ¿eso evita esta lista de desventajas de Wikipedia ?:

  

La autenticación de acceso implícita está pensada como un compromiso de seguridad. Está destinado a reemplazar la autenticación de acceso básico HTTP sin cifrar. Sin embargo, no pretende reemplazar los protocolos de autenticación fuertes, como la clave pública o la autenticación Kerberos.

     

En términos de seguridad, hay varios inconvenientes con la autenticación de acceso de resumen:

     

  • Muchas de las opciones de seguridad en RFC 2617 son opcionales. Si el servidor no especifica la calidad de protección (qop), el cliente operará en un modo RFC 2069 heredado de seguridad reducida.

    •   

  • La autenticación de acceso implícita es vulnerable a un ataque Man-in-the-middle (MitM). Por ejemplo, un atacante MitM podría decirle a los clientes que utilicen la autenticación de acceso básico o el modo de autenticación de acceso implícito RFC2069 heredado. Para ampliar esto, la autenticación de acceso de resumen no proporciona ningún mecanismo para que los clientes verifiquen la identidad del servidor.

    •   

  • Algunos servidores requieren que las contraseñas se almacenen utilizando un cifrado reversible. Sin embargo, es posible almacenar el valor digerido del nombre de usuario, el dominio y la contraseña. [2]

    •   

Similar a: ¿Es BASIC-Auth seguro si se realiza a través de HTTPS?

    
pregunta Charles Offenbacher 28.03.2012 - 18:45
fuente

2 respuestas

6
  

La autenticación de acceso implícita está pensada como un compromiso de seguridad. Está destinado a reemplazar la autenticación de acceso básico HTTP sin cifrar.   Sin embargo, no pretende reemplazar la autenticación fuerte   Protocolos, como la clave pública o la autenticación Kerberos.

Al implementar SSL, está incorporando la autenticación de clave pública a la ecuación, por lo que está abordando ese problema. Cualquier cosa más fuerte que eso requeriría una infraestructura adicional que no sería práctica en muchas situaciones.

  

Muchas de las opciones de seguridad en RFC 2617 son opcionales. Si la calidad de protección (qop) no está especificada por el servidor, el cliente   operará en un modo RFC 2069 heredado con seguridad reducida.

Eso tiene que ver con la implementación y realmente no se aplica aquí.

  

La autenticación de acceso implícita es vulnerable a un ataque Man-in-the-middle (MitM). Por ejemplo, un atacante MitM podría decirle a los clientes que usen   Autenticación de acceso básico o acceso de compendio RFC2069 heredado   modo de autenticación. Para ampliar esto aún más, digerir el acceso   la autenticación no proporciona ningún mecanismo para que los clientes verifiquen la   identidad del servidor.

El uso de SSL reducirá en gran medida el riesgo de ataques MITM. Proporcionará el método para verificar la identidad del servidor. Sí, se puede falsificar un certificado, pero los navegadores web están mejorando la alerta a los usuarios sobre estos problemas.

  

Algunos servidores requieren que las contraseñas se almacenen utilizando un cifrado reversible. Sin embargo, es posible en su lugar almacenar el digerido.   valor del nombre de usuario, el dominio y la contraseña. [2]

Sí, no deberías estar haciendo eso de todos modos.

Entonces la respuesta es sí, SSL aborda las debilidades bastante bien. No es perfecto, pero el siguiente paso después de eso es bastante grande.

    
respondido por el Mark Burnett 30.03.2012 - 09:47
fuente
-1

Seguro que evitará problemas durante el tránsito, pero ¿qué ocurre con los servidores? ¿Por qué no usar SHA-1/2?

    
respondido por el Numpty 28.03.2012 - 20:32
fuente

Lea otras preguntas en las etiquetas

¿Cumple BitLocker en una máquina virtual FIPS 140-2 con nivel de seguridad 1? ¿Qué tan aislados están los archivos en una máquina virtual de VirtualBox desde el sistema de archivos del host?