Resumen

  • RFC 9807 permite registrar y autenticar a un cliente sin revelar su contraseña al servidor, aunque la filtración del registro y de los secretos pertinentes de un servidor único todavía habilita el inevitable ataque exhaustivo sin conexión contra esa cuenta.
  • La arquitectura de oprf_seed decide si el daño queda acotado a un usuario o adquiere una dimensión transversal; las semillas independientes, las respuestas falsas, el umbral OPRF y el nuevo registro ofrecen contención a cambio de otras obligaciones.

Una contraseña puede dejar de ser visible sin que el sistema deje de tener un centro de gravedad.

Esa es la lección menos comercial y más útil de RFC 9807. OPAQUE es un intercambio de claves autenticado por contraseña aumentada. El cliente usa una función seudoaleatoria obliviosa, una envoltura para recuperar credenciales y un intercambio autenticado. Demuestra que conoce la contraseña y obtiene una clave de sesión con el servidor, pero nunca entrega la contraseña al otro extremo, tampoco durante el alta.

La clasificación institucional merece el mismo cuidado que la explicación criptográfica. La ficha del RFC Editor y el Datatracker sitúan el texto en la corriente IRTF, con categoría Informational y consenso del Crypto Forum Research Group. El propio documento aclara que no es un producto del IETF ni un estándar. La entrada del directorio IETF es un enlace útil, no una licencia para transformar investigación publicada en mandato normativo.

Lo que cambia al no entregar la contraseña

En el modelo habitual, TLS 1.3 protege la contraseña hasta el punto de terminación. Después, la aplicación puede verla, copiarla en memoria, registrarla por error o enviarla a otro componente. La seguridad del canal no controla la conducta del receptor.

OPAQUE sustituye el objeto transmitido. En el OPRF de RFC 9497, el servidor conserva la clave de la función y el cliente aporta una entrada cegada. El cliente recibe el resultado; el servidor no conoce ni la entrada ni la salida. El cliente estira ese resultado y construye la envoltura que protege su material privado de autenticación.

La conexión en línea consta de KE1, KE2 y KE3. El tercer mensaje aporta autenticación explícita del cliente. Emitir KE2 no significa que la sesión haya terminado correctamente. Un registro operativo riguroso solo cuenta éxito después de recibir un KE3 válido y completar ServerFinish. De lo contrario, la implementación puede respetar el protocolo mientras el sistema antifraude interpreta intentos incompletos como accesos verificados.

También deben separarse las salidas. La session_key es compartida y sirve a la sesión. La export_key queda solo del lado cliente y puede proteger otros datos; no debe usarse antes de autenticar al servidor. Ninguna de las dos decide si la aplicación autoriza una acción. Criptografía, identidad y permiso producen comprobantes distintos.

El ataque de diccionario empieza más tarde, no desaparece

El trabajo original sobre OPAQUE define la promesa sin adornos. Tras comprometer un servidor único, atacar sin conexión la contraseña individual asociada al archivo filtrado es inevitable en un aPAKE. La defensa fuerte consiste en impedir que el adversario precalcule una tabla útil antes de la intrusión. Debe obtener material secreto nuevo y pagar el coste de cada candidato después del incidente.

La KSF eleva ese coste. RFC 9807 propone configuraciones con Argon2id o scrypt; RFC 9106 documenta Argon2. Sin embargo, el cálculo se ejecuta en el cliente. Una configuración que frena al atacante también consume memoria, batería y tiempo de los usuarios legítimos. La cifra que importa no es el promedio en un portátil moderno, sino la cola de latencia y error en los dispositivos más modestos que la organización ha prometido soportar.

OPAQUE no impide las conjeturas en línea, no corrige contraseñas pobres y no protege un dispositivo que expone la contraseña antes del cegado. Tampoco vuelve inocua una filtración de servidor. Sí evita que el servidor aprenda el secreto reutilizable, dificulta el precálculo, ofrece autenticación mutua y añade confidencialidad futura frente a la revelación posterior de la contraseña. Mantener ese perímetro exacto es una señal de confianza, no una rebaja del logro.

La raíz compartida detrás de claves distintas

El servidor prepara una pareja de claves AKE y una oprf_seed. Con la semilla y un identificador de credencial único deriva una clave OPRF específica para cada cliente. Las hojas son individuales; el tronco puede ser común.

Por eso «una clave por usuario» no basta para describir el riesgo. Si el mismo secreto raíz está disponible en todos los inicios de sesión y custodiado dentro de un único dominio, una intrusión que lo alcance cruza fronteras de cuenta. RFC 9807 aconseja una semilla común cuando se usa su mecanismo de resistencia a la enumeración, pero la sección 10.9 reconoce expresamente que la filtración de esa semilla compromete a todos los clientes que dependen de ella.

El estudio de 2024, (Strong) aPAKE Revisited, examinó la variante multiusuario del borrador. No sostiene que la semilla por sí sola descifre cada contraseña. El recorrido es más preciso: el archivo comprometido de un usuario revela la semilla global; con ella se deriva la clave OPRF de otro usuario; una interacción inocua con el servidor honesto aporta lo necesario para trasladar fuera de línea el ataque contra ese segundo usuario. El RFC definitivo cita el análisis e incorpora su límite.

Una aplicación que no necesite la protección de enumeración descrita puede usar semillas independientes. Así evita una raíz transversal, pero debe preservar de forma estable la correspondencia entre identidad y semilla durante el registro y cada conexión. Una restauración incoherente o un camino de búsqueda alternativo puede filtrar la existencia de una cuenta y provocar bloqueos. Distribuir el secreto genera estado operativo que también necesita copias, recuperación, auditoría y pruebas.

Aquí resulta útil la primacía del código que funciona. «Clave individual» es una propiedad de derivación. La realidad se observa preguntando qué puede extraer un administrador, un proceso, un enclave, una copia de respaldo o un equipo de incidentes, y cuántas cuentas puede probar con ello.

La privacidad de existencia es otro objetivo

Para una identidad no registrada, el servidor puede fabricar una CredentialResponse falsa. La masking_key, creada por el cliente durante el alta, cifra la respuesta para que el caso real y el simulado parezcan iguales. El tiempo, los errores y las ramas internas también deben evitar diferencias observables.

La cobertura termina en la entrada al registro. Durante el alta, el servidor debe tratar de forma distinta una identidad existente y una nueva; por tanto, ese flujo sigue siendo un oráculo y debe limitarse o restringirse. Además, la respuesta falsa puede costar al servidor menos que la solicitud al cliente, creando una superficie de abuso.

La propia clave de enmascaramiento necesita confidencialidad durante el registro. RFC 9807 exige un canal autenticado, confidencial e íntegro, menciona TLS y remite a HPKE para construir confidencialidad cuando el canal inicial solo autentica. Ocultar la contraseña no permite descuidar el momento que instala el resto de los secretos.

La decisión entre semilla común e independiente combina privacidad de identidad, radio de compromiso, coherencia de estado y coste de operación. La idea de especificación mínima y decisión futura localizada encaja aquí: el protocolo delimita una construcción interoperable; el responsable local debe declarar qué amenaza de enumeración está comprando y qué concentración acepta a cambio.

OPRF, AKE y registros no son el mismo cofre

La oprf_seed, la clave privada AKE y la base de RegistrationRecord habilitan ataques diferentes. RFC 9807 señala que un HSM puede ejecutar la operación AKE sin exportar la clave privada. Si se filtran la semilla y las envolturas, mantener la capacidad AKE fuera del alcance puede impedir la suplantación del servidor. No evita, por sí solo, las pruebas de contraseña facilitadas por la combinación de OPRF y registros.

Un mapa de custodia debe responder por separado quién puede evaluar OPRF y para cuántos usuarios, quién puede invocar AKE y quién puede copiar y relacionar registros con identidades. Tres servicios bajo la misma cuenta administrativa, el mismo respaldo y el mismo equipo de recuperación siguen siendo un solo dominio.

Un OPRF de umbral cambia la primera frontera. El RFC observa que podría obligar al adversario a controlar suficientes participaciones o a permanecer en línea. Si los servidores OPRF están separados del servidor de autenticación, reunir las participaciones no basta sin la base de registros. El diseño original admite esa distribución, pero RFC 9807 la deja fuera de alcance. No hay recibo de descentralización hasta demostrar custodios independientes, quórum, disponibilidad, revocación y separación respecto de los registros.

Los componentes de HKDF, el hash a curvas de RFC 9380 y los requisitos PAKE de RFC 8125 son piezas necesarias. No garantizan la composición concreta, la aleatoriedad, el tiempo constante ni el procedimiento de crisis.

La verdadera migración ocurre al volver a registrar

Cambiar una suite criptográfica parece un despliegue hasta que el estado del usuario está ligado a ella. RFC 9807 dice que modificar algoritmos, parámetros KSF o material como la clave pública del servidor obliga a crear un nuevo RegistrationRecord. Cambiar la contraseña también es una inscripción fresca con valores aleatorios nuevos.

Por eso una versión nueva del servidor no demuestra agilidad. Siguen existiendo cuentas dormidas, clientes antiguos, recuperaciones incompletas y datos vinculados a la export_key anterior. Con millones de registros, la configuración se convierte en dependencia: abandonar el dominio antiguo exige presencia o recuperación de cada usuario.

Las capas de realidad permiten no confundir tres estados. El software nuevo puede estar disponible. Los registros nuevos pueden cubrir solo una fracción. El secreto anterior puede seguir siendo válido mientras exista un camino de compatibilidad. El informe de migración debe separar esas verdades.

El comprobante es un padrón por cohortes: cuentas aptas, registros renovados, registros antiguos todavía aceptados, cuentas inactivas, fallos de recuperación, dispositivos incapaces de asumir la nueva KSF, datos dependientes de la antigua clave de exportación, uso del modo de respaldo y fecha efectiva de retirada de los secretos históricos.

OPAQUE responde bien a una pregunta delimitada: cómo autenticar una contraseña sin entregarla al servidor y sin permitir precálculo reutilizable. La dirección fracasa si convierte esa respuesta en un certificado general.

La contraseña abandonó la vista del servidor. El poder se trasladó a raíces de derivación, registros, operaciones privadas, simulación de respuestas, capacidad del cliente y estado de migración. Solo un mapa verificable convierte ese traslado en reducción de riesgo.

Sources