Reglas de complejidad de contraseñas obsoletas: qué usar ahora

Por qué las reglas de complejidad de contraseñas están obsoletas (y qué usar en su lugar)

La complejidad de contraseñas es una regla de política que exige que una contraseña combine tipos de caracteres (mayúsculas, minúsculas, dígitos y símbolos) bajo la suposición de que una mayor variedad de caracteres produce mayor entropía y mayor resistencia a los intentos de adivinación.

P@ssw0rd123! probablemente cumple con todas las reglas de complejidad que aplica su Política de Grupo. También le toma a un equipo GPU moderno aproximadamente 2 segundos descifrarlo, porque el patrón detrás de él es una de las primeras cosas que cualquier diccionario de cracking intenta.

Ese es el fallo principal. Las reglas de complejidad fueron diseñadas para aumentar la entropía, pero los usuarios convergieron en sustituciones predecibles, anotaron las contraseñas y reutilizaron la misma credencial en una docena de servicios. En 2024, NIST abandonó formalmente los requisitos de complejidad en SP 800-63B-4. Aquí explicamos por qué y qué lo reemplaza.

Seis cosas que corregir antes de cerrar esta pestaña

Deje de exigir combinaciones de caracteres. NIST SP 800-63B-4 elimina las reglas de composición obligatorias; empujan a los usuarios hacia fórmulas predecibles como Password1! que las herramientas de cracking prueban primero.
Aumente el mínimo de longitud y haga que las contraseñas sean verdaderamente aleatorias. 8 caracteres es el mínimo con MFA habilitado, 15 es el mínimo sin él, y 12+ es el objetivo realista para la mayoría de las políticas empresariales. Genere contraseñas con una herramienta, ya que una contraseña larga creada por un humano sigue siendo predecible.
Elimine el calendario de rotación forzada. Cambie una contraseña solo cuando haya evidencia de compromiso, no con un temporizador de 60 o 90 días que solo genera ajustes del tipo Summer2026!.
Agregue verificación de brechas al momento de la creación. Esto bloquea exactamente las contraseñas que los atacantes ya están probando, algo que ninguna regla de composición logró jamás.
Agregue MFA y migre a passkeys donde sea posible. MFA impide que una contraseña filtrada sea suficiente por sí sola. Los passkeys van más allá y eliminan el secreto compartido por completo, por lo que no queda nada que un atacante pueda suplantar o robar mediante phishing.
Delegue la aplicación a un gestor de contraseñas. La Política de Grupo no puede verificar el estado de brechas ni registrar quién accedió a una credencial compartida. Un gestor de contraseñas está diseñado para cubrir exactamente esa capa.

Qué son las reglas de complejidad de contraseñas

Las reglas de complejidad de contraseñas son requisitos de política que obligan a que una contraseña combine tipos de caracteres, típicamente al menos una letra mayúscula, una letra minúscula, un dígito y un símbolo, bajo la suposición de que una mayor variedad de caracteres produce mayor entropía y mayor resistencia a los ataques de adivinación.

Estas reglas se convirtieron en estándar en la TI empresarial durante las décadas de 2000 y 2010, generalmente combinadas con una longitud mínima de 8 caracteres y rotación obligatoria cada 60 a 90 días. La política de contraseñas predeterminada de Active Directory todavía viene con los requisitos de composición habilitados, y la mayoría de las listas de verificación de cumplimiento de esa época asumían que la complejidad y la rotación eran la base para la seguridad de las cuentas.

La suposición detrás de la regla era sólida en teoría: un conjunto de caracteres más grande por posición significa más combinaciones posibles, lo que significa una búsqueda de fuerza bruta más larga. En la práctica, la regla interactúa con el comportamiento humano de una manera que socava su propio objetivo, tema de la siguiente sección.

Qué cambió NIST — y por qué importa

NIST SP 800-63B-4 elimina las reglas obligatorias de composición de caracteres y los restablecimientos periódicos de contraseñas, citando evidencia de que ambas prácticas degradan la seguridad en el mundo real en lugar de mejorarla. La actualización reemplaza la complejidad prescriptiva con requisitos basados en longitud y verificación de brechas.

La justificación se encuentra en el Apéndice A de la publicación: las reglas de composición empujan a los usuarios hacia contraseñas predecibles y formulaicas, mientras que la rotación forzada lleva a las personas a hacer cambios triviales (Summer2025! se convierte en Summer2026!) o reutilizar contraseñas antiguas con un dígito añadido. Ninguno de estos comportamientos aumenta la resistencia a la adivinación o el cracking.

«La investigación ha demostrado que los usuarios responden de maneras muy predecibles a los requisitos impuestos por las reglas de composición (políticas). Por ejemplo, un usuario que podría haber elegido "password" como su contraseña probablemente elegiría "Password1" si se le exige incluir una letra mayúscula y un número, o "Password1!" si también se requiere un símbolo.» — NIST SP 800-63B-4

Este es el cambio en la práctica:

Composición de caracteres:
- Antes — exigir mayúsculas, minúsculas, dígitos y caracteres especiales.
- Ahora — sin reglas de composición. Aceptar cualquier carácter imprimible, incluyendo espacios.
Rotación:
- Antes — caducar contraseñas cada 60-90 días.
- Ahora — sin rotación forzada. Cambiar solo ante evidencia de compromiso.
Longitud mínima:
- Antes — 8 caracteres a menudo se trataban como suficientes por sí solos.
- Ahora — 8 caracteres es el mínimo absoluto para contraseñas utilizadas con autenticación multifactor. Si una contraseña es su única seguridad, los sistemas deben exigir un mínimo de 15 caracteres. Se recomiendan 12+ caracteres como el piso práctico empresarial.
Pistas de contraseña:
- Antes — se permitían pistas basadas en conocimiento.
- Ahora — sin pistas, ya que filtran información que un atacante puede usar directamente.
Verificación de brechas:
- Antes — en gran parte ausente de la política.
- Ahora — verificar cada contraseña contra corpus de brechas conocidas al momento de la creación y en cada cambio.

Si su GPO de Active Directory todavía aplica la lista de verificación de la era 2010, ahora está trabajando en contra de las directrices que fue diseñado para satisfacer.

El fallo conductual de las reglas de complejidad

Las reglas de complejidad fallan porque fuerzan un comportamiento predecible. Bajo un requisito de composición, los usuarios convergen en el mismo puñado de patrones de sustitución: @ por a, 1 por i o l, una letra mayúscula al principio, un dígito o símbolo al final. Las herramientas de cracking prueban estos patrones primero, lo cual es exactamente lo contrario de lo que la política pretendía.

Es el resultado predeterminado de pedir a los humanos que generen entropía bajo demanda. Las personas bajo carga cognitiva recurren al camino de menor resistencia: una palabra memorable, una transformación predecible, un patrón que han usado antes. Password1! y Summer2026! son el resultado de la política de complejidad aplicada a humanos reales.

La entropía de contraseña mide cuán impredecible es una contraseña, en bits. Cada bit añadido duplica las conjeturas que un atacante necesita para un crackeo por fuerza bruta. Depende del tamaño del conjunto de caracteres y la longitud, siendo la longitud más importante — y asume una selección completamente aleatoria, algo que las contraseñas elegidas por humanos rara vez logran.

La consecuencia se multiplica. Una vez que un usuario establece una fórmula que satisface la política, aplica la misma fórmula en todas partes: la misma palabra base, las mismas sustituciones, ligeramente modificadas por sitio. Eso es reutilización de contraseñas con pasos adicionales, y es precisamente por qué el credential stuffing funciona a escala. El Informe de Investigaciones de Brechas de Datos 2025 de Verizon encontró que las credenciales robadas o reutilizadas siguen siendo el principal vector de acceso inicial en las brechas, involucradas en la gran mayoría de los incidentes de aplicaciones web.

La fatiga de contraseñas empeora el problema. Los empleados que manejan requisitos de políticas en docenas de sistemas no se vuelven más cuidadosos con cada nueva regla. Se cansan, y los usuarios cansados escriben contraseñas en notas adhesivas o las almacenan en una hoja de cálculo que nadie cifra.

La longitud y la aleatoriedad superan a la complejidad — las matemáticas

Una contraseña de 8 caracteres elegida verdaderamente al azar de un conjunto de 95 caracteres tiene aproximadamente 52 bits de entropía. Una contraseña «compleja» elegida por un humano rara vez se acerca. Estudios sobre contraseñas generadas por usuarios bajo reglas de composición sitúan la entropía real más cerca de 20-30 bits, porque las elecciones de caracteres no son aleatorias. Siguen los patrones de sustitución descritos anteriormente.

Tipo de contraseña	Entropía máxima	Entropía real	Por qué
8 caracteres compleja, elegida por humano	~52 bits	~20-30 bits	Sustituciones predecibles (@, 1, primera letra mayúscula)
8 caracteres compleja, verdaderamente aleatoria	~52 bits	~52 bits	Sin sesgo humano en la selección de caracteres
Frase de contraseña de 4 palabras (Diceware)	~52 bits	~44-52 bits	La aleatoriedad proviene de la elección de palabras, no de patrones inventados de memoria

La brecha entre las dos primeras filas es todo el problema con las reglas de complejidad: el techo teórico y el resultado del mundo real son dos números diferentes, y la política solo controla el techo.

Una frase de contraseña cierra esa brecha. Cuatro palabras elegidas al azar de una lista de 7.776 palabras (el tamaño estándar de la lista de palabras EFF/Diceware) producen aproximadamente 52 bits de entropía — igualando el máximo teórico de esa contraseña compleja de 8 caracteres, mientras son dramáticamente más fáciles de recordar. correct horse battery staple es el ejemplo canónico, y se mantiene porque la aleatoriedad proviene de la selección de palabras, no de la sustitución de caracteres que un humano tiene que inventar en el momento.

Cómic ilustrando la entropía de contraseñas: comparación entre contraseña compleja y frase de contraseña de cuatro palabras — *Fuente:* *xkcd.com*

La conclusión práctica: una contraseña de 12 caracteres completamente en minúsculas elegida aleatoriamente de 26 caracteres tiene más entropía real que una contraseña «compleja» de 8 caracteres que un humano realmente elige, porque los humanos son predecibles y las matemáticas no lo son.

La longitud escala la entropía exponencialmente con cada carácter adicional. Las reglas de composición añaden un pequeño espacio de búsqueda fácilmente adivinable sobre una cadena corta. Contra las tasas de hash de GPU modernas, esa diferencia determina si un ataque de fuerza bruta toma horas o siglos.

Cómo abandonar las reglas de complejidad

Abandonar las reglas de complejidad heredadas no requiere un proyecto de varios trimestres. La mayor parte del trabajo es política y configuración, no nueva infraestructura, y se alinea estrechamente con lo que NIST SP 800-63B-4 y la Hoja de trucos de autenticación de OWASP recomiendan: actualizar el documento de política de contraseñas, ajustar la configuración del proveedor de identidad y dar a los usuarios un período de gracia para actualizar las contraseñas existentes en el próximo inicio de sesión.

La lista de verificación de migración de reglas de complejidad en 5 pasos:

Actualice primero la política escrita. Reemplace los requisitos de composición de caracteres con una longitud mínima de 15 caracteres, generados aleatoriamente en lugar de compuestos a mano. Elimine las reglas obligatorias de dígitos, símbolos y mayúsculas, junto con los restablecimientos forzados periódicos; ambos añaden fricción sin una ganancia de seguridad correspondiente una vez que se aplica la longitud mínima.
Reconfigure el proveedor de identidad. La mayoría de los sistemas AD/LDAP y SSO permiten deshabilitar la aplicación de complejidad y establecer una longitud mínima de forma independiente. Pruebe el cambio en un grupo piloto antes de implementarlo en toda la organización.
Agregue verificación contra bases de datos de brechas. Verifique las nuevas contraseñas contra listas de contraseñas comprometidas conocidas al momento de la creación. Esto hace más para detener el credential stuffing que forzar un dígito y un símbolo, porque bloquea exactamente las contraseñas que los atacantes ya están probando, no solo patrones débiles.
Implemente MFA resistente al phishing. Una contraseña larga y no comprometida sigue siendo un único punto de fallo si es objeto de phishing. Priorice las llaves de seguridad FIDO2/WebAuthn o los passkeys para el acceso de producción. TOTP funciona como alternativa, pero las llaves de seguridad y los passkeys deberían ser el objetivo.
Otorgue un período de gracia, no un restablecimiento forzado. Obligue a todos a cambiar contraseñas el mismo día y obtendrá una avalancha de patrones estilo Winter2026!. En su lugar, permita que las contraseñas roten naturalmente en el próximo inicio de sesión o vencimiento.

Los equipos que hacen este cambio tienden a ver un beneficio secundario que nadie pone en el documento de política: el volumen de tickets de soporte técnico para restablecimientos de contraseña disminuye, porque no hay un ciclo de rotación forzada que genere tickets de «olvidé mi nueva contraseña» cada trimestre.

Para cuentas de servicio y secretos que no pueden depender de la memoria humana en absoluto, el cálculo es diferente: secretos generados de 32+ caracteres almacenados en un gestor de contraseñas en lugar de algo que alguien escriba de memoria.

Passwork genera y almacena contraseñas y secretos de alta entropía, y admite el inicio de sesión sin contraseña con biometría, passkeys y llaves de seguridad WebAuthn, para que su equipo nunca tenga que inventar una contraseña «compleja» de memoria. Explore Passwork con una prueba gratuita

Por qué MFA y los passkeys son el objetivo final real

Incluso una política de contraseñas bien diseñada es una medida de transición. La dirección hacia la que se dirige la seguridad es la autenticación sin contraseña basada en FIDO2 y WebAuthn, donde no hay secreto compartido que robar en primer lugar.

Los passkeys son resistentes al phishing por diseño: la clave privada nunca abandona el dispositivo, y la parte que confía almacena solo una clave pública que no tiene valor para un atacante sin el hardware correspondiente. Apple, Google y Microsoft admiten passkeys de forma nativa en sus plataformas, según la especificación W3C WebAuthn, y la adopción del consumidor ha avanzado más rápido de lo que la mayoría predijo.

La adopción empresarial sigue una línea de tiempo más lenta. Tres factores mantienen a la mayoría de las organizaciones a años de retirar las contraseñas por completo:

Aplicaciones heredadas que se autentican contra directorios on-premise o son anteriores al soporte de WebAuthn y no se pueden reescribir de la noche a la mañana
Configuraciones de identidad federada donde SSO, SAML e integraciones LDAP necesitan acomodar passkeys junto con los protocolos existentes, no reemplazarlos por completo
Logística de implementación a escala de la fuerza laboral: inscripción de dispositivos, recuperación de cuentas cuando se pierde una llave de hardware y capacidad del servicio de asistencia para apoyar la transición

En esa ventana, la política de contraseñas descrita anteriormente (longitud, verificación de brechas, MFA) aplicada a través de herramientas en lugar de un PDF es lo que mantiene segura a una organización mientras la transición se desarrolla.

Lo que un gestor de contraseñas aplica y la Política de Grupo no puede

Un Objeto de Política de Grupo define reglas de composición de contraseñas, pero no tiene forma de verificar si una contraseña ya se ha filtrado, y ningún mecanismo para rastrear quién accedió a una credencial compartida posteriormente. Un gestor de contraseñas cierra esa brecha: verifica las credenciales contra bases de datos de brechas, aplica la longitud en toda la organización y registra cada evento de acceso. Esa es la capa de aplicación que GPO estructuralmente carece.

Passwork, un gestor de contraseñas corporativo autoalojado, aplica esto a nivel de bóveda: aplica la longitud mínima en toda la organización sin reintroducir reglas de combinación de caracteres, y organiza las credenciales del equipo en bóvedas compartidas con control de acceso basado en roles que delimita los permisos por grupo en lugar de por cuenta individual.

El generador integrado de Passwork produce contraseñas criptográficamente aleatorias y de alta entropía, del tipo que una persona no puede inventar de forma fiable a mano, y las almacena directamente en la bóveda. El autocompletado luego maneja el inicio de sesión, por lo que nadie tiene que memorizar ni volver a escribir lo que el generador creó. Esto elimina el último punto donde un humano aún podría debilitar la contraseña: el momento en que alguien intenta hacer memorable una cadena larga y aleatoria y silenciosamente la hace predecible en su lugar.

A diferencia de las herramientas que solo manejan inicios de sesión humanos, Passwork combina la gestión de contraseñas y la gestión de secretos en una sola bóveda: claves API, tokens de acceso, credenciales de bases de datos y certificados TLS se encuentran junto a las contraseñas de usuario bajo los mismos controles de acceso y registro de auditoría.

Realizando el cambio

Las reglas de complejidad son un remanente de una era en la que los atacantes dependían de la adivinación por fuerza bruta en lugar de herramientas automatizadas. Una vez que los ataques de credential stuffing pueden probar miles de variantes de contraseñas por segundo, pedir a los usuarios que inventen entropía manualmente deja de tener sentido. La longitud y MFA hacen el trabajo que se suponía que debían hacer las reglas de composición, sin depender de la memoria de nadie.

La actualización de NIST es un reconocimiento formal de algo que los profesionales de seguridad han observado durante más de una década: los humanos son el eslabón más débil en cualquier política que les pida generar aleatoriedad bajo demanda.

Comience con la auditoría. Extraiga la configuración actual de contraseñas de su GPO, verifique si todavía exige composición y rotación, y compare con SP 800-63B-4.

Si su Política de Grupo todavía aplica reglas de composición de caracteres de 2010, la solución es más simple de lo que parece. Comience con la longitud, agregue verificación de brechas y deje que un gestor de contraseñas maneje la aplicación. Vea cómo Passwork maneja la gobernanza de contraseñas corporativas

Preguntas frecuentes

¿Se aplica NIST a mi organización si no soy una agencia federal de EE. UU.?

NIST SP 800-63 es el estándar global de facto para la política de contraseñas incluso fuera de los requisitos federales. La Hoja de trucos de autenticación de OWASP se basa directamente en él, y los organismos nacionales, incluidos el BSI de Alemania y la ANSSI de Francia, están alineando progresivamente sus propias recomendaciones con los mismos principios.

¿Cuál es la longitud mínima de contraseña que NIST recomienda ahora?

NIST SP 800-63B-4 establece 8 caracteres como el mínimo absoluto para contraseñas utilizadas junto con autenticación multifactor. Si una contraseña es el único control de seguridad (sin MFA), los sistemas deben exigir un mínimo de 15 caracteres. En la práctica, la mayoría de los equipos empresariales deberían tratar 12 o más caracteres como el piso de trabajo realista, ya que 8 caracteres por sí solos ofrecen poco margen contra el hardware de cracking actual incluso con MFA implementado.

¿Debería seguir aplicando cambios periódicos de contraseña?

No. NIST SP 800-63B-4 elimina explícitamente la rotación obligatoria. Cambie una contraseña solo cuando haya evidencia de compromiso, como una coincidencia en una base de datos de brechas o un inicio de sesión sospechoso, o cuando el usuario lo solicite.

¿Los passkeys reemplazan las contraseñas por completo?

Todavía no, y no pronto para la mayoría de los entornos. Los passkeys son la dirección a largo plazo, pero la adopción es gradual debido a los sistemas heredados y la complejidad de implementación. Los gestores de contraseñas cierran esa brecha al manejar la higiene de contraseñas, la verificación de brechas y el control de acceso hoy.

¿Cómo verifico si una contraseña ha sido comprometida sin exponerla?

Utilice la API de k-anonimato de Have I Been Pwned. La contraseña se hashea del lado del cliente con SHA-1, y solo los primeros cinco caracteres del hash se transmiten al servicio. La contraseña completa y el hash completo nunca viajan por la red.