Resumen

  • nc cuenta las solicitudes que el cliente afirma haber enviado con el nonce de servidor incluido en la solicitud. El servidor necesita mantener la copia correspondiente para detectar una cifra repetida.
  • El cálculo Digest vincula ese contador con material derivado de la credencial, los nonces y ciertos elementos HTTP. No lo convierte en identificador universal, permiso de negocio ni constancia de ejecución.
  • Una operación con consecuencias necesita identidad persistente y un resultado consultable aparte. Autenticar correctamente un reintento no demuestra que el intento anterior careciera de efecto.

Una secuencia ordenada en el lugar equivocado

La primera solicitud asociada a un nonce lleva nc=00000001. Después, el cliente incrementa el valor hexadecimal. Si el servidor conserva su propio contador y observa de nuevo el mismo valor en el contexto que está siguiendo, puede detectar un replay. La lógica tiene la sencillez de una buena señal operativa: algo que debía avanzar ha aparecido dos veces.

El problema empieza cuando el número cambia de dueño conceptual. En manos del autenticador, significa cuántas solicitudes dice el cliente que ha enviado con ese nonce. En manos de una consola de negocio, puede parecer la posición de una transacción. El RFC no dice que todas las solicitudes contadas fueron aceptadas, alcanzaron la misma instancia, ejecutaron código o confirmaron datos. Tampoco exige que nc sea único fuera del nonce.

Cuando el servidor cambia el nonce, la serie vuelve a empezar. Otros clientes, credenciales o espacios de protección mantienen series distintas. Una rotación puede obedecer a caducidad normal, no al inicio de una nueva historia comercial. Por eso el contador es una coordenada dentro de un intercambio de autenticación, no una línea temporal global.

Incluso como evidencia de replay necesita compañía. Un nc sin nonce, realm, client nonce, identidad y decisión del servidor es un fragmento difícil de interpretar. Con todo ese contexto puede explicar la autenticación; todavía no puede decir si una operación se confirmó en la capa de aplicación.

La política oculta detrás del nonce

El nonce lo crea el servidor y es opaco para el cliente. La especificación deja que su validez se limite por tiempo, recurso, cliente, cantidad de usos u otras reglas. Esa libertad permite adaptar seguridad y rendimiento, pero también impide suponer una semántica única entre despliegues.

Un servicio puede aceptar cada nonce una sola vez y guardar el gasto. Así frena incluso un replay inmediato, a costa de conservar más estado y de perjudicar solicitudes canalizadas. Otra implementación permite varios usos y comprueba nc, evitando un nuevo desafío para cada petición. Ambas decisiones pueden ajustarse al RFC; no producen el mismo tipo de registro.

En un clúster, además, hay que decidir dónde vive la memoria de replay. Si dos instancias no comparten el mismo estado, pueden interpretar de manera distinta una repetición. Un failover o una pérdida del almacén cambia lo que el autenticador recuerda. No modifica por sí mismo los commits ya hechos por la base de datos, un worker o un proveedor externo.

Las piezas que sí quedan ligadas

Cuando se usa qop, la respuesta Digest incorpora material derivado del password, el nonce de servidor, nc, el client nonce, el valor qop y el hash de A2. Para qop=auth, A2 contiene el método HTTP y la URI solicitada. Para qop=auth-int, también incluye el hash del cuerpo de entidad. El servidor puede verificar así el conocimiento del secreto y detectar ciertas repeticiones o alteraciones.

La protección no abarca todo el mensaje. El RFC advierte que la mayoría de los encabezados permanecen modificables incluso con auth-int. Digest tampoco aporta confidencialidad al resto del intercambio y recomienda un canal seguro como HTTPS.

Hay otro límite institucional: autenticar no es autorizar. Un resultado criptográfico correcto respalda que el solicitante conoce el secreto asociado al realm. No decide si el rol actual permite borrar una cuenta, mover dinero o iniciar un despliegue. La autorización y la postcondición pertenecen a controles que ven el estado de la aplicación.

Rifaat Shekh-Yusef figura como editor y coautor colectivo del RFC de consenso de la IETF. Conviene no atribuirle la invención de cada campo: el RFC 2617 ya contenía el nonce count. El RFC 7616 lo conservó y añadió SHA-256, SHA-512/256, negociación de algoritmo, uso actualizado de qop y userhash, además de una evaluación de riesgos más explícita. También señala que cambiar de algoritmo no evita los ataques de diccionario contra contraseñas memorizables.

La respuesta autenticada tampoco es un recibo

Authentication-Info puede devolver rspauth y los valores cnonce y nc de la solicitud correspondiente. Esto permite que el servidor pruebe conocimiento del secreto y, con auth-int, entregue integridad limitada para la respuesta. Es una confirmación valiosa en el plano de autenticación.

No es el acuse del resultado empresarial. Los parámetros no designan una orden persistente, un cargo, un mensaje de cola, un commit o una compensación. El servidor puede validar Digest, entregar el trabajo a otro proceso y perder la respuesta después de que ese proceso confirme el cambio. El cliente obtiene luego un nonce nuevo y emite otro Digest perfectamente válido. La corrección de ambas autenticaciones no impide que el efecto se repita.

La solución pertenece a la aplicación. Una clave de idempotencia debe nombrar la intención antes de producir el efecto. Un endpoint de consulta debe responder qué resultado quedó asociado a esa clave. Ante un timeout, el cliente puede consultar en vez de adivinar. Nada de esto lo define el RFC 7616, y por eso no debe esconderse dentro de una interpretación ampliada de nc.

Cinco hechos para una sola operación

Una arquitectura auditable distingue al menos cinco estados: autenticación aceptada, control de replay superado, autorización concedida, identidad duradera de la operación y postcondición confirmada. También puede registrar si la respuesta llegó al cliente. Cada estado tiene una autoridad distinta y puede fallar por separado.

Leer el RFC con disciplina significa aprovechar toda la información del contador sin exigirle la que no posee. Hay que conservar y proteger el estado de servidor que permite comparar nc; aplicar nonces limitados cuando el riesgo lo justifica; escoger qop con conocimiento de su perímetro; y usar HTTPS. Después hace falta detener la inferencia. Un contador de autenticación no observa la transacción de negocio y no puede numerarla.

Fuentes