Ralph Merkle
(leer más)
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.
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.
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.
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:
Hay varios inconvenientes con la autenticación de acceso implícita:
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.
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:
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:
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.
"GET"
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: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=TRUE
al 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.
.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
El Protocolo de inicio de sesión (SIP) utiliza básicamente el mismo algoritmo de autenticación implícita. Está especificado por RFC 3261.
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).
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:
(leer más)
La sociología computacional es una rama de la sociología que utiliza métodos computacionalmente intensivos para analizar y modelar fenómenos sociales.... (leer más)
(leer más)