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]
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]
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.
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 autenticación de acceso resumido presenta varias desventajas:
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] .
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:
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:
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]
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 >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).
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.
"GET" de resumen, p. ej. de y "/dir/index.html". El resultado se denomina HA2.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") = 6629fae49393a05397450978507c4ef1En 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.
.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 mantiene a menudo 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
El protocolo de inicio de sesión (SIP) utiliza básicamente el mismo algoritmo de autenticación resumida, especificado en RFC 3261.
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).
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:
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )