Autenticación de acceso con resumen

La autenticación de acceso con resumen 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 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, por lo que no es segura a menos que se utilice junto con TLS.

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

Visión general

La autenticación de acceso implícita se especificó originalmente en RFC 2069 (una extensión de HTTP: autenticación de acceso implícita). RFC 2069 especifica aproximadamente un esquema de autenticación implícita 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 reemplazado más tarde por RFC 2617 (Autenticación HTTP: autenticación de acceso básica y implícita). RFC 2617 introdujo una serie de mejoras de seguridad opcionales para digerir la autenticación; "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, el criptoanálisis de ataque de texto sin formato elegido.

Si el valor de la directiva del algoritmo es "MD5" o no 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:reino:contraseña):nonce:cnonce)

Si el valor de la directiva qop es "auth" o no se especifica, 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 RFC 2069 más simple.

En septiembre de 2015, RFC 7616 reemplazó a 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 partir de julio de 2021, ninguno de los navegadores populares, incluidos Firefox y Chrome, admiten SHA-256 como función hash. A partir de octubre de 2021, Firefox 93 admite oficialmente los algoritmos "SHA-256" y "SHA-256-sess" para la autenticación implícita. Sin embargo, todavía falta soporte para los algoritmos "SHA-512-256", "SHA-512-256-sess" y el hash de nombre de usuario.

Impacto de la seguridad MD5 en la autenticación implícita

Los cálculos MD5 utilizados en la autenticación de resumen HTTP están destinados a 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, es 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 es fácil. disponible.

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 hash con clave (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 conocía el texto sin formato (es decir, la contraseña). Sin embargo, las afirmaciones de 2006 también generan dudas sobre otras aplicaciones de MD5. Sin embargo, hasta ahora, no se ha demostrado que los ataques de colisión MD5 representen una amenaza para la autenticación digerida, y el RFC 2617 permite a los servidores implementar mecanismos para detectar algunos ataques de colisión y reproducción.

Consideraciones sobre la autenticación de resumen HTTP

Ventajas

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

Algunas de las fortalezas de seguridad de la autenticación implícita de HTTP son:

• La contraseña no se envía clara al servidor.
• La contraseña no se usa directamente en el resumen, sino HA1 = MD5 (nombre de usuario: reino: contraseña). Esto permite que algunas implementaciones (por ejemplo, JBoss) almacenen HA1 en lugar de la contraseña de texto simple (sin embargo, vea las desventajas de este enfoque)
• Client nonce se introdujo en RFC 2617, lo que permite al cliente evitar ataques de texto sin formato elegido, como las tablas de arcoíris que, de lo contrario, podrían amenazar los esquemas de autenticación implícita.
• El servidor nonce puede contener marcas de tiempo. Por lo tanto, el servidor puede inspeccionar los atributos nonce enviados por los clientes para evitar ataques de reproducción.
• El servidor también puede mantener una lista de valores nonce de servidor recientemente emitidos o usados ​​para evitar la reutilización.
• Evita el phishing porque la contraseña simple nunca se envía a ningún servidor, sea el servidor correcto o no. (Los sistemas de clave pública dependen de que el usuario pueda verificar que la URL es correcta).

Desventajas

Hay varios inconvenientes con la autenticación de acceso implícita:

• El sitio web no tiene control sobre la interfaz de usuario presentada 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 RFC 2069 heredado con seguridad reducida
• La autenticación de acceso implícita es vulnerable a un ataque de intermediario (MITM). Por ejemplo, un atacante MITM podría decirles a los clientes que usen la autenticación de acceso básica o el modo de autenticación de acceso resumido RFC2069 heredado. Para extender 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 (nombre de usuario: dominio: contraseña) en lugar de la contraseña en sí. Sin embargo, si se filtra el HA1 almacenado, 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 misma. Por lo tanto, la tabla de valores HA1 debe protegerse con la misma seguridad que un archivo que contiene contraseñas de texto sin formato.
• La autenticación de acceso Digest 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 digeridos 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.

Protocolos de autenticación alternativos

Con mucho, el enfoque más común es utilizar un protocolo de texto claro de autenticación basado en formularios HTTP+HTML o, más raramente, autenticación de acceso básico. Estos protocolos débiles de texto sin cifrar que se usan junto con el cifrado de red HTTPS resuelven muchas de las amenazas que la autenticación de acceso digerida 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 resulta en 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 sólidos para aplicaciones basadas en web que se usan ocasionalmente incluyen:

• Autenticación de clave pública (normalmente implementada con un certificado de cliente HTTPS/SSL) utilizando un certificado de cliente.
• Autenticación Kerberos o SPNEGO, empleada por ejemplo por Microsoft IIS que se ejecuta configurado para la autenticación integrada de Windows (IWA).
• Protocolo Secure Remote Password (preferiblemente dentro de la capa HTTPS/TLS). Sin embargo, esto no está implementado por ningún navegador convencional.
• JSON Web Token (JWT) es un RFC 7519 estándar basado en JSON para crear tokens de acceso que afirman una cierta cantidad de reclamos.

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, solo se sabe que los navegadores web Opera y Konqueror admiten "auth-int" (autenticación con protección de integridad). Aunque la especificación menciona la versión 1.1 de HTTP, el esquema se puede agregar con éxito 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 y contraseña. Por lo general, 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 denominado nonce.
3. En este punto, el navegador presentará el dominio de autenticación (generalmente una descripción de la computadora o el sistema al que se accede) al usuario y le solicitará un nombre de usuario y una contraseña. El usuario puede decidir cancelar en este punto.
4. Una vez que se ha 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 y/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 de cliente (sin autenticación)

OBTENER  /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).Respuesta del servidor

HTTP / 1.0  401  Servidor no autorizado 
: HTTPd/0.9 Fecha: domingo, 10 de abril de 2014 20:26:47 GMT WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce= "dcd98b7102dd2f0e8b11d0f600bfb0c093", opaco="5ccc069c403ebaf9f0171e9517f40e41" Tipo de contenido: texto/html Longitud del contenido: 153 
 
 
                        
                        
                        
 
 

<!DOCTYPE html> 
< html > 
  < cabeza > 
    < juego de caracteres meta  = "UTF-8" /> < título > Error </ título > </ cabeza > < cuerpo > < h1 > 401 No autorizado. </ h1 > </ cuerpo > </ html > 
    
  
  
    
  

Solicitud de cliente (nombre de usuario "Mufasa", contraseña "Circle Of Life")

OBTENER  /dir/index.html  HTTP / 1.0 
Host:  localhost 
Autorización:  Digest nombre de usuario="Mufasa", 
                     realm="testrealm@host.com", 
                     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:  domingo, 10 de abril de 2005 20:27:03 GMT 
Tipo de contenido:  text/html 
Longitud de contenido:  7984

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

---

El valor de "respuesta" se calcula en tres pasos, como sigue. Cuando se combinan valores, se delimitan con dos puntos.

1. Se calcula el hash MD5 del nombre de usuario combinado, el dominio de autenticación y la contraseña. El resultado se denomina HA1.
2. Se calcula el hash MD5 del método combinado y el URI de resumen, por ejemplo, de "GET"y "/dir/index.html". El resultado se denomina HA2.
3. Se calcula el hash MD5 del resultado HA1 combinado, el servidor nonce (nonce), el contador de solicitudes (nc), el cliente nonce (cnonce), la calidad del código 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:testrealm@host.com:Círculo de la vida")
       = 939e7578ed9e3c518a452acee763bce9

   HA2 = MD5("OBTENER:/dir/index.html")
       = 39aff3a2bab6126f332b942af96d3366

   Respuesta = MD5("939e7578ed9e3c518a452acee763bce9:
                    dcd98b7102dd2f0e8b11d0f600bfb0c093:
                    00000001:0a4f113b:autorización:
                    39aff3a2bab6126f332b942af96d3366”)
            = 6629fae49393a05397450978507c4ef1

En este punto, el cliente puede realizar otra solicitud, reutilizando el valor de 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 de nonce que ha emitido, rechazando cualquier solicitud incorrecta de manera adecuada. Obviamente, cambiar el método, el URI y/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, venciéndolos después de un cierto período de tiempo. Si se usa un valor caducado, el servidor debe responder con el código de estado "401" y agregarlo stale=TRUEal encabezado de autenticación, lo que indica que el cliente debe volver a enviar con el nuevo nonce proporcionado, sin solicitar al usuario otro nombre de usuario y contraseña.

El servidor no necesita mantener ningún valor nonce caducado; simplemente puede asumir que cualquier valor no reconocido ha caducado. 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 la caducidad de un servidor nonce 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 implícita del servidor Apache HTTP. 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 similares a Unix consideran oculto cualquier archivo que comience con un punto. Este archivo a menudo se mantiene 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 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:

htdigest [ -c ] passwdfile realm nombre de usuario

El formato del archivo.htdigest:

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

Autenticación de resumen SIP

El Protocolo de inicio de sesión (SIP) utiliza básicamente el mismo algoritmo de autenticación implícita. Está especificado por RFC 3261.

Implementación del navegador

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

• Amaya
• Basado en Gecko: (sin incluir auth-int)
  • Conjunto de aplicaciones de Mozilla
  • Mozilla Firefox
  • Netscape 7+
• iCab 3.0.3+
• Basado en KHTML y WebKit: (sin incluir auth-int)
  • iCab 4
  • Conquistador
  • Google Chrome
  • Safari
• Basado en Tasmania:
  • Internet Explorer para Mac
• Basado en tridente:
  • Internet Explorer 5+ (sin incluir auth-int)
• Basado en Presto:
  • Ópera
  • Ópera Móvil
  • mini Opera
  • Navegador de Nintendo DS
  • Navegador Nokia 770
  • Navegador de Sony Mylo 1
  • Navegador de canales de Internet de Wii

Deprecaciones

Debido a las desventajas de la autenticación Digest en comparación con la autenticación básica a través de HTTPS, ha quedado obsoleta por una gran cantidad de software, por ejemplo:

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