Resumen

  • RFC 2069 evitó que Basic enviara la contraseña recuperable por la red, pero dejó en el servidor H(A1), un equivalente limitado al realm que debía custodiarse como una contraseña sin cifrar.
  • La respuesta ordinaria unía ese material con un nonce, el método y el URI solicitado; no cifraba el mensaje ni certificaba todos sus campos, la voluntad del cliente, la autorización o el resultado.
  • Un nonce con dirección y tiempo podía validarse sin estado y reducir la ventana de repetición. Saber que era el primer uso exigía recordar respuestas ya aceptadas y asumir ese coste operativo.

El secreto cambió de lugar

El RFC 1945 describió Basic como el envío de usuario y contraseña en una representación Base64. No era cifrado: un observador podía extraer la contraseña y reutilizarla. El RFC 2069, publicado en enero de 1997 junto al primer HTTP/1.1 del RFC 2068, propuso un intercambio distinto. El servidor entregaba un desafío y el cliente respondía con un resumen calculado; la contraseña ya no viajaba en claro.

El avance debe medirse contra la amenaza que resolvía. El propio documento llamó débil al esquema, negó que cifrara el contenido, dejó fuera el acuerdo inicial de la contraseña y reconoció ataques de intermediario, servidor falso, diccionario y repetición. El registro histórico del RFC 2069 tampoco prueba adopción ni configuración en un producto concreto.

La frase correcta no es “Digest eliminó el secreto”, sino “Digest dejó de revelar por la red el secreto humano en cada petición”. El servidor seguía necesitando material capaz de validar —y también de producir— una respuesta.

Una fórmula con fronteras visibles

RFC 2069 concretó H como MD5, definido en el RFC 1321, y construyó la respuesta así:

A1 = usuario : realm : contraseña
A2 = Método : URI-de-la-petición
respuesta = KD(H(A1), nonce : H(A2))

El realm no era decoración. Participaba en A1 y separaba espacios de protección. A2 vinculaba la prueba a un método y un URI. El nonce aportaba el desafío del servidor. Si el valor coincidía, el verificador podía afirmar que quien lo produjo disponía de material válido para esas entradas.

No podía afirmar mucho más. La fórmula básica no contenía todos los encabezados, no cifraba cuerpo ni respuesta y no decía si una persona quería la operación. Tampoco concedía permiso sobre el recurso ni demostraba que la aplicación hubiera confirmado una transacción una sola vez. Incluso el servidor debía comprobar que el uri repetido en Authorization correspondía a lo realmente servido, porque un proxy podía alterar la línea de petición.

Para POST y PUT, RFC 2069 definió un digest adicional y opcional que podía abarcar el cuerpo y ciertos metadatos. La separación importa: si la integridad total ya estuviera incluida en la respuesta principal, aquel campo no habría sido necesario. El documento aconsejaba usarlo, emplear valores de un solo uso o restringir Digest a GET.

El equivalente tenía un ámbito, no inocencia

Un servidor podía guardar usuario y H(A1), sin conservar la contraseña legible. Sin embargo, la sección 3.5 dijo que la copia de ese archivo permitía acceso inmediato a los documentos del realm. No era necesario descifrar H(A1); bastaba emplearlo como secreto de la operación KD. Por eso debía protegerse como si contuviera contraseñas sin cifrar.

Llamarlo “equivalente de contraseña” no significa que H(A1) revele automáticamente la contraseña ni que funcione en todos los realms. Como el nombre del realm forma parte del cálculo, una copia no se traslada sin más a otro espacio. Sí significa que, dentro de su ámbito, la posesión permite fabricar la evidencia que el servidor acepta. Un atacante puede además probar contraseñas débiles fuera de línea.

La lección de custodia es más amplia que una etiqueta de inventario. Un hash puede ser menos revelador y a la vez seguir siendo ejecutable. Copiarlo a respaldos, réplicas o servicios auxiliares aumenta la superficie capaz de causar aceptación. El criterio relevante es la acción habilitada, no si el valor parece legible.

El nonce compraba límites; el estado compraba unicidad

La construcción sugerida para el nonce era un hash de dirección IP del cliente, marca temporal y clave privada del servidor. El servidor podía recalcularlo al recibir la petición, verificar origen aparente y caducidad, y no almacenar cada desafío emitido. Esta arquitectura favorecía la escala.

Pero “todavía válido” y “nunca usado” son afirmaciones distintas. Durante la ventana temporal, la misma respuesta puede volver a llegar. RFC 2069 observó que repetir un GET simple solía dar poco beneficio al espía, porque el URI estaba ligado y el documento ya había sido visto. También reconoció que un GET podía activar un programa y que POST o PUT podían producir datos o ficheros falsificados.

Para impedir cualquier repetición, el servidor tenía que recordar las respuestas utilizadas hasta que caducara el nonce y rechazar la segunda aparición. Ese diseño consume memoria, coordinación, expiración y capacidad de consulta. En un conjunto de servidores, el coste incluye compartir el estado o garantizar que todas las repeticiones llegan al mismo verificador. El resumen criptográfico no realiza ese trabajo.

1999 y 2015 no estaban escondidos en 1997

El RFC 2617 sustituyó al 2069, como confirma su ficha oficial. Añadió qop, el valor cliente cnonce y el contador nc. El servidor que conserva su propia cuenta puede detectar la repetición de un mismo número. qop=auth-int incorpora el hash del cuerpo a A2. Pero sin qop, RFC 2617 mantuvo la fórmula antigua por compatibilidad. No es correcto atribuir contador, nonce de cliente o cobertura integrada del cuerpo al mecanismo básico de 1997.

El RFC 7616 y su registro trazan la revisión de 2015. Se añadieron SHA-256 y SHA-512/256 y MD5 pasó a no ser recomendado. Aun así, el texto repitió que robar H(A1) da acceso inmediato al realm y que el archivo debe protegerse como una contraseña. También advirtió que cambiar el algoritmo no salva contraseñas fáciles de adivinar y recomendó HTTPS.

El marco de autenticación moderno del RFC 9110 ayuda a no confundir autenticación con autorización. Una identidad o credencial aceptada es una entrada para decidir; no es la decisión ni el efecto posterior.

Reconstruir una acción exige más de una igualdad

Ante un Digest correcto para PUT /saldo, una investigación puede afirmar que un nodo aceptó cierta relación entre secreto, nonce, método y URI. Después debe buscar otras pruebas: algoritmo y variante; cuerpo cubierto o no; estado anti-repetición consultado; identidad asignada al usuario; política de autorización vigente; identificador de transacción; confirmación en almacenamiento; efecto observado.

La Primacía del Código en Ejecución de Lu Heng exige mirar lo implementado, no promover un documento a realidad. Su Especificación Inicial Mínima separa la regla común verificable de decisiones locales posteriores. Aquí, la fórmula es común; la custodia, la vida del nonce, el presupuesto de estado y la autorización pertenecen al operador.

La nota sobre capas de realidad añade el límite final. Un valor válido en una capa no adquiere autoridad sobre las siguientes por llamarse “autenticación”. La operación, la intención y el resultado deben demostrar su propia ejecución.

Fuentes