Autenticación Digest

Definición

¿Recuerdas jugar a las “20 Preguntas” de niño? En lugar de simplemente decirle a alguien lo que estás pensando, demuestras que conoces la respuesta respondiendo correctamente a sus preguntas. La Autenticación Digest funciona con un principio similar: en lugar de enviar tu contraseña directamente por la red (que podría ser interceptada), demuestras que conoces la contraseña resolviendo un puzzle criptográfico que solo alguien con la contraseña real podría resolver.

La Autenticación Digest fue inventada en los años 90 para solucionar un agujero de seguridad evidente en la Autenticación Básica, que envía tu usuario y contraseña esencialmente en texto plano. Con Digest Auth, cuando intentas acceder a un recurso protegido, el servidor te envía un “desafío”: un valor aleatorio llamado nonce (número usado una vez). Entonces combinas tu usuario, contraseña, el nonce y otros detalles de la petición, los pasas por una función hash (típicamente MD5), y envías de vuelta el “digest” resultante. El servidor, que conoce tu contraseña, realiza el mismo cálculo. Si los resultados coinciden, estás autenticado, y tu contraseña real nunca viajó por la red.

Aunque esto fue una mejora significativa sobre la Autenticación Básica en su momento, la Autenticación Digest ahora se considera un protocolo legacy que debe evitarse en aplicaciones nuevas. El algoritmo hash que usa (MD5) ha sido criptográficamente roto, lo que significa que atacantes con suficiente poder de cómputo pueden potencialmente revertir las contraseñas. Más importante aún, Digest Auth requiere que el servidor almacene las contraseñas en un formato recuperable (no hasheadas de forma segura), lo cual es un riesgo de seguridad importante. Los sistemas modernos deberían usar OAuth 2.0, claves API sobre HTTPS, u otros métodos de autenticación contemporáneos. Sin embargo, todavía puedes encontrar Digest Auth al integrarte con sistemas empresariales antiguos, dispositivos de red o APIs legacy.

Ejemplo

Escenario Real 1: Sistemas Empresariales Legacy Muchas aplicaciones empresariales construidas a principios de los 2000 usan Autenticación Digest. Si estás construyendo una integración con un sistema ERP antiguo, sistema de gestión de inventario o repositorio de documentos, podrías necesitar implementar Digest Auth porque es lo que el sistema legacy soporta. Hasta que estos sistemas puedan actualizarse, Digest Auth (siempre sobre HTTPS) proporciona mejor seguridad que Basic Auth.

Escenario Real 2: Gestión de Dispositivos de Red Muchos dispositivos de red, como routers, switches, cámaras IP y controladores industriales, usan Autenticación Digest para sus APIs de gestión. Cuando tu equipo de IT construye scripts para monitorear o configurar equipamiento de red, a menudo necesitan implementar Digest Auth. Una herramienta de monitoreo de red verificando el estado de 100 cámaras IP podría autenticarse con cada una usando Digest Auth porque es lo que el firmware de la cámara soporta.

Escenario Real 3: Sistemas de Telefonía SIP/VoIP El Protocolo de Iniciación de Sesión (SIP), que alimenta la mayoría de los sistemas de telefonía por internet, tradicionalmente usa Autenticación Digest. Cuando tu teléfono de escritorio se registra con el servidor telefónico corporativo, o cuando una aplicación VoIP se conecta a un servicio de llamadas, a menudo se usa Digest Auth para verificar credenciales. Por esto verás implementaciones de Digest Auth en software de telecomunicaciones.

Escenario Real 4: Sistemas de Archivos WebDAV Los servidores WebDAV (Web Distributed Authoring and Versioning), usados para compartir archivos en red y edición colaborativa, comúnmente soportan Autenticación Digest. Si estás construyendo un cliente que se conecta a un servidor WebDAV (como versiones antiguas de SharePoint o varios sistemas de gestión de contenido), podrías necesitar implementar Digest Auth.

Analogía

El Apretón de Manos Secreto con Verificación: Imagina unirte a un club con un apretón de manos secreto. En lugar de simplemente decirle al portero el secreto, el portero te muestra una tarjeta aleatoria y te pide que realices el apretón de manos secreto modificado por lo que hay en la tarjeta. Solo alguien que conoce el apretón de manos real podría ajustarlo correctamente para esa tarjeta específica. La tarjeta (nonce) es diferente cada vez, así que aunque alguien vea tu apretón de manos modificado una vez, no pueden reproducirlo la próxima vez.

El Juego de Desafío de Contraseña: Piensa en una instalación segura donde en lugar de decir tu contraseña, el guardia te da un problema matemático que incorpora tu contraseña. “Toma tu contraseña, suma la fecha de hoy, multiplica por este número aleatorio, y dime los últimos 4 dígitos.” Solo alguien que conoce la contraseña real podría responder correctamente, pero la respuesta cambia cada vez así que los escuchas no aprenden nada.

La Verificación del Sello Notarial: En lugar de mostrar tu firma real (contraseña), demuestras que eres el firmante real sellando correctamente un documento aleatorio que el notario te da. Solo alguien con tu sello auténtico podría producir la impresión correcta en ese documento específico. El documento (nonce) es único cada vez.

El Sistema de Palabras Clave de Radio: En comunicación militar, los operadores no declaran directamente su identidad. En su lugar, se da una palabra de “desafío” aleatoria, y solo alguien con el libro de códigos auténtico puede proporcionar la palabra de “respuesta” correcta. El desafío cambia regularmente, así que interceptar un intercambio no ayuda a los atacantes después.

Ejemplo de Código

// Respuesta Digest Auth (concepto simplificado)
function generateDigestResponse(username, password, realm, nonce, method, uri) {
  const ha1 = md5(`${username}:${realm}:${password}`);
  const ha2 = md5(`${method}:${uri}`);
  const response = md5(`${ha1}:${nonce}:${ha2}`);
  return response;
}

// Header de Digest Auth
const authHeader =
  'Digest username="user", ' +
  'realm="[email protected]", ' +
  'nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", ' +
  'uri="/api/resource", ' +
  'response="6629fae49393a05397450978507c4ef1"';

// Desafío del servidor (respuesta 401)
// [HTTP/1.1](https://reference.apios.info/es/terms/http-1-1/) 401 Unauthorized
// WWW-Authenticate: Digest realm="[email protected]",
//                   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
//                   qop="auth"

// El cliente calcula la respuesta y reintenta
// GET /api/resource HTTP/1.1
// Authorization: Digest username="user", realm="[email protected]",
//                nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
//                uri="/api/resource", qop=auth, nc=00000001,
//                cnonce="0a4f113b", response="6629fae49..."

Diagrama

sequenceDiagram
    participant C as Cliente
    participant S as Servidor

    C->>S: GET /recurso-protegido
    S-->>C: 401 No Autorizado
WWW-Authenticate: Digest
realm="[email protected]"
nonce="abc123random"
qop="auth"

    Note over C: Calcular hash de respuesta:
HA1 = MD5(user:realm:pass)
HA2 = MD5(method:uri)
response = MD5(HA1:nonce:HA2)

    C->>S: GET /recurso-protegido
Authorization: Digest
username="user"
nonce="abc123random"
response="hash_calculado"

    Note over S: Recalcular mismo hash
usando contraseña almacenada
Comparar con respuesta recibida

    alt Hashes Coinciden
        S-->>C: 200 OK + Datos de Respuesta
    else Hashes Difieren
        S-->>C: 401 No Autorizado
    end

    Note over C,S: La contraseña NUNCA se envia por la red
Solo prueba criptografica de conocimiento

Notas de Seguridad

Estándares y RFCs