El Instituto Nacional de Estándares y Tecnología ha finalizado una publicación orientada a ayudar a las organizaciones a evitar exponer tokens de identidad y acceso en línea a los atacantes. Según el anuncio de la agencia, el documento finalizado está diseñado para ayudar a las organizaciones a adoptar medidas eficaces que mantengan esos tokens fuera de manos equivocadas.

Eso es todo lo que dice el resumen del anuncio de NIST. No nombra, en el material disponible al momento de redactar este artículo, formatos de token específicos, no enumera controles requeridos, no establece plazos ni impone obligaciones de cumplimiento. Los lectores que busquen una lista de verificación deberán abrir la publicación en sí. El anuncio está publicado en nist.gov.

Por qué esto importa no es ningún misterio para quien haya pasado tiempo en un canal de respuesta a incidentes. Los tokens son lo que demuestra que un inicio de sesión ya ocurrió. Las cookies de sesión, los tokens de acceso OAuth, los refresh tokens, las aserciones SAML y los ID tokens de OIDC permiten a su portador saltarse la puerta principal. Robar uno significa que el atacante no necesita la contraseña, no necesita el segundo factor y no activa el elegante prompt de MFA que todos estuvieron desplegando el año pasado. El cerrojo de la puerta es excelente. La llave está en el almacenamiento local del navegador, o en un archivo de log, o en la captura de pantalla de un ingeniero de soporte.

Esa es la incómoda ironía de la identidad moderna. Las organizaciones han mejorado de forma medible en el momento de la autenticación y se han vuelto comparativamente descuidadas con todo lo que sucede después. El token es la prueba de trabajo, y la prueba de trabajo es portable.

Que NIST publique una guía finalizada sobre este tema indica que la protección de tokens es ahora una preocupación de primer orden para un organismo de estándares estadounidense, no una nota al pie en un documento de autenticación más amplio. Para las agencias federales de EE. UU. y los contratistas que siguen las publicaciones de NIST por política o por contrato, eso suele tener peso. Para todos los demás, las guías de NIST tienen la costumbre de convertirse en el punto de referencia que auditores, aseguradoras y clientes mencionan, generalmente uno o dos años después de los hechos y justo antes de una renovación.

Lo que el anuncio no dice merece señalarse con claridad, porque la tentación de llenar vacíos con suposiciones es fuerte:

• No indica si la publicación es una Special Publication, un Interagency Report u otra serie documental, ni proporciona su número.
• No especifica qué tipos de tokens o protocolos están dentro del alcance.
• No establece ningún calendario de implementación, mecanismo de cumplimiento ni mapeo con las directrices de identidad digital existentes de NIST.
• No incluye citas del personal de NIST sobre el contenido ni sobre el proceso de redacción.

Nada de esto es una crítica. Los resúmenes de anuncios son breves por diseño. Son simplemente aspectos que deben confirmarse cotejando el texto del documento, en lugar de reportarse como hechos establecidos.

Lo alentador es que este es uno de los pocos ámbitos donde la historia defensiva es genuinamente buena. El robo de tokens es un problema bien comprendido con mitigaciones bien comprendidas, y la mayoría de los proveedores de identidad ya incluyen las funciones relevantes. Tokens de acceso de corta duración, rotación de refresh tokens, tokens vinculados al emisor, atributos de cookies que impiden que los scripts lean el material de sesión, y evaluación continua que revoca una sesión cuando el dispositivo o la red deja de comportarse como se esperaba. La parte difícil nunca fue la tecnología. La parte difícil fue conseguir que alguien la activara cuando la página de inicio de sesión ya funcionaba y nadie se quejaba.

Una publicación finalizada de NIST le da a los equipos de identidad algo que a menudo les falta: un documento con el sello del gobierno que pueden presentar ante los responsables de producto que consideran que un tiempo de espera de sesión de 24 horas es un acto de crueldad. Eso no es poca cosa. La mitad de la ingeniería de identidad consiste en tener el documento adecuado en la reunión adecuada.

En términos prácticos, los equipos deberían consultar la publicación completa y compararla con su gestión actual de tokens, en lugar de confiar en este resumen o en cualquier otro. Verifiquen cuánto tiempo viven los tokens de acceso y las sesiones en cada proveedor de identidad y aplicación, si los refresh tokens rotan y se revocan al reutilizarse, y si las cookies de sesión incluyen los atributos HttpOnly, Secure y SameSite. Luego revisen los lugares aburridos donde los tokens se filtran: logs de aplicaciones, parámetros en query strings de URLs, informes de fallos y herramientas de soporte. Encontrar un bearer token activo en un archivo de log es vergonzoso, pero encontrarlo antes que un atacante es una buena semana, así que vayan a tener una buena semana.