Recomendaciones NIST 2025 sobre contraseñas: qué ha cambiado
Por CaptainDNS
Publicado el 20 de febrero de 2026
- El NIST prohíbe ahora la expiración periódica de contraseñas, salvo en caso de compromiso confirmado
- Las reglas de complejidad (mayúscula + número + símbolo) se abandonan: en la práctica, degradan la seguridad
- Mínimo 8 caracteres obligatorios, 15 recomendados, y los sistemas deben aceptar al menos 64 caracteres
- Cada contraseña debe verificarse contra una base de secretos comprometidos (tipo Have I Been Pwned) antes de ser aceptada
- Las pistas de contraseña y preguntas secretas están prohibidas como mecanismos de recuperación
Durante años, las políticas de contraseñas en las empresas seguían la misma receta: 8 caracteres mínimo, una mayúscula, un número, un símbolo, y cambio cada 90 días. Resultado: usuarios que eligen Primavera2025! en enero y Verano2025! en abril. El NIST ha reconocido oficialmente que este enfoque produce contraseñas más débiles, no más fuertes.
La revisión 4 del SP 800-63B, publicada en 2024 y aplicable desde 2025, revierte la mayoría de estas prácticas. Este documento es la referencia federal estadounidense para la autenticación digital, pero su influencia va mucho más allá de las fronteras: ANSSI, BSI y OWASP están alineando progresivamente sus recomendaciones.
Este artículo analiza los cambios concretos, explica la lógica detrás de cada decisión del NIST y proporciona un plan de acción para adaptar tu política de contraseñas. Para probar de inmediato la robustez de una contraseña, utiliza nuestro generador de contraseñas con su indicador de fuerza en tiempo real.
Qué dice el NIST SP 800-63B-4
El SP 800-63B forma parte de la suite NIST SP 800-63 (Digital Identity Guidelines), que cubre todo el ciclo de vida de la identidad digital. La revisión 4 reemplaza la versión 3 de 2017 e introduce cambios importantes en la sección dedicada a los "Memorized Secrets" (contraseñas y frases de paso).
Alcance del documento
El SP 800-63B se dirige a los proveedores de servicios de autenticación (CSP, Credential Service Providers) y a los verificadores. Define tres niveles de seguridad (AAL1, AAL2, AAL3), cada uno con requisitos crecientes. Las recomendaciones sobre contraseñas se aplican principalmente al nivel AAL1 (autenticación por factor único) y sirven como base para los niveles superiores.
Los 8 cambios principales
La siguiente tabla resume las reglas que cambian entre la versión 3 (2017) y la versión 4 (2024/2025):
| Regla | SP 800-63B-3 (2017) | SP 800-63B-4 (2025) |
|---|---|---|
| Longitud mínima | 8 caracteres | 8 obligatorio, 15 recomendado |
| Longitud máxima | No especificada | 64 caracteres mínimo soportado |
| Reglas de complejidad | Desaconsejadas | Prohibidas (SHALL NOT) |
| Rotación periódica | Desaconsejada | Prohibida salvo compromiso |
| Verificación de compromisos | Recomendada | Obligatoria (SHALL) |
| Pistas de contraseña | No mencionadas | Prohibidas |
| Preguntas secretas | Desaconsejadas | Prohibidas |
| Todos los caracteres Unicode | Recomendado | Obligatorio |
El paso de "SHOULD NOT" (desaconsejado) a "SHALL NOT" (prohibido) es significativo: ya no es una recomendación, es un requisito de cumplimiento.
¿Por qué el NIST abandona la rotación obligatoria?
La rotación periódica de contraseñas es la regla más controvertida en seguridad informática. El NIST la prohíbe ahora explícitamente, y la razón es empírica.
El problema documentado
Estudios realizados en la Universidad de Carolina del Norte (Chappell et al.) demostraron que cuando los usuarios se ven obligados a cambiar regularmente su contraseña, adoptan patrones predecibles:
- Incremento:
Contraseña1→Contraseña2→Contraseña3 - Rotación estacional:
Invierno2024!→Primavera2025! - Transformación mínima:
MiGato$→MiGato$1→MiGato$12
Un atacante que obtiene una contraseña anterior puede adivinar la siguiente con menos de 5 intentos en el 41 % de los casos. La rotación no añade seguridad, fomenta la previsibilidad.
La nueva regla
La contraseña solo debe cambiarse en dos casos:
- Compromiso confirmado: la contraseña aparece en una base de datos filtrada
- Solicitud del usuario: cambio voluntario
Los administradores deben eliminar toda política de expiración automática (90 días, 180 días, anual). No obstante, el sistema debe vigilar activamente las bases de compromisos y forzar un cambio si la contraseña actual aparece en ellas.
¿Por qué las reglas de complejidad son contraproducentes?
Exigir "al menos una mayúscula, un número y un símbolo" parece lógico sobre el papel. En la práctica, produce el efecto contrario.
El efecto perverso medido
Cuando un sistema impone reglas de composición, los usuarios convergen hacia las mismas estrategias:
- Mayúscula en primera posición (95 % de los casos)
- Números al final (89 % de los casos)
- Símbolo:
!o@(78 % de los casos)
Password1! cumple todas las reglas de complejidad clásicas. Se descifra en menos de un segundo por cualquier herramienta de fuerza bruta que pruebe patrones comunes. La entropía teórica de una contraseña restringida es más alta, pero la entropía real cae porque los humanos son predecibles.
Lo que recomienda el NIST en su lugar
La longitud es el factor dominante. Una contraseña de 15 caracteres aleatorios sin restricción de composición ofrece más entropía que una contraseña de 8 caracteres que cumple todas las reglas de complejidad. El NIST pide a los sistemas que:
- Acepten todos los caracteres imprimibles ASCII y Unicode (espacios incluidos)
- No impongan reglas de composición
- Soporten como mínimo 64 caracteres (para permitir frases de paso)
- Normalicen las entradas Unicode (NFKC o NFKD) para evitar problemas de codificación
Verificación contra bases de contraseñas comprometidas
Este es el cambio más técnico. Cada contraseña elegida por un usuario debe verificarse contra una lista de secretos comprometidos antes de ser aceptada.
¿Cómo implementar la verificación?
El NIST no prescribe una implementación específica, pero el método más habitual utiliza el servicio Have I Been Pwned (HIBP) de Troy Hunt:
- El sistema calcula el hash SHA-1 de la contraseña candidata
- Envía los 5 primeros caracteres del hash a la API de HIBP (k-anonymity)
- La API devuelve todos los hashes correspondientes
- El sistema verifica localmente si el hash completo está en la lista
Este mecanismo preserva la confidencialidad: la contraseña nunca se transmite en texto plano ni como hash completo. La API de HIBP contiene más de 900 millones de contraseñas únicas procedentes de filtraciones reales.
¿Cuándo verificar?
| Momento | Obligatorio | Recomendado |
|---|---|---|
| Creación de cuenta | Sí | - |
| Cambio de contraseña | Sí | - |
| Inicio de sesión | - | Sí (verificación periódica) |
Si la contraseña se encuentra en la base de compromisos, el sistema debe rechazarla con un mensaje claro explicando el motivo e invitando al usuario a elegir otra.
Lo que el NIST prohíbe explícitamente
Más allá de los cambios principales, varias prácticas están ahora formalmente prohibidas:
Pistas de contraseña
Los campos de "pista" que muestran un recordatorio en caso de olvido están prohibidos. Exponen información que ayuda a un atacante a adivinar la contraseña. Una pista como "nombre de mi gato + año" reduce el espacio de búsqueda a unos pocos miles de combinaciones.
Preguntas secretas
"¿Cuál es el apellido de soltera de tu madre?" o "¿En qué ciudad naciste?": estas preguntas de autenticación basada en conocimiento (KBA) están prohibidas como único factor de recuperación. Las respuestas suelen ser fáciles de encontrar en redes sociales o en bases de datos públicas.
Truncamiento de la contraseña
Un sistema nunca debe truncar la contraseña a una longitud fija antes del hashing. Si un usuario introduce 40 caracteres, los 40 caracteres deben tenerse en cuenta. El truncamiento reduce silenciosamente la entropía y crea una falsa sensación de seguridad.
Hashing sin sal
El NIST exige que las contraseñas se almacenen con una función de hashing resistente (bcrypt, scrypt, Argon2id o PBKDF2) y una sal única por usuario. SHA-256 solo no es aceptable: es demasiado rápido y vulnerable a ataques con tablas arcoíris.
Comparación NIST, OWASP, ANSSI
El NIST no es la única referencia. Así se comparan sus recomendaciones con los demás estándares principales:
| Criterio | NIST SP 800-63B-4 | OWASP ASVS 4.0 | ANSSI (2021) |
|---|---|---|---|
| Longitud mín. | 8 (15 recomendado) | 12 | 12 (16 para admin) |
| Longitud máx. soportada | 64+ | 128 | No especificado |
| Complejidad | Prohibida | Desaconsejada | Aceptada bajo condiciones |
| Rotación | Prohibida salvo compromiso | Desaconsejada | 1 año máx. |
| Verificación de compromisos | Obligatoria | Recomendada | No mencionada |
| MFA | Obligatorio AAL2+ | Obligatorio niv. 2+ | Recomendado |
| Preguntas secretas | Prohibidas | Prohibidas | No mencionadas |
Los tres marcos de referencia convergen en los principios fundamentales (longitud > complejidad, nada de rotación innecesaria) pero difieren en el nivel de exigencia. La ANSSI sigue siendo más conservadora en complejidad y rotación. OWASP es más estricto en longitud mínima.
🎯 Plan de cumplimiento
Para los administradores de sistemas y CISO que necesitan adaptar su política:
- Elimina la expiración periódica: desactiva las políticas de cambio cada 90/180 días en Active Directory, LDAP o tu IAM. Configura la vigilancia de compromisos en su lugar
- Retira las reglas de composición: elimina los requisitos "mayúscula + número + símbolo". Aumenta la longitud mínima a 15 caracteres y el máximo soportado a al menos 64
- Integra la verificación HIBP: implementa la verificación k-anonymity en la creación y el cambio de contraseña. Utiliza un generador de hash para verificar tus implementaciones SHA-1
- Acepta todos los caracteres: Unicode completo, espacios incluidos. Aplica la normalización NFKC antes del hashing
- Despliega MFA: la contraseña sola no basta. FIDO2/WebAuthn para cuentas críticas, TOTP como mínimo para las demás
- Documenta tu política: crea una política escrita alineada con el SP 800-63B-4 y comunica los cambios a los usuarios. Explica por qué ya no tendrán que cambiar su contraseña regularmente
FAQ
¿Qué es el NIST SP 800-63B?
El NIST SP 800-63B es un documento de referencia publicado por el National Institute of Standards and Technology (NIST) de Estados Unidos. Forma parte de la suite Digital Identity Guidelines y cubre específicamente la autenticación y la gestión del ciclo de vida de las credenciales. La revisión 4, publicada en 2024, es la versión vigente y aporta cambios significativos a las recomendaciones sobre contraseñas.
¿Hay que seguir cambiando la contraseña regularmente?
No. El NIST prohíbe explícitamente la expiración periódica de contraseñas (SHALL NOT). Una contraseña solo debe cambiarse si está comprometida (presente en una base de datos filtrada) o si el usuario lo solicita voluntariamente. Los estudios demuestran que el cambio obligatorio lleva a los usuarios a elegir contraseñas predecibles y más débiles.
¿Las reglas de complejidad siguen siendo necesarias?
No. El NIST prohíbe las reglas de composición ("al menos una mayúscula, un número, un símbolo"). Estas reglas generan patrones predecibles (mayúscula al inicio, números al final, símbolo !) que reducen la entropía real. La longitud es el factor dominante: una contraseña larga y aleatoria es más segura que una contraseña corta y "compleja".
¿Cuál es la longitud mínima para una contraseña en 2025?
El NIST impone un mínimo de 8 caracteres y recomienda 15. OWASP y ANSSI recomiendan 12. En la práctica, apunta a 15+ caracteres para cuentas de usuario y 20+ para cuentas de administrador. Los sistemas deben aceptar como mínimo 64 caracteres para permitir el uso de frases de paso.
¿Cómo verificar si una contraseña está comprometida?
Utiliza el protocolo k-anonymity con la API de Have I Been Pwned: haz el hash de la contraseña en SHA-1, envía los 5 primeros caracteres del hash a la API y verifica si el hash completo aparece en los resultados. La contraseña nunca se transmite en texto plano. Esta verificación debe realizarse al crear la cuenta y en cada cambio de contraseña.
¿Se aplica el NIST fuera de Estados Unidos?
El SP 800-63B es una norma federal estadounidense, pero su influencia es mundial. OWASP se inspira directamente en él, el BSI alemán y la ANSSI francesa están alineando progresivamente sus recomendaciones. Para empresas internacionales o las que tratan datos de ciudadanos estadounidenses, seguir el NIST es un estándar de facto, incluso sin obligación legal directa.
¿Qué algoritmo de hashing usar para almacenar contraseñas?
El NIST recomienda Argon2id, bcrypt, scrypt o PBKDF2, con una sal única por usuario. SHA-256 o MD5 solos son inaceptables: son demasiado rápidos y vulnerables a ataques con tablas arcoíris y fuerza bruta por GPU. Argon2id es la opción recomendada por OWASP en 2025, con parámetros de memoria y tiempo adaptados a tu infraestructura.
Glosario
- SP 800-63B: Special Publication del NIST que define los requisitos de autenticación digital, parte B (Authentication and Lifecycle Management). La revisión 4 (2024) es la versión vigente.
- AAL (Authentication Assurance Level): nivel de seguridad de la autenticación definido por el NIST, desde AAL1 (factor único) hasta AAL3 (hardware criptográfico resistente al phishing).
- k-anonymity: técnica criptográfica que permite verificar si un dato pertenece a un conjunto sin revelar el dato en sí. Utilizada por Have I Been Pwned para la verificación de contraseñas.
- Sal (salt): valor aleatorio único que se añade a la contraseña antes del hashing, impidiendo los ataques con tablas precalculadas (rainbow tables).
- Argon2id: función de hashing de contraseñas ganadora de la Password Hashing Competition (2015), resistente a ataques por GPU y ASIC gracias a su consumo de memoria configurable.
Verifica la robustez de tus contraseñas ahora: comprueba si tus URLs están siendo explotadas para phishing con nuestro detector de phishing, un complemento esencial para cualquier política de contraseñas sólida.
📚 Guías de seguridad de contraseñas relacionadas
- Passkeys vs contraseñas: ¿deberías abandonar tus contraseñas en 2025?
- Frase de paso vs contraseña: ¿qué es realmente más seguro?
