¿Por qué no hay adopción de RFC 7616 (Autenticación de resumen HTTP)?

7

El sucesor de RFC 2617 agrega soporte para SHA-256 en lugar de MD5 y hace que el campo qop sea obligatorio, lo que hace que la autenticación sea más segura.

Sin embargo, ningún navegador / cliente principal (Edge, FF, Chrome, Opera, curl) lo admite.

Eso es un poco extraño para mí ya que, por lo general, los proveedores de navegadores son bastante activos cuando se trata de mejores estándares de seguridad.

¿Por qué es esto? ¿Me estoy perdiendo algo aquí?

    
pregunta eckes 04.03.2017 - 07:43
fuente

2 respuestas

8

La mayoría de los sitios no utilizan ninguno de los mecanismos de autenticación HTTP, es decir, Autenticación básica o Autenticación de resumen basada en MD5, porque estos mecanismos son muy limitados en lo que ofrecen. Ni siquiera es posible cerrar la sesión usando estos mecanismos de autenticación.

Pero incluso los pocos sitios que utilizan la autenticación HTTP suelen preferir la autenticación básica a través de HTTPS en lugar de la autenticación de resumen, ya que el último requiere que las contraseñas se almacenen en el servidor como texto plano o equivalente, lo que por supuesto es incorrecto desde un punto de vista de seguridad. perspectiva.

Por lo tanto, la única ventaja de la autenticación de resumen con otras formas de autenticación es si se utiliza con conexiones no cifradas. En todos los demás casos, es peor que las otras formas establecidas de autenticación. Pero, cualquier tipo de inicio de sesión en conexiones inseguras se considera malo de todos modos hoy. Por lo tanto, no es necesario mejorar levemente un mecanismo de autenticación ya defectuoso sin abordar los problemas básicos de la misma, es decir, el almacenamiento necesario de texto sin formato (o texto sin formato equivalente) de la contraseña.

Aparte de eso, las debilidades de MD5 como una mala resistencia contra ataques de colisión y ataques de pre imagen no afectan realmente su uso en la autenticación Digest, es decir, aún es adecuada para este caso de uso cuando se usa junto con un servidor aleatorio adecuado nonce definido.

    
respondido por el Steffen Ullrich 04.03.2017 - 10:24
fuente
2

Ese es un gran hallazgo, no estaba al tanto del Compendio HTTP con el hashing SHA

HTTP Digest es genial porque:

  • es fácil de configurar [ 1 ]
  • el método hash está documentado oficialmente
  • nunca necesita almacenar la contraseña del usuario, solo la 'H (A1)' [ 3 ].
  • por lo tanto, no puedes arruinarlo

La autenticación HTTPS + Basic no es tan buena:

  • la configuración adecuada es difícil y costosa [ 2 ]
  • barrera de entrada para los novatos, que terminan teniendo que confiar en los proveedores de SSL
  • centralizado, puede habilitar indagaciones indetectables por parte de un CA deshonesto
  • proporciona una falsa sensación de seguridad
  • no hay una guía general sobre cómo almacenar las credenciales de forma segura

La razón potencial es que quieren consolidar el control de la web, ya que la emisión del certificado SSL está centralizada.

Si desea la mejor seguridad, use HTTPS Y HTTP Digest al mismo tiempo. Y DEBE animar a los proveedores a implementar la última RFC.

    
respondido por el Scala William 05.06.2017 - 01:04
fuente

Lea otras preguntas en las etiquetas