Entropía de contraseñas: las matemáticas reales de por qué la longitud vence a la complejidad
El consejo sobre contraseñas lleva dos décadas estancado en alguna versión de «usa mayúsculas, minúsculas, un número y un símbolo». Las matemáticas dicen que eso es en su mayoría falso — o al menos muy mal priorizado. La fuerza de una contraseña generada aleatoriamente se rige por una sola fórmula, y esa fórmula recompensa la longitud mucho más agresivamente que la amplitud del conjunto de caracteres. Esto es también, no por casualidad, lo que NIST lleva diciendo desde SP 800-63B (2017, revisado en 2024).
Este artículo recorre las matemáticas reales, calcula valores de entropía concretos, ofrece estimaciones de fuerza bruta con hipótesis declaradas explícitamente, y luego lo traduce a reglas que puedes aplicar.
La fórmula de la entropía
Para una contraseña extraída uniformemente al azar de un conjunto de caracteres de tamaño P, con longitud L, el número de contraseñas posibles es P^L, y la entropía en bits es:
H = log2(P^L) = L × log2(P)Ese es todo el modelo. La entropía mide el tamaño del espacio de búsqueda que un atacante debe enumerar. Cada bit adicional duplica el trabajo.
Las dos palancas son P (tamaño del conjunto) y L (longitud), y no son iguales. Añadir un carácter multiplica el espacio de búsqueda por P; ampliar el conjunto lo multiplica por una razón. Estos son los conjuntos que importan y sus contribuciones de entropía por carácter:
| Conjunto de caracteres | Tamaño (P) | Bits por carácter, log2(P) |
|---|---|---|
Solo dígitos (0–9) | 10 | 3.32 |
Solo minúsculas (a–z) | 26 | 4.70 |
Minúsculas + mayúsculas (a–zA–Z) | 52 | 5.70 |
Alfanumérico (a–zA–Z0–9) | 62 | 5.95 |
| ASCII imprimible completo (94 caracteres incl. símbolos) | 94 | 6.55 |
Observa los rendimientos decrecientes al ampliar el conjunto: pasar de solo minúsculas (26) al conjunto imprimible completo (94) casi cuadruplica el conjunto pero solo eleva la entropía por carácter de 4.70 a 6.55 bits — una ganancia del 39 % por carácter. Pasar de 8 a 16 caracteres con cualquier tamaño de conjunto exactamente duplica la entropía. La longitud escala linealmente sin techo; el tamaño del conjunto está limitado a ~94 en un teclado estándar.
Valores reales de entropía, calculados
Aplicando H = L × log2(P):
Conjunto ASCII imprimible completo (94 caracteres):
| Longitud | Entropía (bits) | Espacio de búsqueda |
|---|---|---|
| 8 | 52.4 | ~6.1 × 10^15 |
| 10 | 65.5 | ~4.4 × 10^19 |
| 12 | 78.7 | ~4.8 × 10^23 |
| 14 | 91.8 | ~5.1 × 10^27 |
| 16 | 104.9 | ~3.7 × 10^31 |
| 20 | 131.1 | ~2.9 × 10^39 |
Solo minúsculas (26 caracteres):
| Longitud | Entropía (bits) |
|---|---|
| 8 | 37.6 |
| 12 | 56.4 |
| 16 | 75.2 |
| 20 | 94.0 |
Conjunto alfanumérico (62 caracteres):
| Longitud | Entropía (bits) |
|---|---|
| 8 | 47.6 |
| 12 | 71.5 |
| 16 | 95.3 |
| 20 | 119.1 |
Ahora la comparación que demuestra el punto. Mira estas tres contraseñas, todas salidas plausibles de políticas distintas:
xQ9#mK2!— 8 caracteres, conjunto completo de 94: 52.4 bitshkbwvztdpqrm— 12 caracteres, solo minúsculas: 56.4 bitshkbwvztdpqrmjfyc— 16 caracteres, solo minúsculas: 75.2 bits
La contraseña «simple» de 12 caracteres en minúsculas ya supera a la «compleja» de 8 caracteres, y la de 16 caracteres la supera por 23 bits — un factor de unos 8 millones en espacio de búsqueda — siendo dramáticamente más fácil de escribir y recordar. Cuatro caracteres adicionales valen más que todo el conjunto de símbolos.
En este sentido la longitud vence a la complejidad: no porque la complejidad sea inútil (un conjunto más amplio siempre ayuda a longitud fija), sino porque los humanos son pésimos produciendo complejidad al azar, y la entropía marginal por carácter añadido supera la entropía marginal por ampliación del conjunto para cualquier conjunto realista.
La gran advertencia: esto solo funciona con contraseñas aleatorias
La fórmula H = L × log2(P) asume una extracción aleatoria uniforme. Las contraseñas elegidas por humanos no son nada de eso. Summer2026! tiene 11 caracteres de un conjunto de ~90 — nominalmente ~71 bits — pero cualquier herramienta de cracking lo prueba dentro de sus primeros miles de intentos porque es una palabra del diccionario, un año y el símbolo más común, en la disposición más común.
La entropía de las contraseñas humanas está dominada por la predictibilidad, no por la fórmula. Análisis empíricos de corpus de contraseñas filtradas encuentran consistentemente que un pequeño diccionario de contraseñas comunes más reglas de manipulación (mayúscula en la primera letra, añadir dígitos, añadir !) cubre una fracción amplia de las contraseñas reales. Por eso:
- Las matemáticas de la entropía se aplican a contraseñas generadas, frases de paso a partir de listas de palabras y secretos creados por gestores — no a cualquier cosa que una persona invente sin ayuda.
- Para contraseñas elegidas por humanos, la defensa no es la estimación de entropía, sino el filtrado contra listas de contraseñas comunes y filtradas — que es exactamente lo que NIST exige.
Frases de paso y Diceware
El método Diceware concreta las matemáticas para secretos memorables: tira dados para elegir palabras de forma uniforme de una lista de 7.776 palabras (6^5). Cada palabra aporta log2(7776) ≈ 12.9 bits:
- 5 palabras: 64.6 bits
- 6 palabras: 77.5 bits
- 7 palabras: 90.4 bits
Una frase de paso de 6 palabras estilo correct horse battery staple (el famoso ejemplo del XKCD ilustra las mismas matemáticas) ofrece ~77 bits con mucha mejor memorabilidad que una cadena aleatoria de 12 caracteres a 78.7 bits. Mismo nivel de seguridad, usabilidad radicalmente distinta.
Estimaciones de tiempo de fuerza bruta — con las hipótesis declaradas
Cualquier número de «tiempo hasta crackear» no significa nada sin su modelo de ataque. Aquí va uno, declarado explícitamente:
Hipótesis: ataque offline contra un hash rápido y sin sal (p. ej., MD5/SHA-1 en crudo) a 10^10 (10 mil millones) de intentos por segundo — alcanzable con un equipo multi-GPU modesto. Búsqueda exhaustiva del espacio completo; el tiempo esperado para encontrar la contraseña es la mitad. Sin limitación de tasa, sin atajos por listas de filtraciones (válido porque asumimos contraseñas aleatorias).
| Clase de contraseña | Espacio de búsqueda | Tiempo exhaustivo @ 10^10/s |
|---|---|---|
| 8 caracteres, minúsculas (26) | 2.1 × 10^11 | ~21 segundos |
| 8 caracteres, conjunto completo (94) | 6.1 × 10^15 | ~7 días |
| 12 caracteres, minúsculas (26) | 9.5 × 10^16 | ~110 días |
| 12 caracteres, conjunto completo (94) | 4.8 × 10^23 | ~1.5 millones de años |
| 16 caracteres, minúsculas (26) | 4.4 × 10^22 | ~140.000 años |
| 16 caracteres, conjunto completo (94) | 3.7 × 10^31 | ~1.2 × 10^14 años |
Trátalos como órdenes de magnitud ilustrativos, no garantías. Se desplazan en ambas direcciones:
- Más lento en la práctica si el sitio usa una función de hash de contraseñas adecuada. bcrypt, scrypt o Argon2 con parámetros razonables pueden reducir el throughput de intentos en 4–7 órdenes de magnitud comparado con MD5 en crudo, convirtiendo «~7 días» en «más largo que el calendario de muerte térmica que a alguien le importe». Por eso la elección del algoritmo de hash importa más que casi cualquier cosa que hagan los usuarios.
- Más rápido si la contraseña no es aleatoria (ataque de diccionario), el atacante tiene hardware de estado, o mejoras tipo ley de Moore se acumulan durante los años que un hash robado permanece valioso.
- Ataques online (intentos contra un endpoint de login en vivo) son un modelo completamente distinto: límites de tasa y bloqueos limitan a los atacantes a quizá cientos de intentos, así que incluso secretos de ~20 bits sobreviven — por eso NIST exige limitación de tasa, y por eso las contraseñas por sitio de tu gestor importan más que la fortaleza de cualquier contraseña individual.
La conclusión práctica de la tabla: 8 caracteres no son suficientes para nada que se vaya a hashear rápido, sin matices; 12+ caracteres aleatorios son cómodos; 16 es overkill en el buen sentido. Y de nuevo, la cadena de 16 caracteres en minúsculas supera a la cadena de 12 caracteres con conjunto completo — la longitud gana.
Lo que NIST SP 800-63B dice realmente
Las Digital Identity Guidelines del NIST (SP 800-63B, originalmente 2017; Revision 4 publicada en 2024) codificaron gran parte de esto en la política federal de EE. UU. Las recomendaciones de carga para los verificadores de contraseñas («secreto memorizado»):
- Longitud mínima, no complejidad. Exige al menos 8 caracteres para contraseñas elegidas por el usuario (Revision 4 lo eleva a 15 para contraseñas usadas como único factor, 8 cuando hay un segundo factor presente). Permite al menos 64 caracteres. No impongas reglas de composición (no «debe contener mayúscula, dígito, símbolo») — empujan a los usuarios hacia patrones predecibles (
Password1!) que debilitan la seguridad real. - Sin cambios periódicos forzados. La revisión de 2017 ya eliminó el viejo dogma de «rotar cada 90 días»; Revision 4 lo reitera. Cambia contraseñas solo cuando haya evidencia de compromiso. La rotación forzada produce confiablemente
Summer2026!→Autumn2026!— un incremento que una regla de cracking cubre trivialmente. - Filtra contra listas de contraseñas filtradas y comunes. Los verificadores deben comparar las contraseñas candidatas contra diccionarios de contraseñas comprometidas conocidas, palabras de diccionario, cadenas repetitivas/secuenciales y palabras específicas del contexto (nombre del servicio, nombre de usuario). Esto reemplaza a las reglas de composición como verdadera defensa para secretos elegidos por humanos.
- Permite pegar y gestores de contraseñas. Los verificadores deben permitir entradas pegadas — lo que es un respaldo explícito a los gestores de contraseñas, ya que las cadenas aleatorias generadas de 20 caracteres son exactamente lo que las directrices quieren que tengan los usuarios.
- Sin pistas basadas en conocimiento ni preguntas de seguridad. Las pistas de contraseñas y KBA («nombre de soltera de la madre») están prohibidas porque filtran o revelan trivialmente el secreto.
- Hash con sal y resistente a memoria para almacenar. Los verificadores deben almacenar las contraseñas hasheadas con una función unidireccional adecuada — la guía apunta a esquemas como Argon2, bcrypt o PBKDF2 con factores de trabajo adecuados — con una sal por usuario de al menos 32 bits.
Observa cómo encaja con las matemáticas de la entropía: las reglas de composición no añaden entropía real para humanos, la longitud sí; la rotación destruye cualquier entropía que los usuarios tenían empujándolos a patrones; y el filtrado contra listas de filtraciones maneja el hecho de que la entropía humana es inmedible. El estándar es la matemática, institucionalizada.
Reglas que realmente puedes usar
- Deja que un generador haga tus contraseñas. La generación aleatoria es la única forma de que la fórmula de entropía se aplique a ti. Nuestro Generador de Contraseñas crea contraseñas criptográficamente aleatorias en tu navegador — nada se transmite a ningún sitio. Configúralo a 16+ caracteres y deja de pensar en ello.
- Por defecto, 16 caracteres para todo lo importante. Con 95+ bits incluso solo en minúsculas, estás más allá de cualquier presupuesto concebible de fuerza bruta contra un almacén correctamente hasheado.
- Para cosas que debes memorizar, usa una frase de paso de 6 palabras. ~77 bits, escribible, recordable. Genera candidatos con el modo de frase de paso/lista de palabras de la misma herramienta si está disponible, o usa Diceware.
- Única por sitio, siempre. La entropía protege un sitio; la reutilización convierte una filtración en todas las filtraciones. Para esto existe el gestor de contraseñas.
- Añade un segundo factor donde se ofrezca. Los requisitos de longitud de NIST se relajan explícitamente cuando hay MFA, porque un segundo factor multiplica el trabajo del atacante de forma mucho más barata que más entropía de contraseña.
- Ignora el teatro de la complejidad. Un sitio que exige «una mayúscula, un dígito, un símbolo» pero te limita a 12 caracteres tiene la política al revés. Cumple mecánicamente, pero no lo confundas con fortaleza.
Resumen
- La entropía de una contraseña aleatoria es
H = L × log2(P): cada carácter añade un número fijo de bits dependiendo solo del tamaño del conjunto. - Ampliar el conjunto (26 → 94 caracteres) gana ~1.85 bits por carácter; cada carácter añadido gana 4.7–6.6 bits. La longitud gana de forma decisiva.
- 8 caracteres aleatorios ≈ 52 bits ≈ días-hasta-crackear contra hashes offline rápidos; 12 caracteres aleatorios ≈ 78+ bits ≈ efectivamente incrackeable en ese modelo.
- La fórmula solo aplica a la generación aleatoria. Las contraseñas elegidas por humanos son derrotadas por diccionarios, por eso NIST exige filtrado contra listas de filtraciones y prohíbe reglas de composición y rotación forzada.
- Genera contraseñas aleatorias de 16 caracteres con el Generador de Contraseñas, guárdalas en un gestor y activa MFA. Ese stack es lo que las matemáticas recomiendan.