Las contraseñas débiles siguen siendo la mayor fuente de compromiso de cuentas. Año tras año, los informes de brechas confirman el mismo patrón: el credential stuffing, el phishing y las contraseñas reutilizadas superan con creces a los exploits sofisticados. La buena noticia es que las contramedidas están bien entendidas, han evolucionado notablemente en la última década y el NIST las ha condensado en una guía breve que cualquiera puede seguir. Este artículo explica la matemática detrás de la fortaleza, resume la posición moderna del NIST y recorre las decisiones que nuestro generador toma por ti.
El Concepto Clave: Entropía
La fortaleza de una contraseña se mide en bits de entropía — el logaritmo en base 2 del número total de contraseñas posibles bajo las mismas reglas. Si eliges 12 caracteres al azar de un pool de 94 ASCII imprimibles, la entropía es 12 × log₂(94) ≈ 78,6 bits. Aproximadamente 4 × 10²³ contraseñas en ese espacio. Incluso un atacante con GPUs a un billón de intentos por segundo tarda milenios.
La entropía cae rápido al reducir el pool. Una contraseña de 12 caracteres solo en minúsculas tiene 12 × log₂(26) ≈ 56,4 bits — unas 10¹⁷ posibilidades. Entra en territorio de fuerza bruta para un adversario estatal. El upgrade más efectivo no es añadir reglas de complejidad a una contraseña corta, sino simplemente hacerla más larga.
Por Qué la Longitud Gana a la Complejidad
Una política común exige al menos una mayúscula, un dígito y un símbolo. En términos de entropía amplía el pool por carácter de 26 a unos 94 — mejora útil. Pero la misma ganancia es gratis simplemente añadiendo caracteres: una contraseña de 16 minúsculas tiene 16 × log₂(26) ≈ 75 bits, casi tan fuerte como una de 12 con pool de 94. Cuatro minúsculas más son mucho más fáciles de memorizar que cumplir reglas de complejidad, y las contraseñas resultantes tienden a ser más fuertes en la práctica.
NIST SP 800-63B formaliza esto. La guía actual recomienda longitud mínima (8 caracteres elegidos por el usuario, 6 generados aleatoriamente), prohíbe las reglas de composición y elimina la rotación periódica forzada. Las reglas de complejidad sin longitud empujan a los usuarios a patrones predecibles (Password1!, Verano2024$) que los atacantes modelan explícitamente.
Aleatoriedad: Por Qué Importa crypto.getRandomValues
Los bytes crudos bajo cualquier contraseña generada salen de un generador pseudoaleatorio (PRNG). No todos son adecuados para seguridad. Math.random() en navegador y Node es un PRNG rápido no criptográfico pensado para juegos y simulaciones; su estado interno se puede recuperar tras unos pocos outputs. Usarlo para contraseñas sería catastrófico.
El navegador expone una fuente criptográficamente segura mediante crypto.getRandomValues(), respaldada por el CSPRNG del sistema operativo — /dev/urandom en Linux/BSD, BCryptGenRandom (o proveedores equivalentes de CNG) en Windows moderno, SecRandomCopyBytes en macOS. Estas fuentes se reseedean continuamente con eventos hardware e interrupciones; su salida es indistinguible de la aleatoriedad verdadera para cualquier adversario computacional. Nuestro generador usa crypto.getRandomValues() en exclusiva — Math.random() no se importa ni referencia en ningún punto del código.
Modo Entropía Humana: Tirantes y Cinturón
Para usuarios que quieren garantías adicionales — o que operan bajo modelos de amenaza que desconfían del CSPRNG del SO — nuestra herramienta ofrece un Modo Entropía Humana opcional. Al activarlo, movimientos de ratón, pulsaciones y eventos táctiles aportan un número conservador de bits a un pool. Cuando el pool alcanza 128 bits (marcado por la barra de progreso), la herramienta lo mezcla por XOR con 256 bits de crypto.getRandomValues() y hashea el resultado con SHA-256 para producir una semilla uniforme. Bytes posteriores se producen por hashing continuado.
Críticamente, la contribución humana no puede debilitar la salida. XOR con una máscara uniforme de 256 bits preserva la uniformidad sin importar la calidad del pool; la ronda SHA-256 destruye cualquier estructura residual. Para modelos de amenaza que no lo requieran, el modo estándar es criptográficamente suficiente en cualquier navegador moderno.
Evitar el Sesgo de Módulo
Un error sutil de implementación puede socavar incluso el mejor PRNG. Si eliges un carácter tomando un byte aleatorio y calculando byte % tamaño_pool, el resultado es uniforme solo cuando 256 es divisible por tamaño_pool. Con un pool de 94, 256 mod 94 = 68, lo que significa que los primeros 68 caracteres son ligeramente más probables que los 26 restantes. A lo largo de millones de contraseñas, el sesgo se detecta estadísticamente y hace los ataques por diccionario algo más efectivos.
La solución es el muestreo por rechazo: calcula el rango uniforme L = 256 − (256 mod 94) = 188 y descarta cualquier byte igual o superior a L. El promedio de bytes por carácter sube un poco (unos 256/188 ≈ 1,36×), pero cada carácter pasa a ser exactamente equiprobable. Nuestro generador aplica muestreo por rechazo en cada selección.
Caracteres Ambiguos y Usabilidad
La ambigüedad visual entre 0 y O, 1 y l y I, causa errores al transcribir contraseñas desde pantalla a otro dispositivo — habitual en configuración de routers, onboarding IoT y hojas impresas de respaldo. Nuestra opción 'Excluir ambiguos' elimina 0OoIl1 del pool. El coste en entropía es mínimo — menos de medio bit por carácter en un pool de 94 — pero la ganancia de usabilidad es considerable cuando hay transcripción manual.
La Longitud Correcta para Tu Modelo de Amenaza
Cuentas distintas requieren fortalezas distintas. Un foro olvidable puede bastar con 12 caracteres (≈ 79 bits contra pool de 94), protegido además por el rate-limiting del sitio. Una cuenta bancaria o de correo (que suele controlar los resets de todo lo demás) merece 20+ caracteres (≈ 131 bits). La contraseña maestra de tu gestor — el único secreto que realmente memorizas — debe apuntar a 128 bits y provenir de al menos cuatro palabras aleatorias o 20+ caracteres; es la raíz de confianza de tu identidad digital.
Almacenamiento: el Gestor de Contraseñas No Es Negociable
Nadie puede memorizar una contraseña aleatoria única de 20 caracteres para cada cuenta. La respuesta universalmente respaldada en la literatura de seguridad es un gestor de contraseñas: Bitwarden, 1Password, KeePassXC o los integrados en Chrome, Safari y Firefox. Genera una contraseña fuerte y única por cuenta, almacénala y deja que autocompletar se encargue del resto. Elimina la reutilización (vector principal del credential stuffing), reduce la susceptibilidad al phishing (el gestor solo rellena en el dominio exacto) y permite maximizar longitud sin carga de memoria.
Higiene del Portapapeles
Las contraseñas copiadas son vulnerables a cualquier proceso con acceso de lectura al portapapeles. En Android e iOS es permisivo; en escritorio menos pero también vale defender. Nuestra herramienta autolimpia el portapapeles a los 60 segundos tras copiar. En la práctica, pega la contraseña en su destino de inmediato. Si usas gestor de contraseñas, prefiere autocompletar a copiar-pegar cuando esté disponible — inyecta la contraseña en el formulario sin pasar por el portapapeles.
Rotación: la Visión Moderna
El consejo antiguo de rotar contraseñas cada 90 días está oficialmente deprecated. NIST SP 800-63B sección 5.1.1.2 dice: "Los verificadores NO deberían requerir que los secretos memorizados se cambien arbitrariamente (por ejemplo, periódicamente)." La rotación forzada lleva a patrones más débiles (Verano2024$ → Verano2025$) que los atacantes modelan explícitamente. La rotación debe ser por evento: tras una brecha conocida, sospecha de compromiso o al salir de un escenario de acceso compartido.
Monitorización de Brechas
Incluso una contraseña perfecta pierde valor si el sitio que la almacena sufre una brecha y su hash se crackea. Monitoriza haveibeenpwned.com y activa las notificaciones de brecha en tu gestor de contraseñas. Si la brecha te afecta, rota la credencial específica — no el vault completo.
Usar Nuestro Generador
Abre el Generador de Contraseñas, ajusta la longitud, activa las clases de caracteres y pulsa Generar. El medidor de fortaleza muestra la entropía en bits y una etiqueta alineada con NIST. Para cuentas críticas, usa el modo en lote para producir 10–20 candidatas a la vez, elige la que prefieras y guárdala en tu gestor. Toda la generación ocurre en tu navegador; nada se envía por red, nada se registra y el historial de sesión se borra al recargar.
Anti-Patrones Comunes que Persisten
Pese a una década de guías, usuarios y políticas de TI siguen cayendo en trampas predecibles. La sustitución por patrón (P@ssw0rd, Ver4no2024!) produce contraseñas que parecen complejas a un validador de cumplimiento pero que están modeladas explícitamente por diccionarios de cracking — añaden aproximadamente cero entropía real. Los patrones de recorrido de teclado (qwerty123, asdfghjkl) aparecen en todos los corpus de brecha y se prueban primero en cualquier ataque de diccionario. El formato nombre + año (JuanPerez1987) es trivialmente enumerable cuando se conocen datos sociales básicos. Reutilizar el nombre del servicio (NetflixPassword1) cumple técnicamente con una política de "distinta por sitio" sin aportar nada de su beneficio real: un atacante de credential-stuffing probará inmediatamente el patrón en otros sitios. La única defensa fiable contra estos es la generación aleatoria — ninguna contraseña elegida por un humano cumple consistentemente los requisitos modernos de entropía.
Política Corporativa de Contraseñas: lo que Realmente Funciona
Si defines política de TI para un equipo, el cambio de mayor impacto es abandonar las reglas de composición (exigir símbolos, dígitos, mayúsculas y minúsculas) a favor de mínimos de longitud y bloqueo contra corpus de brechas. NIST SP 800-63B recomienda explícitamente: exigir longitud mínima (12+ caracteres elegidos por el usuario), bloquear contraseñas comprometidas mediante una blocklist en vivo (la API de Have I Been Pwned lo ofrece gratis), eliminar la rotación forzada periódica y nunca imponer reglas de composición. Combina esto con 2FA obligatorio en todas las cuentas y gestión centralizada (Bitwarden Business, 1Password Teams) para que los empleados nunca necesiten memorizar contraseñas. Estos cuatro cambios eliminan típicamente el 80–90% de incidentes relacionados con credenciales en equipos medianos, con un coste de unas horas de trabajo de política y una licencia de gestor por usuario.
El Papel de los Servicios de Monitorización de Brechas
Have I Been Pwned (haveibeenpwned.com) mantiene una base de datos de más de 12.000 millones de credenciales comprometidas en miles de brechas. Dos usos prácticos: (1) comprobar cualquier email o hash de contraseña antes de confiarla para una cuenta nueva, y (2) suscribirse a notificaciones a nivel de dominio para enterarte de inmediato cuando credenciales de tu dominio aparezcan en una brecha nueva. Alternativas corporativas como Spycloud, Have I Been Pwned for Enterprise y las funciones de alerta integradas en los gestores extienden esto con monitorización darkweb y detección en tiempo real. Para usuarios individuales, el servicio gratuito HIBP es suficiente. Para equipos de TI que protegen una plantilla, el nivel de pago se integra con proveedores de identidad (Okta, Azure AD, Google Workspace) para forzar resets automáticos al detectar exposición.