La autenticación de acceso implícito es uno de los métodos acordados que un servidor web puede utilizar 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 usa la codificación Base64 fácilmente reversible en lugar de hash, lo que la hace no segura a menos que se use 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 reproducción . Utiliza el protocolo HTTP .
Descripción general
La autenticación de acceso implícito fue especificada originalmente por RFC 2069 ( Una extensión para HTTP: Autenticación de acceso implícito ). RFC 2069 especifica aproximadamente un esquema de autenticación implícita tradicional con la 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: reino: 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 de algoritmo es "MD5" o no se especifica, entonces HA1 es
HA1 = MD5 (nombre de usuario: reino: contraseña)
Si el valor de la directiva de 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 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 la directiva qop no está especificada, 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" y "SHA-512-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 .
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 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 ), quizás con la ayuda de un diccionario o una lista de búsqueda adecuada , que para MD5 es fácil de usar. disponible. [1]
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). [2] Sin embargo, las afirmaciones de 2006 [3] también provocan algunas dudas sobre otras aplicaciones MD5. Sin embargo, hasta ahora, no se ha demostrado que los ataques de colisión MD5 representen una amenaza para digerir la autenticación [ cita requerida ] , 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 implícita de HTTP
Ventajas
La autenticación implícita HTTP está diseñada para ser más segura que los esquemas de autenticación implícita tradicionales, por ejemplo, "significativamente más fuerte que (por ejemplo) CRAM-MD5 ..." (RFC 2617).
Algunas de las fortalezas de seguridad de la autenticación implícita 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 [4] ) almacenen HA1 en lugar de la contraseña de texto sin cifrar
- Client nonce se introdujo en RFC 2617, que permite al cliente prevenir ataques de texto sin formato elegido , como tablas de arco iris que de otro modo podrían amenazar los esquemas de autenticación implícita.
- El nonce del servidor 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, ya sea el servidor correcto o no. (Los sistemas de clave pública dependen de que el usuario pueda verificar que la URL sea correcta).
Desventajas
Hay varios inconvenientes con la autenticación de acceso implícito:
- 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 funcionará en un modo RFC 2069 heredado con seguridad reducida
- La autenticación de acceso implícito es vulnerable a un ataque de intermediario (MITM) . Por ejemplo, un atacante MITM podría decirle a los clientes que utilicen la autenticación de acceso básica o el modo de autenticación de acceso implícito RFC2069 heredado. Para extender esto aún más, la autenticación de acceso implícito no proporciona ningún mecanismo para que los clientes verifiquen la identidad del servidor.
- Algunos servidores requieren que las contraseñas se almacenen mediante cifrado reversible. Sin embargo, es posible almacenar en su lugar el valor digerido del nombre de usuario, reino y contraseña [5]
- 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, reino y 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 de cifrado certificados por FIPS [nota 1] .
Protocolos de autenticación alternativos
Con mucho, el enfoque más común es utilizar un protocolo de texto sin cifrar de autenticación basado en formularios HTTP + HTML o, más raramente, la autenticación de acceso básica . Estos débiles protocolos de texto sin cifrar que se utilizan junto con el cifrado de red HTTPS resuelven muchas de las amenazas que la autenticación de acceso de resumen 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 hacen esto, por lo que el phishing se ha convertido en la forma más común de violación de seguridad.
Algunos protocolos de autenticación sólidos para aplicaciones basadas en web que se utilizan ocasionalmente incluyen:
- Autenticación de clave pública (generalmente implementada con un certificado de cliente HTTPS / SSL ) mediante 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 de contraseña remota segura (preferiblemente dentro de la capa HTTPS / TLS ). Sin embargo, ninguno de los navegadores convencionales lo implementa.
- JSON Web Token (JWT) es un RFC 7519 estándar basado en JSON para crear tokens de acceso que afirman cierto número de reclamaciones.
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). 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:
- El cliente solicita una página que requiere autenticación pero no proporciona un nombre de usuario y contraseña. [nota 2] Por lo general, esto se debe a que el usuario simplemente ingresó la dirección o siguió un enlace a la página.
- El servidor responde con el código de respuesta 401 "No autorizado" , que proporciona el ámbito de autenticación y un valor de uso único generado aleatoriamente llamado nonce .
- En este punto, el navegador presentará el dominio de autenticación (generalmente una descripción de la computadora o sistema al que se accede) al usuario y le pedirá un nombre de usuario y contraseña. El usuario puede decidir cancelar en este momento.
- 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.
- 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 preguntarle 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 retorno de carro seguido de un salto de línea ). [6]
- Respuesta del servidor
HTTP / 1.0 401 Servidor no autorizado : HTTPd / 0.9 Fecha : Dom, 10 de abril de 2014 20:26:47 GMT WWW-Authenticate : Digest realm = "[email protected]", qop = "auth, auth-int", nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque = "5ccc069c403ebaf9f0171e9517f40e41" Tipo de contenido : texto / html Longitud del contenido : 153 < html > < head > < meta charset = "UTF-8" /> < title > Error title > head > < body > < h1 > 401 No autorizado. h1 > cuerpo > html >
- Solicitud del cliente (nombre de usuario "Mufasa", contraseña "Circle Of Life")
OBTENER /dir/index.html HTTP / 1.0 Host : localhost Autorización : Digest username = "Mufasa", realm = "[email protected]", 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 de abril de 2005 20:27:03 GMT Tipo de contenido : texto / html Longitud del 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 los valores se combinan, se delimitan con dos puntos.
- Se calcula el hash MD5 del nombre de usuario, el dominio de autenticación y la contraseña combinados. El resultado se conoce como HA1.
- 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 conoce como HA2. - 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 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.
Completar el ejemplo dado en RFC 2617 da los siguientes resultados para cada paso.
HA1 = MD5 ("Mufasa: [email protected]: Circle Of Life") = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5 ("OBTENER: /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 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 nonce que ha emitido, rechazando las solicitudes incorrectas de forma 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 de nonce, expirando 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=TRUE
al encabezado de autenticación, indicando que el cliente debe volver a enviar con el nuevo nonce proporcionado, sin pedirle al usuario otro nombre de usuario y contraseña.
El servidor no necesita mantener ningún valor nonce caducado; simplemente puede asumir que los valores no reconocidos han caducado. También es posible que el servidor solo permita que cada valor de nonce se devuelva una vez, aunque esto obliga al cliente a repetir cada solicitud. Tenga en cuenta que caducar un nonce de servidor 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 HTTP Apache . El nombre del archivo se proporciona en la configuración .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 que cualquier archivo que comience con un punto está oculto. 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 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: [7]
htdigest [-c] passwdfile reino de nombre de usuario
El formato del archivo .htdigest: [7]
user1: Reino: 5ea41921c65387d904834f8403185412user2: 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 excluyen ciertas características como la verificación de autenticación 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 [8] )
- Suite de aplicaciones de Mozilla
- Mozilla Firefox
- Netscape 7+
- iCab 3.0.3+
- Basado en KHTML y WebKit : (sin incluir auth-int [9] )
- iCab 4
- Konqueror
- Google Chrome
- Safari
- Basado en Tasmania :
- Internet Explorer para Mac
- Basado en tridente :
- Internet Explorer 5+ [10] (sin incluir auth-int)
- Presto -basado:
- Ópera
- Opera Mobile
- mini Opera
- Navegador de Nintendo DS
- Navegador Nokia 770
- Navegador de Sony Mylo 1
- Navegador de canales de Internet de Wii
Desaprobaciones
Debido a las desventajas de la autenticación implícita en comparación con la autenticación básica sobre HTTPS, muchos software la han desaprobado, por ejemplo:
- Bitbucket: https://bitbucket.org/blog/fare-thee-well-digest-access-authentication
- Marco PHP de Symfony: https://github.com/symfony/symfony/issues/24325
Ver también
- AKA (seguridad)
- Token web JSON (JWT)
- Autenticación de acceso básica
- Autenticación basada en formularios HTTP + HTML
Notas
- ^ La siguiente es 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.
- ^ Es posible que un cliente ya tenga el nombre de usuario y la contraseña requeridos sin necesidad de preguntarle al usuario, por ejemplo, si han sido almacenados previamente por un navegador web.
Referencias
- ^ Lista de tablas de arco iris, Proyecto Rainbowcrack . Incluye múltiples tablas arcoíris MD5.
- ^ "Preguntas y respuestas de Hash Collision" . Investigación en criptografía . 2005-02-16. Archivado desde el original el 6 de marzo de 2010.[se necesita una mejor fuente ]
- ^ Jongsung Kim; Alex Biryukov; Bart Preneel; Seokhie Hong. "Sobre la seguridad de HMAC y NMAC basado en HAVAL, MD4, MD5, SHA-0 y SHA-1" (PDF) . IACR .
- ^ Scott Stark (8 de octubre de 2005). "Autenticación DIGEST (4.0.4+)" . JBoss .
- ^ "Autenticación HTTP: Autenticación de acceso básica y Digest: Almacenamiento de contraseñas" . IETF . Junio de 1999.
- ^ Tim Berners-Lee , Roy Fielding , Henrik Frystyk Nielsen ( 19 de febrero de 1996 ). "Protocolo de transferencia de hipertexto - HTTP / 1.0: solicitud" . W3C .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ a b "htdigest: gestiona los archivos de usuario para la autenticación implícita" . apache.org .
- ^ Emanuel Corthay (16 de septiembre de 2002). "Error 168942 - Autenticación implícita con protección de integridad" . Mozilla .
- ^ Timothy D. Morgan (5 de enero de 2010). "Integridad 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.
- ^ "Autenticación de resumen de TechNet" . Agosto 2013.
enlaces externos
- RFC 7235
- RFC 2617 (actualizado por RFC 7235)
- RFC 2069 (obsoleto)