Política de contraseñas moderna: adiós al cambio cada 90 días según NIST

1. Introducción
La política de contraseñas de tu empresa probablemente aún obliga a cambiar las contraseñas cada 90 días y a combinar mayúsculas, minúsculas, números y símbolos. Esas dos reglas, omnipresentes en las empresas españolas, están desacreditadas por el propio estándar de referencia: la NIST SP 800-63B. En este artículo te explicamos qué dice el estándar, por qué la caducidad arbitraria y la complejidad superficial no protegen nada y cómo construir una Política de contraseñas empresas moderna, alineada con las directrices que NIST publicó a partir de 2017 y actualizó en 2024.
La razón de fondo es simple: el atacante actual no «adivina» contraseñas en el teclado, las compra, las roba por phishing o las descifra con hardware dedicado a miles de millones de intentos por segundo. Frente a ese arsenal, obligar al empleado a añadir un «!» al final y cambiarlo todo cada trimestre solo consigue contraseñas más predecibles y más reutilizadas.
Veremos las cinco reglas del estándar, los algoritmos de hash correctos, la comprobación contra filtraciones, el Kerberoasting en Active Directory y el horizonte passkey.
2. Por qué la política clásica fracasa
Los números del descifrado de contraseñas explican la obsolescencia de la política clásica. Una tarjeta gráfica RTX 4090 alcanza unos 165.000 millones de hashes MD5 por segundo, unos 300.000 millones en el caso de NTLM, el formato con el que Active Directory almacena las contraseñas de usuario. Una contraseña de 8 caracteres alfanuméricos se agota en minutos. Por eso la política de contraseñas empresas de 2026 debe empezar por asumir estos números.
El ejemplo del libro es ilustrativo: «Madrid2024!», que cumple todas las reglas imaginables (mayúscula, minúscula, dígitos, símbolo y referencia local), se descifra en segundos. La complejidad superficial no protege, porque las reglas de transformación añaden «2024» y «!» por puro patrón y el descifrado parte de diccionarios con miles de millones de entradas.
La caducidad de 90 días, por su parte, produce el efecto contrario al deseado: empuja a la reutilización de contraseñas entre sistemas, induce variaciones triviales («Patata1», «Patata2») y aumenta la carga cognitiva del empleado, que acaba pegando la contraseña en una nota. NIST reconoce hoy que forzar rotaciones periódicas sin un incidente concreto incrementa la debilidad del conjunto.
3. Las reglas de NIST SP 800-63B
La NIST SP 800-63B (Digital Identity Guidelines) propone un modelo que hoy es criterio de referencia para auditorías y certificaciones. La comparativa con la política clásica resume el cambio de paradigma:
| Criterio | Política clásica | NIST SP 800-63B |
|---|---|---|
| Regla principal | Complejidad (mayúsculas, símbolos…) | Longitud: mínimo 8, recomendado 12+ |
| Caducidad | Cambio forzado cada 90 días | Sin caducidad arbitraria |
| Longitud máxima | 20 caracteres, sin espacios ni pegar | Hasta 64 caracteres, passphrases |
| Comprobaciones | No se consultan filtraciones | Criba contra HIBP (>14.000 M filtradas) |
| Almacenamiento | Hash rápido no documentado | Argon2id o bcrypt coste 12+ |
| Bloqueo | Bloqueo duro tras N intentos | Rate limiting progresivo (1-5-15 min) |
Fig. 1 – Comparativa entre la política de contraseñas clásica y la NIST SP 800-63B.
Sobre esas cinco reglas se construye una Política de contraseñas empresas moderna: longitud por encima de complejidad, sin rotación forzada salvo incidente o sospecha, sin reglas restrictivas de contenido, criba contra contraseñas filtradas en creación y cambio, y facilitar el pegado desde gestor de contraseñas en lugar de penalizarlo. Con contraseñas largas y MFA activo en la cuenta, la caducidad deja de ser un control relevante.
Las cuentas privilegiadas merecen un escalón propio: mínimos de 16 caracteres, gestor con jerarquización y rotación automática tras cada uso, y criba contra filtraciones en el alta. La NIST también recomienda verificar la contraseña contra listas de filtraciones como petición previa al alta: la mayoría de las contraseñas filtradas son de baja entropía técnica, pero reutilizadas y por tanto predecibles.
4. Almacenar hashes como un profesional
La política solo es real si el almacenamiento de credenciales sigue el mismo criterio. Los hashes rápidos (MD5, SHA-1, SHA-256) son inutilizables para contraseñas: la asimetría entre el coste del atacante y el del defensor se invierte por completo. El estado del arte son los algoritmos de propósito específico con factor de trabajo: Argon2id, ganador del Password Hashing Competition, y bcrypt con coste igual o superior a 12, que ralentiza el descifrado en unas seis órdenes de magnitud:
# Velocidades de cracking con una RTX 4090 (OnlineHashCrack, 2025)
MD5 ~165.000 millones de hashes/s # inaceptable
NTLM ~300.000 millones de hashes/s # inaceptable (AD legacy)
SHA-256 ~22.000 millones de hashes/s # inaceptable
bcrypt cost 12 ~200.000 hashes/s # 10^6 veces más lento
Argon2id decenas de miles h/s # estado del arte
# Cada hash debe llevar un salt único de al menos 16 bytes
Fig. 2 – Velocidades de descifrado según el algoritmo, con una RTX 4090.
La diferencia entre 165.000 millones y 200.000 intentos por segundo no es cosmética: es la diferencia entre agotar un diccionario en segundos y necesitar siglos. Además, cada contraseña requiere un salt único, y el saneamiento debe cubrir también los sistemas heredados: la AEPD ya ha sancionado a organizaciones por mantener hashes obsoletos o sin salt, por violación del deber de protección del RGPD.
5. Lo que ya está en la calle: HIBP y los logs de infostealers
La comprobación contra filtraciones no es opcional. Have I Been Pwned (HIBP) centraliza más de 14.000 millones de contraseñas conocidas y expone una API con anonimato por k-anonymity: se envía solo el prefijo del hash de la contraseña y se recibe la lista de coincidencias, sin revelar el valor original. Integrar esa comprobación en el alta y en el cambio es la forma más barata de impedir que un empleado use una combinación que el atacante ya tiene en su diccionario.
El mercado de credenciales robadas complementa el problema. Además de las grandes filtraciones, los logs de infostealers (RedLine, Lumma, Vidar, StealC) se venden en mercados clandestinos por 5-50 dólares por log, con contraseñas del navegador, cookies de sesión y datos de autocompletado. La vigilancia de credenciales filtradas propias del dominio — vía inteligencia de amenazas — es la otra mitad del cribado: NIST recomienda tratar como comprometidas las credenciales que aparecen en la calle, aunque tu sistema nunca fuese el origen.
6. Cuentas de servicio y Kerberoasting
La política de contraseñas no termina en los usuarios: las cuentas de servicio son el talón de Aquiles de Active Directory. El Kerberoasting es el arma preferida contra el directorio: cualquiera autenticado en el dominio solicita tickets de servicio cifrados con el hash NTLM de las cuentas SPN y los descifra fuera de línea con Hashcat en modo 13100. La defensa es doble — gMSA con rotación automática o contraseñas de servicio de al menos 25 caracteres — y se comprueba con la misma herramienta del atacante:
# Revisión defensiva de cuentas de servicio contra Kerberoasting
# 1. Extraer tickets de cuentas SPN como haría un atacante
hashcat -m 13100 tickets.txt rockyou.txt --rules best64.rule
# 2. Auditar longitud real de las contraseñas de servicio
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties *
# 3. Migrar a gMSA (managed service accounts) o ≥25 caracteres
Add-KdsRootKey -EffectiveImmediately
New-ADServiceAccount -Name svc_pagos -Enabled $true
Fig. 3 – Comprobación defensiva de cuentas SPN contra Kerberoasting.
La misma jerarquía se aplica a otras rutas de robo offline: el AS-REP Roasting (Hashcat modo 18200, evitable sin marcar «no usar preautenticación»), el Pass-the-Hash y el Pass-the-Ticket exigen endurecer LSASS (Credential Guard, Restricted Admin Mode) y usar modelos de niveles administrativos. Si compruebas la longitud real de las cuentas SPN de tu dominio, descubrirás casi siempre contraseñas de 10 caracteres con años de antigüedad: ese es el objetivo número uno de los ataques internos.
7. Gestores, MFA y el horizonte passkey
Ninguna política sobrevive al contacto con la realidad si el empleado no tiene un gestor de contraseñas corporativo. NIST exige explícitamente permitir el pegado desde el gestor y soportar contraseñas de hasta 64 caracteres precisamente para que las passphrases sean viables. Los gestores del navegador son una comodidad insuficiente: son el primer objetivo de los infostealers. Un gestor corporativo (Bitwarden, 1Password, Dashlane, Keeper, incluso self-hosted) con repositorios compartidos, recuperación de emergencia y proceso de baja asume esa función de forma segura.
El MFA jerarquizado acompaña a la contraseña en todas las cuentas relevantes: SMS solo como último recurso, TOTP como base aceptable, push con number matching contra el MFA fatigue, y FIDO2/WebAuthn (llaves de seguridad, passkeys, Windows Hello con TPM) como factor resistente al phishing, el único que sobrevive a los ataques AiTM con Evilginx y compañía, de los que hablamos en profundidad en nuestro análisis de los ataques MITM a credenciales.
El horizonte a medio plazo es la reducción estructural del factor contraseña: los passkeys sustituyen el secreto compartido por criptografía asimétrica con biometría local, lo que hace estructuralmente imposible el phishing y el credential stuffing. Cuando un passkey no puede ser robado ni descifrado, la política de contraseñas deja de ser el eslabón débil.
8. Qué hacer cuando una contraseña se compromete
Cuando se confirma el compromiso de una credencial, la rotación ya no es un trámite: se cambia la contraseña afectada y las reutilizadas, se revocan sesiones y tokens OAuth, se analiza la actividad de la cuenta (geografías, horarios, descargas masivas, reenvíos) y se busca movimiento lateral; si la cuenta era privilegiada, la revisión alcanza a todo el directorio. El protocolo completo, con los plazos de notificación, está descrito en nuestro artículo sobre acciones tras el secuestro o pérdida de credenciales. El enfoque moderno trata cualquier sospecha con la seriedad de una filtración confirmada: el falso positivo cuesta poco; el acceso silencioso, todo.
9. Conclusión
La Política de contraseñas empresas moderna no es más indulgente, es más inteligente: longitud sobre complejidad, sin caducidad arbitraria, criba contra las más de 14.000 millones de contraseñas filtradas, almacenamiento con Argon2id o bcrypt coste 12, cuentas de servicio inmunes al descifrado offline con gMSA o 25 caracteres, y gestor corporativo con MFA jerarquizado.
Eliminar el cambio de contraseña cada 90 días no es una relajación de la seguridad, es la decisión que permite concentrar recursos donde sí importan: detectar filtraciones, endurecer los factores de autenticación y avanzar hacia un modelo sin contraseñas. Revisar la política de contraseñas empresas es una decisión de dirección, no un trámite de TI: la normativa clásica protegía de un ataque de 2005, y la de 2026 se construye con datos de 2026.
¿Necesitas ayuda con Política de contraseñas empresas?
En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.
Contacta con nosotros para una evaluación gratuita de tu infraestructura.


