Generador de contraseñas criptográficamente seguro con Modo Entropía Humana opcional. Corre 100% en tu navegador con crypto.getRandomValues().
— Ajusta la longitud con el deslizador o la entrada numérica (4–128 caracteres).
Activa las clases de caracteres: minúsculas, mayúsculas, dígitos, símbolos. Opcionalmente activa 'Excluir ambiguos' o 'Sin repeticiones consecutivas'.
Pulsa Generar para una contraseña o Generar en lote para hasta 100 a la vez.
Pulsa Copiar para llevarla al portapapeles; se borrará automáticamente a los 60 segundos.
Para máxima paranoia, activa el Modo Entropía Humana y mueve el ratón, teclea o toca la pantalla para añadir aleatoriedad antes de generar.
Cada byte aleatorio proviene del PRNG criptográfico del navegador — nunca Math.random(). Verificable en el código open-source.
Recoge entropía adicional desde ratón, teclado y táctil, mezcla con crypto por XOR y hashea con SHA-256 antes de usar.
Entropía Shannon en bits junto a etiqueta Débil/Aceptable/Fuerte/Muy Fuerte alineada con la guía NIST SP 800-63B.
Produce hasta 100 contraseñas de una vez y descárgalas como .txt con una por línea — todo en cliente.
Las contraseñas copiadas se limpian del portapapeles automáticamente a los 60 segundos para reducir la exposición a otras apps.
Cada contraseña se genera en tu navegador. Nada se transmite, se guarda en servidor ni se registra. Cierra la pestaña y ya no existe.
Usa crypto.getRandomValues() y SubtleCrypto.digest() — primitivas nativas del navegador, open-source y ampliamente auditadas.
Una vez cargada la página no hace falta red. Puedes generar contraseñas en un equipo aislado después de cachear la herramienta.
El medidor de fortaleza usa role='meter', la barra de entropía role='progressbar' y los cambios de estado se anuncian con aria-live.
La guía moderna del NIST (SP 800-63B) deja claro lo que los criptógrafos dicen desde hace años: la fortaleza de una contraseña la dominan su longitud y el tamaño del conjunto de caracteres del que se sacó. Una contraseña de 8 caracteres en minúsculas tiene unos 37 bits de entropía — crackeable en segundos con una GPU moderna. Una de 16 caracteres con mayúsculas, minúsculas, dígitos y símbolos (pool de 94) ronda los 105 bits — fuera del alcance computacional de cualquier atacante sin recursos de estado.
La entropía, medida en bits, es el logaritmo en base 2 del número de contraseñas posibles con las mismas reglas. Con 60 bits de entropía hay 2⁶⁰ ≈ 10¹⁸ posibilidades. A un billón de intentos por segundo, unos 35 años de crackeo continuo. A 128 bits, incluso hardware futuro hipotético no llegará a tiempo durante la vida útil del secreto.
Todo navegador moderno expone dos fuentes aleatorias. Math.random() es un PRNG no criptográfico — rápido, válido para juegos, inadecuado para secretos. crypto.getRandomValues() se respalda en el CSPRNG del sistema operativo (/dev/urandom en Linux, CryptGenRandom en Windows, SecRandomCopyBytes en macOS) y es la única fuente aceptable para material de contraseña. Esta herramienta usa solo la ruta criptográfica.
Algunos modelos de amenaza — particularmente frente a adversarios estatales — se benefician de entropía con "tirantes y cinturón". El Modo Entropía Humana opcional recoge aleatoriedad adicional desde movimientos de ratón, pulsaciones y eventos táctiles, la mezcla con 256 bits de crypto.getRandomValues() por XOR y hashea con SHA-256 para producir una semilla uniforme. La contribución humana no puede debilitar la salida por debajo de lo que aporta crypto.getRandomValues() — XOR con una máscara realmente aleatoria preserva la uniformidad — pero ofrece a quienes lo desean el confort psicológico de participar físicamente.
Una implementación ingenua elegiría un carácter tomando un byte aleatorio módulo el tamaño del pool. Esto introduce sesgo de módulo: con pool de 94 y bytes 0–255, los primeros 26 caracteres aparecen ligeramente más que los últimos 68. Esta herramienta usa muestreo por rechazo — los bytes fuera del rango uniforme 256 − (256 mod 94) = 188 se descartan — para garantizar que todo carácter es equiprobable.
Cero vs O mayúscula, uno vs L minúscula vs I mayúscula: indistinguibles en muchas tipografías y fuente habitual de errores al transcribir. La opción 'Excluir ambiguos' quita 0OoIl1 del pool. Reduce la entropía muy poco (menos de un bit en un pool de 94), compensando de sobra cuando las contraseñas deben transcribirse a mano.
NIST ya no recomienda rotación periódica arbitraria — lleva a patrones más débiles. La rotación debe ser por evento: tras una brecha, compromiso o sospecha de exposición. Para el día a día, la recomendación más fuerte es almacenar cada contraseña en un gestor reputado (Bitwarden, 1Password, KeePassXC) para maximizar longitud sin carga de memoria. Genera 32 caracteres aleatorios por cuenta y memoriza solo la maestra del vault.
Al copiar al portapapeles, otras aplicaciones del mismo sistema pueden leer las contraseñas — especialmente en móvil, donde el acceso cruzado al portapapeles es permisivo. Esta herramienta autolimpia el portapapeles 60 segundos tras copiar. Pega la contraseña en su destino sin demora y evita dejarla en el portapapeles de forma indefinida.
No toda cuenta justifica la misma estrategia. Las cuentas de servicio y secretos de API — consumidas programáticamente y guardadas en gestores de secretos — se benefician de la longitud máxima razonable (64–128 caracteres, con todos los símbolos) porque ningún humano las teclea. Las contraseñas Wi-Fi que los invitados leen ocasionalmente de una tarjeta funcionan mejor con 20 caracteres excluyendo glifos ambiguos para transcripción limpia. Las contraseñas root y de administrador de infraestructura merecen 32+ caracteres del pool completo y se deben rotar inmediatamente tras la salida de cualquier miembro con acceso. Las frases de cifrado que protegen volúmenes de disco o vaults deberían apuntar a 128 bits de entropía pero pueden prescindir de símbolos a favor de secuencias diceware más largas por ergonomía de escritura — una frase de 7 palabras tomada de una lista de 7.776 palabras rinde ~90 bits sin símbolos.
Este generador resuelve la creación, pero la creación es solo la mitad del problema. Sin gestor, los usuarios caen en contraseñas memorables (débiles) o en la reutilización. Los gestores modernos — Bitwarden (open source, capa gratuita), 1Password (comercial), KeePassXC (solo local) o los integrados en Chrome, Firefox y Safari — gestionan generación, almacenamiento, autocompletar y sincronización entre dispositivos. Además avisan de brechas (comparando tus credenciales almacenadas contra Have I Been Pwned) y muestran informes de antigüedad para priorizar rotaciones. La contraseña maestra del vault se convierte en el único secreto que memorizas; debe generarse a 128+ bits o como frase diceware de 6–7 palabras, y acompañarse de 2FA sobre el propio vault.
Incluso una contraseña criptográficamente perfecta puede ser phisheada. Añadir un segundo factor — una OTP temporal (TOTP) desde una app autenticadora, una llave de seguridad hardware (YubiKey, SoloKey) o una passkey de plataforma — eleva el listón drásticamente. Apps TOTP como Aegis, 2FAS y Google Authenticator generan códigos de 6 dígitos que rotan cada 30 segundos; obligan al atacante a comprometer un segundo dispositivo, no solo a phishear una credencial. Las llaves hardware con FIDO2/WebAuthn son el estándar de oro: son físicamente necesarias para autenticar y no se pueden phishear porque verifican criptográficamente el origen del sitio. Siempre que se pueda, prefiere passkeys (la implementación FIDO2 orientada al consumidor) sobre contraseña+TOTP — las passkeys eliminan la contraseña por completo y no se pueden reejecutar.
Asume que cualquiera de tus contraseñas acabará apareciendo en una brecha. Secuencia estándar de respuesta: (1) identifica qué credencial específica ha filtrado en haveibeenpwned.com, (2) rota esa credencial de inmediato con una contraseña recién generada, (3) rota cualquier credencial que usara la misma contraseña u otra similar en otros sitios (por esto la reutilización es tóxica — una brecha se propaga), (4) revisa la actividad de la cuenta por accesos no autorizados, (5) activa 2FA si aún no lo está. Si la cuenta brechada controla a otras (correo, gestor de contraseñas, proveedor SSO), trátalo como incidente crítico: rota todas las credenciales dependientes por orden de valor. Un gestor hace esto tratable; hacerlo para cientos de cuentas sin gestor es impracticable.
Muchos sitios siguen imponiendo políticas anticuadas: rotación obligatoria cada 90 días, longitud máxima de 16 caracteres, prohibición de pegar contraseñas o veto a ciertos símbolos. Estas reglas no suelen proteger mejor al usuario; normalmente lo empujan hacia patrones previsibles como Primavera2026!, incrementos secuenciales o variantes reutilizadas. Un buen generador ayuda, pero una política deficiente puede reducir igualmente la seguridad efectiva.
Cuando un sitio obliga a cumplir reglas de composición estrictas, la estrategia práctica es maximizar la longitud dentro del límite permitido, mantener la aleatoriedad real en todas las clases habilitadas y guardar el resultado en un gestor para no depender de la memoria. Si el servicio soporta passkeys o WebAuthn, conviene preferir esa vía cuanto antes. Un buen diseño de autenticación reduce el número de concesiones que el usuario debe hacer para satisfacer validadores heredados.
Exclusivamente crypto.getRandomValues() de WebCrypto. Math.random() no se usa en ningún punto. El código open-source está en tools-core.
Para uso general, apunta a al menos 80 bits de entropía (16 caracteres con pool de 62). Para cuentas críticas, 128+ bits (20 caracteres con pool de 94).
No puede empeorarla. El pool humano se XORea con 256 bits de crypto aleatorio y se hashea con SHA-256, así que el resultado es al menos tan fuerte como crypto.getRandomValues() solo.
No. Las últimas 10 contraseñas viven solo en memoria y se borran al recargar o al pulsar 'Borrar historial'. Nada se escribe en localStorage.
Sí. Una vez cargada la página no se requiere red. El sitio es un bundle estático y el generador es JavaScript puramente cliente.
El sesgo de módulo distorsiona la frecuencia de caracteres al reducir un byte aleatorio módulo el tamaño del pool. Aquí usamos muestreo por rechazo para eliminarlo.
El portapapeles puede ser leído por otras apps en muchas plataformas. Autolimpiarlo a los 60 segundos reduce la ventana de exposición dándote tiempo de pegar la contraseña.
En esta versión no — el generador emite contraseñas de caracteres. Un generador de passphrases desde lista curada está en el roadmap.
Sin logs, sin eventos de analítica para la generación, sin llamadas a servidor. La herramienta es una página estática y toda la lógica corre en tu pestaña.
La guía de identidad digital del Instituto Nacional de Estándares y Tecnología de EEUU. Sus secciones fijan longitud, composición y entropía de contraseñas que sigue esta herramienta.
No necesariamente. Los símbolos amplían el conjunto de caracteres y aumentan la entropía por carácter, pero la mejor contraseña es la más fuerte que el sistema de destino acepta y que puedes almacenar con seguridad en un gestor. En muchos sistemas heredados, más longitud aporta más valor práctico que usar símbolos exóticos.
Para una clave Wi-Fi que personas vayan a teclear ocasionalmente, unos 20 caracteres aleatorios sin glifos ambiguos suele ser un buen equilibrio. Las cuentas admin o root deberían usar 24–32 o más caracteres del pool completo. Los secretos consumidos por máquinas, como credenciales de servicio o claves API, pueden ser mucho más largos porque ningún humano necesita escribirlos.
Sí. Los límites máximos de longitud, la rotación forzada, las restricciones absurdas sobre símbolos o la prohibición de pegar empujan al usuario hacia hábitos peores. Cuando te encuentres con esas reglas, genera la contraseña aleatoria más fuerte que el sitio permita y guárdala en un gestor en lugar de transformarla en algo memorable.
Entiende la entropía de contraseña, por qué la longitud gana a la complejidad y cómo crypto.getRandomValues produce contraseñas seguras alineadas con NIST SP 800-63B.
Leer más →Guía práctica para equipos IT: generación masiva de contraseñas, cuentas de servicio, políticas de rotación y flujos con gestores de secretos.
Leer más →Guía práctica de Base64 en desarrollo web: data URIs, tokens JWT, autenticación HTTP Basic, APIs del navegador, codificación de archivos y errores comunes.
Leer más →Aprende cómo funciona la codificación Base64, cuándo usar Base64 URL-safe o MIME, qué coste tiene, y por qué no es lo mismo que Base128.
Leer más →