autenticación - http digest authentication example
¿Cuál es la diferencia entre Digest y Basic Authentication? (3)
La autenticación implícita comunica las credenciales en forma cifrada mediante la aplicación de una función hash al nombre de usuario, la contraseña, el valor nonce suministrado por el servidor, el método HTTP y el URI solicitado.
Mientras que la Autenticación básica usa codificación base64 no encriptada.
Por lo tanto, la Autenticación básica generalmente solo debe utilizarse cuando se proporciona seguridad de la capa de transporte, como https.
Ver RFC-2617 para todos los detalles sangrientos.
¿Cuál es la diferencia entre Digest y Basic Authentication?
Autenticación de acceso básico HTTP
- PASO 1 : el cliente realiza una solicitud de información, enviando un nombre de usuario y contraseña al servidor en texto sin formato
- PASO 2 : el servidor responde con la información deseada o un error
HTTP Basic no necesita implementarse a través de SSL, pero si no lo hace, no es seguro en absoluto. Así que ni siquiera voy a considerar la idea de usarlo sin.
Pros:
- Es simple de implementar, por lo que los desarrolladores de sus clientes tendrán menos trabajo que hacer y tomarán menos tiempo para entregarlos, por lo que es más probable que los desarrolladores quieran usar su API
- A diferencia de Digest, puede almacenar las contraseñas en el servidor con el método de cifrado que desee, como bcrypt, haciendo que las contraseñas sean más seguras.
- Solo se necesita una llamada al servidor para obtener la información, lo que hace que el cliente sea un poco más rápido que los métodos de autenticación más complejos.
Contras:
- SSL es más lento de ejecutar que HTTP básico por lo que esto hace que los clientes sean un poco más lentos
- Si no tiene el control de los clientes y no puede obligar al servidor a usar SSL, un desarrollador podría no usar SSL, lo que ocasionaría un riesgo de seguridad
En resumen : si tiene el control de los clientes o puede asegurarse de que usen SSL, HTTP Basic es una buena opción. La lentitud del SSL puede ser cancelada por la velocidad de solo hacer una solicitud
Autenticación de acceso HTTP Digest
La autenticación de acceso HTTP Digest es una forma más compleja de autenticación que funciona de la siguiente manera:
- PASO 1 : un cliente envía una solicitud a un servidor
- PASO 2 : el servidor responde con un código especial (llamado nonce ie n umber usado solo una vez ), otra cadena que representa el realm (un hash) y le pide al cliente que se autentique
- PASO 3 : el cliente responde con este nonce y una versión encriptada del nombre de usuario, contraseña y reino (un hash)
- PASO 4 : el servidor responde con la información solicitada si el hash del cliente coincide con su propio hash del nombre de usuario, la contraseña y el reino, o si no se produce un error.
Pros:
- No se envían nombres de usuario o contraseñas al servidor en texto llano, lo que hace que una conexión no SSL sea más segura que una solicitud HTTP básica que no se envía a través de SSL. Esto significa que no se requiere SSL, lo que hace que cada llamada sea un poco más rápida
Contras:
- Para cada llamada que se necesita, el cliente debe hacer 2, lo que hace que el proceso sea un poco más lento que HTTP Basic
- HTTP Digest es vulnerable a un ataque de seguridad man-in-the-middle que básicamente significa que podría ser pirateado
- HTTP Digest evita el uso de encriptación segura de contraseñas, lo que significa que las contraseñas almacenadas en el servidor podrían ser pirateadas
En resumen , HTTP Digest es intrínsecamente vulnerable a al menos dos ataques, mientras que un servidor que utiliza cifrado fuerte para contraseñas con HTTP Básico sobre SSL tiene menos probabilidades de compartir estas vulnerabilidades.
Si no tiene control sobre sus clientes, pueden intentar realizar la autenticación básica sin SSL, lo que es mucho menos seguro que Digest.
Veamos la diferencia entre las dos autenticaciones HTTP usando Wireshark (herramienta para analizar paquetes enviados o recibidos).
1. Http Basic Authentication
Tan pronto como el cliente ingrese el nombre de usuario correcto : contraseña , según lo solicite el servidor web, el servidor web verifica en la base de datos si las credenciales son correctas y le da acceso al recurso.
Así es como se envían y reciben los paquetes:
En el primer paquete, el cliente llena las credenciales usando el método POST en el recurso - lab/webapp/basicauth . A cambio, el servidor responde con el código de respuesta http 200 ok , es decir, el nombre de usuario: la contraseña era correcta.
Ahora, en el encabezado Authorization , muestra que es Autorización básica seguida de una cadena aleatoria. Esta cadena es la versión codificada (Base64) de las credenciales admin:aadd (incluidos dos puntos).
2. Http Digest Authentication (rfc 2069)
Hasta ahora hemos visto que la Autenticación básica envía nombre de usuario: contraseña en texto plano a través de la red. Pero la autenticación Digest envía un HASH de la contraseña usando el algoritmo Hash.
Aquí hay paquetes que muestran las solicitudes realizadas por el cliente y la respuesta del servidor.
Tan pronto como el cliente escriba las credenciales solicitadas por el servidor, la contraseña se convertirá en una response usando un algoritmo y luego se enviará al servidor. Si la base de datos del servidor tiene la misma respuesta dada por el cliente, el servidor le da acceso al recurso, de lo contrario, un error 401 .
En la Authorization anterior, la cadena de response se calcula utilizando los valores de Username de Username , Realm , Password , http-method , URI y Nonce como se muestra en la imagen:
Por lo tanto, podemos ver que la autenticación implícita es más segura, ya que implica el hash (cifrado MD5), por lo que las herramientas de detección de paquetes no pueden oler la contraseña aunque en autenticación básica la contraseña exacta se mostró en Wireshark.