Los requisitos de la directriz sí abarcan la longitud de las contraseñas, los autenticadores sincronizables, el correo electrónico, los códigos por teléfono y SMS, y los tiempos de expiración de sesión. El material revisado para este artículo no define qué se considera resistente al phishing, así que esta guía se ciñe a lo que dice el texto de la directriz y señala como tal nuestra propia interpretación allí donde aparece.
Qué es la directriz de autenticación del NIST y a quién se dirige
La versión final de SP 800-63B-4 figura en su historial del documento con fecha del 31 de julio de 2025, según consta en la página de la publicación del NIST en csrc.nist.gov. Cuando este artículo cita un requisito, indica quién debe cumplirlo, porque la directriz asigna sus obligaciones a partes concretas.
Muchos de los requisitos se aplican a los verificadores y a los CSP, las partes que menciona la sección de autenticadores del NIST en pages.nist.gov. Otros se aplican a las agencias federales. Por ejemplo, el texto de la directriz del NIST en pages.nist.gov establece que las agencias federales deben seleccionar al menos AAL2 cuando se ponga información personal a disposición en línea.
Nuestra interpretación: estas reglas están escritas para las organizaciones que gestionan sistemas de inicio de sesión, no como instrucciones para quienes tienen cuentas en un bróker, un exchange o un servicio de correo. Aun así, pueden ayudar al lector a entender qué opciones de acceso ofrece un servicio y por qué. Por sí solas, no muestran cómo protege a sus usuarios un servicio en particular.
Contraseña frente a MFA: qué exige el texto a las contraseñas
La regla más clara sobre contraseñas entre las afirmaciones revisadas se refiere a las contraseñas usadas por sí solas. Según la sección de autenticadores del NIST en pages.nist.gov, los verificadores y los CSP deben exigir que las contraseñas empleadas como mecanismo de autenticación de un solo factor tengan al menos 15 caracteres.
Como contexto histórico, las preguntas frecuentes del NIST sobre identidad digital describen el antiguo modelo LOA. Señalan que, en lo relativo a los autenticadores, la mayor diferencia entre LOA1 y LOA2 era que la longitud mínima de la contraseña pasaba de seis a ocho caracteres.
| Regla en las afirmaciones revisadas | Fuente |
|---|---|
| Contraseñas de un solo factor: al menos 15 caracteres, exigidos por verificadores y CSP | Sección de autenticadores del NIST |
| Antiguo modelo LOA: la longitud mínima de la contraseña pasó de seis a ocho caracteres entre LOA1 y LOA2 | Preguntas frecuentes del NIST |
Nuestra interpretación: cuando la contraseña es el único factor, el texto actual pide un mínimo mucho más largo que las cifras del antiguo modelo LOA. Las afirmaciones revisadas no fijan una longitud concreta para las contraseñas usadas como uno de los factores dentro de una MFA, de modo que este artículo no ofrece ninguna.
Passkeys, autenticadores sincronizables y AAL3
Las afirmaciones revisadas nunca emplean la palabra «passkey». Sí tratan una categoría relacionada: los autenticadores sincronizables. El texto de la directriz del NIST en pages.nist.gov establece que los autenticadores sincronizables no deben usarse en AAL3 porque requieren que la clave privada sea exportable.
Esa frase recoge a la vez una regla y su justificación declarada:
- La regla: los autenticadores sincronizables quedan excluidos en AAL3.
- La justificación declarada: requieren que la clave privada sea exportable.
Lo que este artículo no puede resolver a partir de las afirmaciones revisadas:
- Si un producto concreto que se vende o se presenta como passkey es un autenticador sincronizable.
- Cómo trata la directriz a los autenticadores sincronizables en niveles distintos de AAL3.
- Si alguna passkey cumple una definición de resistencia al phishing.
Nuestra interpretación: quien compare una passkey con una MFA basada en contraseña debería averiguar primero si la passkey en cuestión sincroniza su clave. Esa es la propiedad sobre la que gira esta regla. Como las afirmaciones no van más allá, dejamos sin resolver la clasificación de passkeys concretas.
Correo electrónico, SMS y códigos telefónicos en el inicio de sesión multifactor
Varios segundos pasos habituales aparecen en las afirmaciones revisadas. La sección de autenticadores del NIST en pages.nist.gov indica que el correo electrónico no debe usarse para la autenticación fuera de banda. La misma sección establece que la autenticación fuera de banda debe considerarse inválida a menos que se complete en un plazo de 10 minutos.
Los códigos por teléfono y SMS se tratan en las preguntas frecuentes del NIST sobre identidad digital. Allí se indica que los autenticadores que utilizan la red telefónica pública conmutada, incluidos los OTP por teléfono y por SMS, están restringidos. Las afirmaciones revisadas no explican qué implica en la práctica esa «restricción», así que este artículo no entra en más detalle.
| Método | Qué dicen las afirmaciones revisadas |
|---|---|
| Correo electrónico para autenticación fuera de banda | No debe usarse |
| Autenticación fuera de banda en general | Inválida salvo que se complete en 10 minutos |
| OTP por teléfono y por SMS | Restringidos |
Nuestra interpretación: «MFA» engloba varios tipos de segundo paso, y la directriz no los trata a todos por igual. A quien revise las opciones de acceso de una cuenta de correo, de un bróker o de un exchange, esta distinción puede resultarle útil, pero estas reglas no indican qué opción utiliza un servicio determinado ni qué tal funciona.
Tiempos de reautenticación en AAL2 y AAL3
Las reglas de sesión también varían según el nivel. El texto de la directriz del NIST en pages.nist.gov establece que en AAL2 debe fijarse un tiempo máximo global de reautenticación definido, que debería ser de no más de 24 horas. En AAL3, el tiempo máximo global de reautenticación debe ser de no más de 12 horas.
| Nivel | Tiempo máximo global de reautenticación |
|---|---|
| AAL2 | Debe fijarse; debería ser de no más de 24 horas |
| AAL3 | Debe ser de no más de 12 horas |
Conviene fijarse en la redacción. En AAL2 el límite usa «should» (debería), mientras que en AAL3 usa «must» (debe). Este artículo mantiene esa diferencia en lugar de presentar ambos límites como igual de vinculantes.
Nuestra interpretación: si un servicio te pide volver a iniciar sesión pasado cierto tiempo, eso puede responder a una política de expiración de este tipo. Las afirmaciones no dicen cómo fija sus tiempos cada servicio concreto.
Qué es resistente al phishing y cómo valorar lo que se afirma al respecto
Las afirmaciones revisadas procedentes del texto de la directriz del NIST en pages.nist.gov no incluyen una definición de resistencia al phishing. Tampoco dicen si las passkeys, los autenticadores sincronizables o cualquier otro método cumplen alguna. Este artículo deja esa pregunta abierta a propósito. No toma prestada una definición de resúmenes secundarios que la revisión de evidencias no cubrió.
Esa cautela vale para las afirmaciones sobre seguridad en general. La guía de consejos rápidos de CERT.br señala que un rumor suele tener un tono alarmista, trata temas que están captando atención en ese momento y no tiene fuente de información o cita fuentes desconocidas. Un hábito relacionado, según nuestra interpretación: cuando un mensaje o una publicación diga que un método de inicio de sesión es seguro o inseguro, busca el texto primario en el que se apoya y comprueba si la redacción original dice «must» (debe), «should» (debería) o algo más débil.
Esto es lo que este artículo puede y no puede responder sobre la pregunta de partida:
- Respondido a partir de las afirmaciones: reglas sobre la longitud de las contraseñas de un solo factor, el correo electrónico y los plazos de la autenticación fuera de banda, los códigos por teléfono y SMS, los autenticadores sincronizables en AAL3 y los tiempos de reautenticación.
- Queda abierto: una definición de resistencia al phishing y cómo encajan en ella passkeys concretas.
Límites de este artículo
Este artículo ofrece información educativa sobre directrices de autenticación publicadas. No constituye asesoramiento de inversión ni recomienda ningún producto, bróker, exchange o servicio. No abarca partes de la directriz del NIST más allá de las afirmaciones enumeradas aquí, ni define la resistencia al phishing. No evalúa cómo protege a sus usuarios ninguna cuenta o servicio específico.