Hispanopedia Wiki
Articulo de referencia

Autenticación de acceso resumido

La autenticación de acceso Digest es uno de los métodos acordados que un servidor web puede usar para negociar credenciales, como nombre de usuario o contraseña, con el navegado...

Hispanopedia WikiContenido en espanolLectura gratuita

La autenticación de acceso Digest es uno de los métodos acordados que un servidor web puede usar para negociar credenciales, como nombre de usuario o contraseña, con el navegador web de un usuario . Esto se puede usar 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. En cambio, la autenticación de acceso básica utiliza la codificación Base64, fácilmente reversible , en lugar de la función hash, lo que la hace insegura a menos que se use junto con TLS . [ 1 ]

Técnicamente, la autenticación digest es una aplicación del hash criptográfico que utiliza valores nonce para prevenir ataques de repetición . Utiliza el protocolo HTTP .

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

Descripción general

La autenticación de acceso Digest fue especificada originalmente por la RFC 2069 ( Una extensión de HTTP: Autenticación de acceso Digest ). La RFC 2069 especifica, a grandes rasgos, un esquema de autenticación Digest 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, method es el verbo del método HTTP y digestURI la URI a la que se accederá): 

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.

El RFC 2069 fue reemplazado posteriormente por el RFC 2617 ( Autenticación HTTP: Autenticación de acceso básica y digest ). El RFC 2617 introdujo varias mejoras de seguridad opcionales para la autenticación digest: "calidad de protección" (qop) , contador nonce incrementado por el cliente y un nonce aleatorio generado por el cliente. Estas mejoras están diseñadas para proteger contra, por ejemplo, el criptoanálisis de ataques de texto plano elegido . 

Si el valor de la directiva del algoritmo es " MD5 " o no está especificado, 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", entonces 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 demuestra que cuando no se especifica qop, se sigue el estándar RFC 2069, que es más sencillo.

En septiembre de 2015, el RFC 7616 reemplazó al 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 .

En octubre de 2021 Firefox 93 [ 3 ] implementó los algoritmos "SHA-256" y "SHA-256-sess" para la autenticación digest. Sin embargo, aún no se admite el uso de los algoritmos "SHA-512-256", "SHA-512-256-sess" ni el hash de nombres de usuario. [ 4 ]

En agosto de 2023 , Chromium 117 implementó "SHA-256" y "SHA-256-sess". [ 5 ] [ 6 ]

Impacto de la seguridad MD5 en la autenticación digest

Los cálculos MD5 utilizados en la autenticación HTTP digest están diseñados 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 es demasiado simple, entonces podría 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. [ 7 ]

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 hash de clave ( HMAC ). Aunque la construcción criptográfica utilizada 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 donde se desconocía el texto plano (es decir, la contraseña). [ 8 ] Sin embargo, algunas afirmaciones de 2006 [ 9 ] generan dudas sobre otras aplicaciones de MD5.

Consideraciones sobre la autenticación HTTP digest

Ventajas

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

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

  • La contraseña no se envía en texto plano al servidor.
  • La contraseña no se utiliza directamente en el resumen, sino que se usa HA1 = MD5(nombre de usuario:dominio:contraseña). Esto permite que algunas implementaciones (por ejemplo, JBoss [ 10 ] ) almacenen HA1 en lugar de la contraseña en texto plano (sin embargo, consulte las desventajas de este enfoque).
  • El nonce del cliente se introdujo en el RFC 2617, que permite al cliente prevenir ataques de texto plano elegido , como las tablas arcoíris que de otro modo podrían amenazar los esquemas de autenticación digest.
  • El nonce del servidor puede contener marcas de tiempo. Por lo tanto, el servidor puede inspeccionar los atributos del nonce enviados por los clientes para prevenir ataques de repetición.
  • El servidor también puede mantener una lista de valores nonce del servidor emitidos o utilizados recientemente para evitar la reutilización.
  • Previene el phishing porque la contraseña en texto plano nunca se envía a ningún servidor, sea este 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 mediante resumen presenta varios inconvenientes:

  • El sitio web no tiene control sobre la interfaz de usuario que se presenta al usuario final.
  • 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 heredado RFC 2069 con seguridad reducida.
  • La autenticación de acceso digest 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 digest RFC2069 heredado. Además, la autenticación de acceso digest no proporciona ningún mecanismo para que los clientes verifiquen la identidad del servidor.
  • Un servidor puede almacenar HA1 = MD5(nombre de usuario:dominio:contraseña) en lugar de la contraseña misma. Sin embargo, si el HA1 almacenado se filtra, un atacante puede generar respuestas válidas y acceder a documentos en el dominio con la misma facilidad que si tuviera acceso a la contraseña. Por lo tanto, la tabla de valores HA1 debe protegerse con la misma seguridad que un archivo que contiene contraseñas en texto plano. [ 11 ]
  • 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 los módulos criptográficos certificados por FIPS [ nota 1 ] .

Protocolos de autenticación alternativos

El método más común consiste en utilizar un protocolo de autenticación en texto plano basado en formularios HTTP+HTML o, más raramente , la autenticación básica de acceso (BAS) . Estos protocolos de texto plano, aunque débiles, combinados con el cifrado de red HTTPS , resuelven muchas de las amenazas que la autenticación de acceso digest está diseñada para prevenir. Sin embargo, este uso de HTTPS depende de que el usuario final valide correctamente que accede a la URL correcta cada vez para evitar enviar su contraseña a un servidor no confiable, lo que da lugar a ataques de phishing . Los usuarios a menudo no lo hacen, razón por la cual el phishing se ha convertido en la forma más común de brecha de seguridad.

Algunos protocolos de autenticación robustos para aplicaciones web que se utilizan ocasionalmente incluyen:

Ejemplo con explicación

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

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

  1. El cliente solicita una página que requiere autenticación, pero no proporciona nombre de usuario ni 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 dominio de autenticación y un valor de un solo uso generado aleatoriamente llamado nonce .
  3. En este punto, el navegador mostrará al usuario el dominio de autenticación (normalmente una descripción del ordenador o sistema al que se accede) y le pedirá que introduzca un nombre de usuario y una contraseña. El usuario puede optar por cancelar la operación en este momento.
  4. Una vez que se han proporcionado el nombre de usuario y la contraseña, el cliente reenvía la misma solicitud, pero agrega una cabecera de autenticación que incluye el código de respuesta.
  5. En este ejemplo, el servidor acepta la autenticación y devuelve la página. Si el nombre de usuario es inválido o la contraseña es incorrecta, el servidor podría devolver el código de respuesta "401" y el cliente volvería a solicitar la contraseña al usuario.
Solicitud del cliente (sin autenticación)
GET /dir/index.html HTTP / 1.0 Host : localhost

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

Respuesta del servidor
HTTP / 1.0 401 No autorizado Servidor : HTTPd/0.9 Fecha : dom., 10 abr. 2014 20:26:47 GMT WWW-Authenticate : Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type : text/html Content-Length : 153< ! DOCTYPE html > <html> <head> < meta charset = " UTF - 8 " / > <title> Error </title> </head> <body> <h1> 401 No autorizado . </h1> </body> </html>​​​​​​​​
Solicitud del cliente (nombre de usuario "Mufasa", contraseña "Circle Of Life")
GET /dir/index.html HTTP / 1.0 Host : localhost Authorization : Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="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 : texto/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 de la combinación del nombre de usuario, el dominio de autenticación y la contraseña. El resultado se denomina HA1.
  2. Se calcula el hash MD5 del URI"GET" combinado del método y el resumen, por ejemplo, de y "/dir/index.html". El resultado se denomina HA2.
  3. Se calcula el hash MD5 de la combinación del resultado HA1, el nonce del servidor (nonce), el contador de solicitud (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 verificar 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 mostradas no se utilizan en el cálculo.

Al completar el ejemplo proporcionado en RFC 2617, se obtienen los siguientes resultados para cada paso.

 HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" ) = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5( "GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366 Respuesta = MD5( "939e7578ed9e3c518a452acee763bce9:\ dcd98b7102dd2f0e8b11d0f600bfb0c093:\ 00000001:0a4f113b:auth:\ 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 las solicitudes subsiguientes, el contador de solicitud hexadecimal (nc) debe ser mayor que el último valor utilizado  ; de lo contrario, un atacante podría simplemente " repetir " una solicitud antigua con las mismas credenciales. Es responsabilidad del servidor garantizar que el contador aumente para cada uno de los valores nonce emitidos, rechazando adecuadamente cualquier solicitud incorrecta. 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 reenviar la solicitud con el nuevo nonce proporcionado, sin solicitar al usuario otro nombre de usuario y contraseña.

El servidor no necesita conservar ningún valor nonce caducado  ; simplemente puede asumir que cualquier valor no reconocido ha caducado. También es posible que el servidor permita que cada valor nonce se devuelva solo una vez, aunque esto obliga al cliente a repetir cada solicitud. Cabe destacar que hacer que un valor nonce del servidor caduque inmediatamente no funcionará, ya que el cliente nunca tendría la oportunidad de usarlo.

El archivo .htdigest

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

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

La sintaxis del comando htdigest: [ 16 ]

htdigest [ -c ] passwdfile reino nombre de usuario

Formato del archivo .htdigest: [ 16 ]

usuario1: Reino: 5ea41921c65387d904834f8403185412 usuario2: Reino:734418f1e487083dc153890208b79379

autenticación SIP digest

El Protocolo de Inicio de Sesión (SIP) utiliza básicamente el mismo algoritmo de autenticación digest. Está especificado en el 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 comprobación de auth-int o el algoritmo MD5-sess. Si el servidor requiere que se gestionen estas funciones opcionales, es posible que los clientes no puedan autenticarse (si bien cabe señalar que mod_auth_digest para Apache tampoco implementa completamente la RFC 2617).

Desuso

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

Véase también

Notas

  1. ↑ A continuación se presenta 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 necesarios sin necesidad de solicitarlos al usuario, por ejemplo, si un navegador web los ha almacenado previamente.

Referencias

  1. ↑ "RFC 7616: Autenticación de acceso HTTP Digest" . IETF Datatracker . Consultado el 19 de enero de 2026 .
  2. ↑ Trasladar DIGEST-MD5 a la sección Histórica, julio de 2011 .
  3. ↑ "Error 472823: Autenticación SHA 256 Digest" . Mozilla Bugzilla .
  4. ↑ "Mozilla-central: admite la autenticación HTTP Digest SHA-256" . Mozilla-central .
  5. ↑ "Función de Chrome: Autenticación Digest RFC 7616: Compatibilidad con SHA-256 y hash de nombre de usuario" .
  6. 1 2 Deomid "rojer" Ryabkov (27-07-2023). "RFC 7616 Autenticación de resumen HTTP: Añadir soporte para SHA-256 y hash de nombre de usuario" . Chromium (navegador web) .
  7. ↑ Lista de tablas arcoíris, Proyecto Rainbowcrack . Incluye múltiples tablas arcoíris MD5.
  8. ↑ "Preguntas y respuestas sobre colisiones de hash" . Investigación en criptografía . 16 de febrero de 2005. Archivado del original el 6 de marzo de 2010.
  9. ↑ Jongsung Kim; Alex Biryukov; Bart Preneel; Seokhie Hong. "Sobre la seguridad de HMAC y NMAC basada en HAVAL, MD4, MD5, SHA-0 y SHA-1" (PDF) . IACR .
  10. ↑ Scott Stark (08-10-2005). "Autenticación DIGEST (4.0.4+)" . JBoss . Archivado del original el 18-10-2015 . Recuperado el 04-03-2013 .
  11. ↑ 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ásico y resumen: almacenamiento de contraseñas" . IETF . doi : 10.17487/RFC2617 . S2CID 27137261 . {{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  12. ↑ "RFC 2617: Autenticación HTTP: Autenticación de acceso básica y digest" . Editor de RFC . Consultado el 19 de enero de 2026 .
  13. ↑ "Autenticación Digest" . Documentación del servidor HTTP Apache . Consultado el 19 de enero de 2026 .
  14. ↑ "RFC 2617: Autenticación HTTP: Autenticación de acceso básica y digest" . Editor de RFC . Consultado el 19 de enero de 2026 .
  15. ↑ Tim Berners-Lee , Roy Fielding , Henrik Frystyk Nielsen (1996-02-19). "Protocolo de transferencia de hipertexto -- HTTP/1.0: Solicitud" . W3C .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  16. 1 2 "htdigest - gestionar archivos de usuario para autenticación digest" . apache.org .
  17. ↑ Emanuel Corthay (16 de septiembre de 2002). "Bug 168942 - Autenticación Digest con protección de integridad" . Mozilla .
  18. ↑ Timothy D. Morgan (5 de enero de 2010). "Integridad del resumen HTTP: una nueva perspectiva a la luz de los recientes ataques" (PDF) . vsecurity.com. Archivado del original (PDF) el 14 de julio de 2014.
  19. ↑ "Autenticación de TechNet Digest" . Agosto de 2013.
  20. ↑ Anthony, Sebastian (13 de febrero de 2013). "La ópera admite la derrota y se pasa a Chromium de Google" . Extreme Tech . Ziff Davis . Consultado el 19 de enero de 2024 .
  21. ↑ DeLorenzo, Ike (2015-04-03). "Adiós, autenticación de acceso Digest" . Bitbucet . Archivado del original el 23-04-2024 . Recuperado el 21-01-2025 .
  22. ↑ " [ RFC ] Desaprobar la autenticación HTTP Digest · Problema n.° 24325 · symfony/symfony" . GitHub . Archivado del original el 12/10/2023 . Recuperado el 21/01/2025 .
  • RFC 7616
  • RFC 7235
  • RFC 6331
  • RFC 2617 (actualizado por RFC 7235)
  • RFC 2069 (obsoleto)