Autenticación de acceso mediante resumen
Método de negociación de credenciales entre el servidor web y el navegador
HTTP
Métodos de solicitud
Campos de encabezado
Códigos de estado de respuesta
Métodos de control de acceso de seguridad
Vulnerabilidades de seguridad

La autenticación de acceso mediante resumen es uno de los métodos acordados que un servidor web puede utilizar para negociar credenciales, como el nombre de usuario o la contraseña, con el navegador web de un usuario . Esto se puede utilizar para confirmar la identidad de un usuario antes de enviar información confidencial, como el historial de transacciones bancarias en línea. Aplica una función hash al nombre de usuario y la contraseña antes de enviarlos a través de la red. Por el contrario, la autenticación de acceso básica utiliza la codificación Base64 fácilmente reversible en lugar de hash, lo que la hace no segura a menos que se utilice junto con TLS .

Técnicamente, la autenticación implícita es una aplicación de hash criptográfico con el uso de valores nonce para evitar ataques de repetición . Utiliza el protocolo HTTP .

DIGEST-MD5 como mecanismo SASL especificado por RFC  2831 está obsoleto desde julio de 2011. [1]

Descripción general

La autenticación de acceso mediante resumen se especificó originalmente en RFC  2069 ( An Extension to HTTP: Digest Access Authentication ). RFC 2069 especifica aproximadamente un esquema de autenticación mediante resumen tradicional con seguridad mantenida por un valor nonce generado por el servidor . La respuesta de autenticación se forma de la siguiente manera (donde HA1 y HA2 son nombres de variables de cadena):

HA1 = MD5(nombre de usuario:dominio:contraseña)HA2 = MD5(método:digestURI)respuesta = MD5(HA1:nonce:HA2)

Un hash MD5 es un valor de 16 bytes. Los valores HA1 y HA2 utilizados en el cálculo de la respuesta son la representación hexadecimal (en minúsculas) de los hashes MD5 respectivamente.

RFC 2069 fue posteriormente reemplazada por RFC  2617 ( Autenticación HTTP: autenticación básica y de acceso implícito ). RFC 2617 introdujo una serie de mejoras de seguridad opcionales para la autenticación implícita; "calidad de protección" (qop) , contador de nonce incrementado por el cliente y un nonce aleatorio generado por el cliente. Estas mejoras están diseñadas para proteger contra, por ejemplo, ataques de texto simple elegido criptoanálisis .

Si el valor de la directiva del algoritmo es "MD5" o no se especifica, entonces HA1 es

HA1 = MD5(nombre de usuario:dominio:contraseña)

Si el valor de la directiva del algoritmo es "MD5-sess", entonces HA1 es

HA1 = MD5(MD5(nombre de usuario:dominio:contraseña):nonce:cnonce)

Si el valor de la directiva qop es "auth" o no está especificado, entonces HA2 es

HA2 = MD5(método:digestURI)

Si el valor de la directiva qop es "auth-int", entonces HA2 es

HA2 = MD5(método:digestURI:MD5(entityBody))

Si el valor de la directiva qop es "auth" o "auth-int", calcule la respuesta de la siguiente manera:

respuesta = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

Si no se especifica la directiva qop, calcule la respuesta de la siguiente manera:

respuesta = MD5(HA1:nonce:HA2)

Lo anterior muestra que cuando no se especifica qop, se sigue el estándar más simple RFC 2069.

En septiembre de 2015, la RFC 7616 reemplazó a la RFC 2617 al agregar 4 nuevos algoritmos : "SHA-256", "SHA-256-sess", "SHA-512-256" y "SHA-512-256-sess". La codificación es equivalente a los algoritmos "MD5" y "MD5-sess", con la función hash MD5 reemplazada por SHA-256 y SHA-512-256 . Sin embargo, a julio de 2021 [actualizar], ninguno de los navegadores populares, incluidos Firefox [2] y Chrome, [3] admite SHA-256 como función hash. A partir de octubre de 2021 [actualizar], Firefox 93 [4] admite oficialmente los algoritmos "SHA-256" y "SHA-256-sess" para la autenticación de resumen. Sin embargo, aún falta compatibilidad con los algoritmos "SHA-512-256", "SHA-512-256-sess" y el hash de nombres de usuario [5] . [6] A partir de agosto de 2023 [actualizar], Chromium 117 (en ese entonces Chrome y Edge) es compatible con "SHA-256". [7]

Impacto de la seguridad MD5 en la autenticación de resumen

Los cálculos MD5 utilizados en la autenticación de resumen HTTP están pensados ​​para ser " unidireccionales ", lo que significa que debería ser difícil determinar la entrada original cuando solo se conoce la salida. Sin embargo, si la contraseña en sí es demasiado simple, entonces puede ser posible probar todas las entradas posibles y encontrar una salida coincidente (un ataque de fuerza bruta ), tal vez con la ayuda de un diccionario o una lista de búsqueda adecuada , que para MD5 está fácilmente disponible. [8]

El esquema HTTP fue diseñado por Phillip Hallam-Baker en el CERN en 1993 y no incorpora mejoras posteriores en los sistemas de autenticación, como el desarrollo del código de autenticación de mensajes con clave hash ( HMAC ). Aunque la construcción criptográfica que se utiliza se basa en la función hash MD5, en 2004 se creía generalmente que los ataques de colisión no afectaban a las aplicaciones en las que no se conoce el texto simple (es decir, la contraseña). [9] Sin embargo, las afirmaciones de 2006 [10] también provocan algunas dudas sobre otras aplicaciones MD5.

Consideraciones sobre la autenticación mediante compendio HTTP

Ventajas

La autenticación de resumen HTTP está diseñada para ser más segura que los esquemas de autenticación de resumen tradicionales, por ejemplo, "significativamente más fuerte que (por ejemplo) CRAM-MD5 ..." (RFC 2617).

Algunas de las ventajas de seguridad de la autenticación mediante resumen HTTP son:

  • La contraseña no se envía clara al servidor.
  • La contraseña no se utiliza directamente en el resumen, sino que se usa HA1 = MD5(nombreusuario:dominio:contraseña). Esto permite que algunas implementaciones (por ejemplo, JBoss [11] ) almacenen HA1 en lugar de la contraseña en texto simple (sin embargo, consulte las desventajas de este enfoque) .
  • El nonce del cliente se introdujo en RFC 2617, lo que permite al cliente evitar ataques de texto simple elegido , como las tablas arco iris que de otro modo podrían amenazar los esquemas de autenticación de resumen.
  • Se permite que el nonce del servidor contenga marcas de tiempo. Por lo tanto, el servidor puede inspeccionar los atributos nonce enviados por los clientes para evitar ataques de repetición.
  • El servidor también puede mantener una lista de valores nonce del servidor emitidos o utilizados recientemente para evitar su reutilización.
  • Previene el phishing porque la contraseña simple nunca se envía a ningún servidor, sea el correcto o no. (Los sistemas de clave pública dependen de que el usuario pueda verificar que la URL es correcta).

Desventajas

La autenticación de acceso resumido presenta varias desventajas:

  • El sitio web no tiene control sobre la interfaz de usuario presentada al usuario final.
  • Muchas de las opciones de seguridad de RFC 2617 son opcionales. Si el servidor no especifica la calidad de protección (qop), el cliente funcionará en un modo de seguridad reducida según el legado de RFC 2069.
  • La autenticación de acceso implícita es vulnerable a un ataque de intermediario (MITM) . Por ejemplo, un atacante MITM podría indicar a los clientes que utilicen la autenticación de acceso básica o el modo de autenticación de acceso implícita RFC2069 heredado. Para ampliar esto aún más, la autenticación de acceso implícita no proporciona ningún mecanismo para que los clientes verifiquen la identidad del servidor.
  • Un servidor puede almacenar HA1 = MD5(nombreusuario:dominio:contraseña) en lugar de la contraseña misma. Sin embargo, si se filtra el HA1 almacenado, un atacante puede generar respuestas válidas y acceder a los documentos del dominio con la misma facilidad que si tuviera acceso a la contraseña misma. Por lo tanto, la tabla de valores HA1 debe protegerse de forma tan segura como un archivo que contenga contraseñas en texto sin formato. [12]
  • La autenticación de acceso mediante resumen evita el uso de un hash de contraseña seguro (como bcrypt ) al almacenar contraseñas (ya que la contraseña o el nombre de usuario, el dominio y la contraseña resumidos deben ser recuperables)

Además, dado que el algoritmo MD5 no está permitido en FIPS , la autenticación HTTP Digest no funcionará con módulos criptográficos certificados por FIPS [nota 1] .

Protocolos de autenticación alternativos

El método más común es utilizar un protocolo de texto sin formato basado en formularios HTTP+HTML o, más raramente, la autenticación de acceso básica . Estos protocolos de texto sin formato débiles utilizados junto con el cifrado de red HTTPS resuelven muchas de las amenazas que la autenticación de acceso resumido está diseñada para prevenir. Sin embargo, este uso de HTTPS depende de que el usuario final valide con precisión que está accediendo a la URL correcta cada vez para evitar enviar su contraseña a un servidor que no es de confianza, lo que da lugar a ataques de phishing . Los usuarios a menudo no lo hacen, por lo que el phishing se ha convertido en la forma más común de violación de la seguridad.

Algunos protocolos de autenticación fuertes para aplicaciones basadas en web que se utilizan ocasionalmente incluyen:

Ejemplo con explicación

El siguiente ejemplo se proporcionó originalmente en RFC 2617 y se amplía aquí para mostrar el texto completo esperado para cada solicitud y respuesta . Tenga en cuenta que solo se cubre la calidad "auth" (autenticación) del código de protección; a partir de abril de 2005 [actualizar], solo se sabe que los navegadores web Opera y Konqueror admiten "auth-int" (autenticación con protección de integridad). [ cita requerida ] Aunque la especificación menciona la versión 1.1 de HTTP, el esquema se puede agregar correctamente a un servidor de la versión 1.0, como se muestra aquí.

Esta transacción típica consta de los siguientes pasos:

  1. El cliente solicita una página que requiere autenticación pero no proporciona un nombre de usuario ni una contraseña. [nota 2] Normalmente, esto se debe a que el usuario simplemente ingresó la dirección o siguió un enlace a la página.
  2. El servidor responde con el código de respuesta 401 "No autorizado" , proporcionando el ámbito de autenticación y un valor de uso único generado aleatoriamente llamado nonce .
  3. En este punto, el navegador presentará al usuario el ámbito de autenticación (normalmente una descripción de la computadora o el sistema al que se accede) y le solicitará un nombre de usuario y una contraseña. El usuario puede decidir cancelar en este punto.
  4. Una vez que se han proporcionado un nombre de usuario y una contraseña, el cliente vuelve a enviar la misma solicitud pero agrega un encabezado de autenticación que incluye el código de respuesta.
  5. En este ejemplo, el servidor acepta la autenticación y se devuelve la página. Si el nombre de usuario no es válido o la contraseña es incorrecta, el servidor podría devolver el código de respuesta "401" y el cliente volvería a preguntar al usuario.
Solicitud del cliente (sin autenticación)
OBTENER  /dir/index.html  HTTP / 1.0 Host :  localhost

(seguido de una nueva línea , en forma de un retorno de carro seguido de un salto de línea ). [13]

Respuesta del servidor
HTTP / 1.0  401  Servidor no autorizado : HTTPd/0.9 Fecha : dom., 10 abr. 2014 20:26:47 GMT WWW-Authenticate : Digest realm="[email protected]", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Tipo de contenido : text/html Longitud del contenido : 153        <!DOCTYPE html> < html >  < head >  < meta  charset = "UTF-8"  />  < title > Error </ title >  </ head >  < body >  < h1 > 401 No autorizado. </ h1 >  </ body > </ html >
Solicitud de cliente (nombre de usuario "Mufasa", contraseña "Circle Of Life")
GET  /dir/index.html  HTTP / 1.0 Host :  localhost Autorización :  Digest nombre de usuario="Mufasa",  reino="[email protected]",  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",  uri="/dir/index.html",  qop=auth,  nc=00000001,  cnonce="0a4f113b",  respuesta="6629fae49393a05397450978507c4ef1",  opaco="5ccc069c403ebaf9f0171e9517f40e41"

(seguido de una línea en blanco, como antes).

Respuesta del servidor
HTTP / 1.0  200  OK Servidor :  HTTPd/0.9 Fecha :  dom, 10 abr 2005 20:27:03 GMT Tipo de contenido :  text/html Longitud del contenido :  7984

(seguido de una línea en blanco y el texto HTML de la página restringida).

El valor de "respuesta" se calcula en tres pasos, como se indica a continuación. Cuando se combinan valores, se delimitan con dos puntos.

  1. Se calcula el hash MD5 del nombre de usuario, el dominio de autenticación y la contraseña combinados. El resultado se denomina HA1.
  2. Se calcula el hash MD5 del método combinado y el URI"GET" de resumen, p. ej. de y "/dir/index.html". El resultado se denomina HA2.
  3. Se calcula el hash MD5 del resultado HA1 combinado, el nonce del servidor (nonce), el contador de solicitudes (nc), el nonce del cliente (cnonce), el código de calidad de protección (qop) y el resultado HA2. El resultado es el valor de "respuesta" proporcionado por el cliente.

Dado que el servidor tiene la misma información que el cliente, la respuesta se puede comprobar realizando el mismo cálculo. En el ejemplo anterior, el resultado se forma de la siguiente manera, donde MD5()representa una función utilizada para calcular un hash MD5 , las barras invertidas representan una continuación y las comillas que se muestran no se utilizan en el cálculo.

Completar el ejemplo dado en RFC 2617 da los siguientes resultados para cada paso.

 HA1 = MD5("Mufasa:[email protected]:Círculo de la vida") = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5("GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366 Respuesta = MD5("939e7578ed9e3c518a452acee763bce9:\ dcd98b7102dd2f0e8b11d0f600bfb0c093:\ 00000001:0a4f113b:autenticación:\ 39aff3a2bab6126f332b942af96d3366") = 6629fae49393a05397450978507c4ef1

En este punto, el cliente puede realizar otra solicitud, reutilizando el valor nonce del servidor (el servidor solo emite un nuevo nonce para cada respuesta "401" ) pero proporcionando un nuevo nonce de cliente (cnonce). Para solicitudes posteriores, el contador de solicitudes hexadecimal (nc) debe ser mayor que el último valor que utilizó; de lo contrario, un atacante podría simplemente " reproducir " una solicitud anterior con las mismas credenciales. Depende del servidor asegurarse de que el contador aumente para cada uno de los valores nonce que ha emitido, rechazando cualquier solicitud incorrecta de manera apropiada. Obviamente, cambiar el método, la URI o el valor del contador dará como resultado un valor de respuesta diferente.

El servidor debe recordar los valores nonce que ha generado recientemente. También puede recordar cuándo se emitió cada valor nonce, haciéndolos caducar después de un cierto tiempo. Si se utiliza un valor caducado, el servidor debe responder con el código de estado "401" y agregarlo stale=TRUEal encabezado de autenticación, indicando que el cliente debe volver a enviar con el nuevo nonce proporcionado, sin solicitarle al usuario otro nombre de usuario y contraseña.

El servidor no necesita conservar ningún valor nonce vencido; simplemente puede asumir que todos los valores no reconocidos han vencido. También es posible que el servidor solo permita que cada valor nonce se devuelva una vez, aunque esto obliga al cliente a repetir cada solicitud. Tenga en cuenta que hacer que un valor nonce del servidor caduque inmediatamente no funcionará, ya que el cliente nunca tendrá la oportunidad de usarlo.

El archivo .htdigest

.htdigest es un archivo plano que se utiliza para almacenar nombres de usuario, dominios y contraseñas para la autenticación resumida del servidor HTTP Apache . El nombre del archivo se proporciona en la configuración de .htaccess y puede ser cualquier cosa, pero ".htdigest" es el nombre canónico. El nombre del archivo comienza con un punto, porque la mayoría de los sistemas operativos tipo Unix consideran que cualquier archivo que comience con un punto está oculto. Este archivo se suele mantener con el comando de shell "htdigest", que puede agregar y actualizar usuarios, y codificará correctamente la contraseña para su uso.

El comando "htdigest" se encuentra en el paquete apache2-utils en los sistemas de administración de paquetes dpkg y en el paquete httpd-tools en los sistemas de administración de paquetes RPM .

La sintaxis del comando htdigest: [14]

htdigest [ -c ] passwdfile nombre de usuario del reino

El formato del archivo .htdigest: [14]

usuario1:Reino:5ea41921c65387d904834f8403185412usuario2:Reino:734418f1e487083dc153890208b79379

Autenticación de resumen SIP

El protocolo de inicio de sesión (SIP) utiliza básicamente el mismo algoritmo de autenticación resumida, especificado en RFC 3261.

Implementación del navegador

La mayoría de los navegadores han implementado sustancialmente la especificación, aunque algunos excluyen ciertas funciones como la verificación de autenticación int o el algoritmo MD5-sess. Si el servidor requiere que se gestionen estas funciones opcionales, es posible que los clientes no puedan autenticarse (aunque tenga en cuenta que mod_auth_digest para Apache tampoco implementa completamente RFC 2617).

Desusos

Debido a las desventajas de la autenticación Digest en comparación con la autenticación básica a través de HTTPS, muchos programas la han dejado obsoleta, por ejemplo:

  • Bitbucket: https://bitbucket.org/blog/fare-thee-well-digest-access-authentication
  • Marco PHP Symfony: https://github.com/symfony/symfony/issues/24325

Véase también

Notas

  1. ^ A continuación se incluye una lista de algoritmos aprobados por FIPS: "Anexo A: Funciones de seguridad aprobadas para FIPS PUB 140-2, Requisitos de seguridad para módulos criptográficos" (PDF) . Instituto Nacional de Estándares y Tecnología. 31 de enero de 2014.
  2. ^ Es posible que un cliente ya tenga el nombre de usuario y la contraseña requeridos sin necesidad de solicitarlos al usuario, por ejemplo, si han sido almacenados previamente por un navegador web.

Referencias

  1. ^ Trasladando DIGEST-MD5 a Histórico, julio de 2011.
  2. ^ "Error 472823: autenticación de resumen SHA 256". Bugzilla de Mozilla .
  3. ^ "Problema 1160478: SHA-256 para autenticación de acceso HTTP Digest de acuerdo con rfc7616". Errores de Chromium .
  4. ^ "Error 472823: autenticación de resumen SHA 256". Bugzilla de Mozilla .
  5. ^ "IETF.org: RFC 7616 Hashing de nombres de usuario". Ietf Datatracker . 30 de septiembre de 2015.
  6. ^ "Mozilla-central: compatibilidad con autenticación SHA-256 HTTP Digest". Mozilla-central .
  7. ^ "Función de Chrome: autenticación de resumen RFC 7616: compatibilidad con SHA-256 y hash de nombre de usuario".
  8. ^ Lista de tablas arcoíris, Proyecto Rainbowcrack. Incluye varias tablas arcoíris MD5.
  9. ^ "Preguntas y respuestas sobre colisiones de hash". Investigación criptográfica . 16 de febrero de 2005. Archivado desde el original el 6 de marzo de 2010.[ Se necesita una mejor fuente ]
  10. ^ Jongsung Kim; Alex Biryukov; Bart Preneel; Seokhie Hong. "Sobre la seguridad de HMAC y NMAC basados ​​en HAVAL, MD4, MD5, SHA-0 y SHA-1" (PDF) . IACR .
  11. ^ Scott Stark (8 de octubre de 2005). «Autenticación DIGEST (4.0.4+)». JBoss . Archivado desde el original el 18 de octubre de 2015. Consultado el 4 de marzo de 2013 .
  12. ^ Franks, J.; Hallam-Baker, P.; Hostetler, J.; Lawrence, S.; Leach, P.; Luotonen, A.; Stewart, L. (junio de 1999). "Autenticación HTTP: autenticación de acceso básica y resumida: almacenamiento de contraseñas". IETF . doi :10.17487/RFC2617. S2CID  27137261. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  13. ^ Tim Berners-Lee , Roy Fielding , Henrik Frystyk Nielsen (19 de febrero de 1996). "Protocolo de transferencia de hipertexto -- HTTP/1.0: Solicitud". W3C .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  14. ^ ab "htdigest - administra archivos de usuario para autenticación de resumen". apache.org .
  15. ^ Emanuel Corthay (16 de septiembre de 2002). "Error 168942: autenticación implícita con protección de integridad". Mozilla .
  16. ^ Timothy D. Morgan (5 de enero de 2010). "Integridad de HTTP Digest: otra mirada, a la luz de los ataques recientes" (PDF) . vsecurity.com. Archivado desde el original (PDF) el 14 de julio de 2014.
  17. ^ "Autenticación de TechNet Digest". Agosto de 2013.
  18. ^ Anthony, Sebastian (13 de febrero de 2013). «Opera admite la derrota y cambia a Chromium de Google». Extreme Tech . Ziff Davis . Consultado el 19 de enero de 2024 .
  • RFC 7235
  • RFC 6331
  • RFC 2617 (actualizado por RFC 7235)
  • RFC 2069 (obsoleto)
Obtenido de "https://es.wikipedia.org/w/index.php?title=Autenticación_de_acceso_digest&oldid=1248550796"