Resumen

  • RFC 1938 aceptaba x cuando H(x) coincidía con el verificador guardado y, acto seguido, guardaba x: el éxito avanzaba una cadena hash descendente.
  • La promesa de un solo uso exigía que comparación y actualización fueran indivisibles, además de resolver carreras, agotamiento y reinicialización.
  • La frase secreta no viajaba por la red, pero el mecanismo no cifraba la sesión ni bloqueaba por sí solo ataques activos; HOTP y TOTP organizaron el cambio de otra manera.

El segundo intento llega a otro mundo

Dos copias de una misma respuesta pueden ser bit por bit idénticas y, sin embargo, no tener el mismo valor probatorio. En RFC 1938, el servidor toma la respuesta x, calcula H(x) y la compara con el verificador almacenado. Si coincide, acepta y reemplaza ese verificador por x. La primera aceptación transforma el estado; la segunda copia ya no encuentra la referencia que la justificaba.

La ficha del RFC Editor sitúa el documento de N. Haller y C. Metz en mayo de 1996, como Proposed Standard hoy obsoleto por RFC 2289. El dato normativo importa, pero no debe ocultar la pregunta histórica: ¿qué tuvo que convertirse en mutable para que una contraseña fuera realmente de un solo uso?

El generador combina una frase secreta con una semilla pública y aplica repetidamente una función unidireccional. En una cadena inicializada a N, se presenta primero H^N(S), después H^(N-1)(S). El servidor conserva el último verificador de 64 bits y la posición, no la frase secreta. Quien observa una respuesta puede calcular hacia valores ya consumidos, no hacia el próximo valor esperado.

El antecedente fue el S/KEY de Bellcore descrito en RFC 1760. Su amenaza era concreta: una contraseña reutilizable capturada pasivamente podía volver a abrir la cuenta. La cadena reducía ese premio sin exigir que el secreto original cruzara la red.

Pero «sin secreto almacenado» no significa «sin estado». El verificador es información operativa decisiva. Una réplica atrasada, una restauración o dos escrituras desordenadas pueden cambiar la respuesta que el sistema considera vigente.

Seis palabras para transportar 64 bits

El reto anunciaba algoritmo, secuencia y semilla; otp-md5 487 dog2 era una forma posible. MD5 era obligatorio, SHA recomendado y MD4 opcional. Generador y validador tenían que usar el mismo algoritmo, y mantener una opción débil podía fijar el suelo de seguridad.

Para que una persona pudiera teclear el resultado, 2.048 palabras estándar codificaban posiciones de 11 bits. Seis palabras sumaban 66 bits: los dos adicionales componían una comprobación contra ciertos errores de entrada y decodificación. No eran otro factor ni una firma; tampoco las palabras añadían secreto por su significado.

El servidor debía admitir la forma de seis palabras y la hexadecimal, y debía procurar admitir diccionarios alternativos. Por ello, mayúsculas, tokenización y normalización no eran detalles decorativos. Una conversión aparentemente amable podía impedir que los mismos 64 bits llegaran al comparador.

La carrera ocurre fuera de la función hash

RFC 1938 describe un atacante que oye casi toda la respuesta verbal, adivina el resto y compite por llegar primero. El servidor debe impedirlo. Una técnica propuesta consiste en no permitir sesiones de autenticación simultáneas para un usuario, con un tiempo de caducidad que evite convertir el bloqueo en una denegación de servicio indefinida.

También puede competir el propio servidor consigo mismo. Dos procesos leen el verificador antiguo, ambos validan x y ambos crean una sesión antes de persistir el nuevo estado. No falló la criptografía: falló la transacción. Comparar y avanzar deben formar una única decisión atómica, o estar sujetos a una serialización equivalente. De otro modo, «un solo uso» es apenas una etiqueta.

La secuencia, además, se termina. Su número expresa inventario disponible. Para reinicializar hay que cambiar la semilla o la frase secreta; repetir ambas reconstruye valores posiblemente observados. Transportar la frase secreta en claro durante esa operación destruye la ventaja inicial.

Una recomendación permitía autorizar la nueva inicialización con un OTP antiguo. Aparece entonces una paradoja práctica: al llegar a uno, el último OTP puede servir para iniciar sesión, pero ya no queda otro para aprobar la renovación. La planificación previa al cero pertenece a la seguridad y a la disponibilidad del sistema.

La sucesión normativa no protege una sesión

El registro de RFC 2289 lo fecha en febrero de 1998 y lo identifica como sucesor. El texto de RFC 2289 mantiene la cadena descendente, añade vectores de prueba y afina la guía operativa. Su recomendación de IPsec frente al secuestro de conexiones TCP revela el límite correcto: validar un OTP no cifra lo que ocurre después.

Otros estándares desplazaron el estado con mecanismos distintos. HOTP emplea un secreto compartido y un contador ascendente; el validador puede explorar una ventana hacia delante para resincronizar y avanza después del éxito. TOTP usa un intervalo temporal como factor móvil de HOTP y exige no aceptar dos veces un valor ya validado dentro de ese intervalo. Son contrastes, no prueba de descendencia desde S/KEY.

En todos los casos, la pregunta operativa supera «¿coincide el código?». Hace falta establecer qué estado manda, qué margen se tolera, qué consume el éxito y cómo acuerdan la historia varias instancias.

Tampoco conviene inflar la conclusión. RFC 1938 no aportaba privacidad ni defensa general contra ataques activos o ingeniería social. La aceptación vincula una respuesta al estado configurado de una cuenta. No concede por sí sola autorización sobre una orden, confidencialidad de sesión, ejecución efectiva, acceso permanente ni identidad civil.

Del nombre a la evidencia de ejecución

La primacía del código en ejecución de Heng Lu obliga a preguntar si el verbo normativo ocurre realmente una sola vez. Sólo la observación de fallos, réplicas y recuperaciones muestra si dos procesos pueden convertir una respuesta en dos éxitos.

La idea de una especificación inicial mínima delimita un núcleo suficiente: cadena, reto, representaciones, prueba y avance. Los productos pueden variar alrededor; no pueden variar el invariante que consume la respuesta.

La separación entre capas de realidad evita que «contraseña de un solo uso» funcione como amuleto. La realidad incluye un verificador mutable, una escritura atómica, reglas de concurrencia, un inventario finito y una autoridad de reinicialización. Si esas capas no coinciden, el cálculo puede ser correcto y la historia falsa.

La aportación duradera de RFC 1938 es reconocer que una prueba exitosa modifica el mundo donde se juzgará la siguiente. A partir de ahí, autenticar no es leer una verdad: es escribirla con orden.

Fuentes

  1. RFC Editor — estado actual de RFC 1938
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — estado actual de RFC 2289
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP
  7. RFC 6238 — TOTP
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile