Generador de contraseñas en lote gratuito

Generación en lote de contraseñas

Esta herramienta genera varias contraseñas criptográficamente robustas en una sola operación. Perfecto para preparar listas para la incorporación de un equipo, la creación masiva de cuentas o la gestión de inventarios de contraseñas. Cada contraseña se produce mediante el generador aleatorio integrado del navegador.

Niveles de robustez

• Débil · 8-11 caracteres: protección básica, a evitar para cuentas sensibles
• Correcta · 12-15 caracteres: protección moderada, aceptable para muchos usos
• Buena · 16-19 caracteres: protección fuerte, recomendado para la mayoría de las cuentas
• Muy fuerte · 20 caracteres o más: protección máxima, ideal para sistemas críticos

Preguntas frecuentes

¿Estas contraseñas son realmente aleatorias?

Sí. Las contraseñas se generan con window.crypto.getRandomValues(), que proporciona valores aleatorios criptográficamente seguros, adecuados para usos de seguridad.

¿Puedo generar más de 100 contraseñas?

La herramienta limita la generación a 100 a la vez para evitar ralentizar el navegador. Genera varios lotes por separado si es necesario.

¿Cómo guardar el archivo descargado?

Conserva el archivo .txt en una ubicación segura, preferiblemente cifrada. Nunca lo confirmes a un repositorio de código ni lo compartas por canales no seguros. Elimínalo tras la distribución a los usuarios.

De dónde vienen los buenos números aleatorios

Un ordenador es, por diseño, determinista. Dadas las mismas entradas y el mismo código, produce las mismas salidas todas las veces. Esa es exactamente la propiedad que quieres de una CPU que ejecuta una hoja de cálculo, y exactamente la propiedad que no quieres de un generador de contraseñas. Si un atacante puede reproducir la secuencia de valores que emitió el generador, puede reproducir todas las contraseñas que haya generado.

Así que el generador recoge «entropía» (señal física impredecible procedente del exterior del programa) y la usa para sembrar un algoritmo llamado CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). El «pseudo» es honesto: los bits los produce un algoritmo, no la física. El «criptográficamente seguro» significa que ni siquiera un atacante que vea una larga serie de salidas pasadas puede predecir el siguiente byte mejor que el azar. Theodore Ts'o implementó /dev/random en el núcleo de Linux en 1994, y macOS, los BSD, Solaris y Windows (con BCryptGenRandom) adoptaron todos interfaces equivalentes. Por dentro, estos mezclan todas las fuentes plausibles de fluctuación física (tiempos de búsqueda en disco, llegadas de paquetes de red, entradas de teclado y ratón, interrupciones de hardware, RDRAND en las CPU de Intel que lo tienen) a través de un hash criptográfico y luego se resiembran de forma continua.

En el navegador, la API de Criptografía Web del W3C lo expone mediante window.crypto.getRandomValues(typedArray): le pasas una matriz tipada y el navegador la rellena con bytes aleatorios criptográficamente fuertes. El máximo por llamada es de 65.536 bytes (esta herramienta se queda muy por debajo). La API cuenta con compatibilidad básica en Chrome, Firefox, Safari y Edge desde julio de 2015: no hay posibilidad realista de que un usuario llegue a esta herramienta con un navegador que carezca de ella.

La entropía de las contraseñas: las matemáticas reales

La «fortaleza» de una contraseña, en el sentido criptográfico formal, se mide en bits de entropía. La fórmula estándar para una contraseña generada aleatoriamente es:

Entropía = L × log₂(R)

donde L es la longitud en caracteres y R es el tamaño del conjunto de caracteres. Entropía por carácter según el conjunto:

• Solo dígitos (0-9): 10 caracteres → 3,32 bits/carácter
• Solo minúsculas (a-z): 26 → 4,70 bits/carácter
• Minúsculas + mayúsculas (A-Za-z): 52 → 5,70 bits/carácter
• Minúsculas + mayúsculas + dígitos (alfanumérico): 62 → 5,95 bits/carácter
• Todo el ASCII imprimible excepto el espacio: 94 → 6,55 bits/carácter

Conviene fijar el número 94: los códigos ASCII del 32 al 126 son los caracteres imprimibles (95 en total); al excluir el espacio quedan 94 glifos visibles que no son espacios (26 minúsculas + 26 mayúsculas + 10 dígitos + 32 signos de puntuación o símbolos). Si introducimos números concretos en la fórmula:

• 8 caracteres × 6,55 ≈ 52,4 bits: rápida de descifrar por fuerza bruta en hardware moderno
• 12 caracteres × 6,55 ≈ 78,6 bits: en el límite, justo por debajo del umbral de 80 bits
• 16 caracteres × 6,55 ≈ 104,8 bits: por encima de 100, en territorio aceptable para la ANSSI
• 20 caracteres × 6,55 ≈ 131,0 bits: superado el umbral equivalente a AES-128
• 32 caracteres × 6,55 ≈ 209,6 bits: excesivo para cualquier adversario concebible

La comunidad criptográfica ha fijado tres umbrales: 80 bits como mínimo imprescindible (el suelo recomendado por el NIST hasta 2014), alcanzado con ~13 caracteres con el conjunto completo de 94 caracteres; 100 bits que exige la ANSSI (el equivalente francés de la NSA) para las contraseñas que protegen sistemas de cifrado, alcanzado con ~16 caracteres; y 128 bits que igualan la fortaleza de clave simétrica de AES-128, recomendado para las contraseñas maestras de las cajas fuertes, alcanzado con ~20 caracteres.

La gran salvedad: estas matemáticas solo se aplican a las contraseñas aleatorias. Si una persona eligió la contraseña, la entropía efectiva es muchísimo menor. El atacante no enumera alfabéticamente las R^L cadenas, sino que ejecuta un programa de adivinación alimentado con listas de contraseñas filtradas, palabras de diccionario, sustituciones habituales (a→@, o→0, s→$), recorridos de teclado y modelos estadísticos de cómo construyen las personas cadenas memorables. El estudio de 2012 de Joseph Bonneau sobre un corpus anonimizado de 70 millones de contraseñas de Yahoo (IEEE Symposium on Security and Privacy) descubrió que las contraseñas elegidas por los usuarios dan «menos de 10 bits de seguridad frente a un ataque de rastreo en línea y solo unos 20 bits frente a un ataque de diccionario sin conexión óptimo». Veinte bits son un millón de intentos. Una GPU moderna lo hace en microsegundos.

NIST SP 800-63B: qué cambió en 2017 y de nuevo en 2025

Durante unos treinta años, la política de seguridad de contraseñas en Norteamérica descendió de una publicación del NIST de 1985 que recomendaba la rotación periódica forzosa, la mezcla de clases de caracteres y longitudes mínimas cortas. Bill Burr, autor de la continuación de 2003 que codificó la regla de «mayúscula + minúscula + dígito + símbolo, cambiar cada 90 días», se retractó públicamente de ella en 2017 y declaró al Wall Street Journal que «buena parte de lo que hice, ahora lo lamento». El NIST formalizó el giro ese mismo año.

La NIST SP 800-63B Rev 3 (junio de 2017) introdujo dos cambios generacionales. La Sección 5.1.1.2 dice: «Los verificadores NO DEBERÍAN exigir que los secretos memorizados se cambien de forma arbitraria (p. ej., periódicamente)», porque las rotaciones forzosas hacen que los usuarios elijan contraseñas más débiles y predecibles. La misma sección: «Los verificadores NO DEBERÍAN imponer otras reglas de composición (p. ej., exigir mezclas de distintos tipos de caracteres) para los secretos memorizados», porque obligar a poner un dígito y un símbolo empuja a los usuarios hacia Password1! en lugar de una frase de contraseña más larga. La Rev 3 fijó la longitud mínima elegida por el suscriptor en 8 caracteres, exigió a los verificadores aceptar hasta 64, obligó a comprobar las contraseñas nuevas frente a listas de bloqueo de filtraciones y exigió de forma explícita que se permitieran los gestores de contraseñas y el pegado desde el portapapeles.

La NIST SP 800-63B Rev 4 (finalizada el 31 de julio de 2025) elevó el listón: las contraseñas de un solo factor exigen ahora un mínimo de 15 caracteres («Los verificadores y los CSP DEBERÁN exigir que las contraseñas utilizadas como mecanismo de autenticación de factor único tengan una longitud mínima de 15 caracteres»). Las contraseñas multifactor se mantienen en 8 caracteres porque el segundo factor soporta el peso de la seguridad. Las reglas de composición siguen prohibidas, y la redacción pasó del «SHOULD NOT» de la Rev 3 al «SHALL NOT» de la Rev 4, lo que lo convierte en un requisito obligatorio en lugar de una recomendación. La rotación sigue desaconsejándose salvo que haya pruebas de un compromiso.

La herramienta de Absolutool usa de forma predeterminada 16 caracteres con las cuatro clases de caracteres, lo que da unos 104 bits de entropía y supera con holgura tanto el mínimo de 15 caracteres de la Rev 4 como el umbral de equivalencia simétrica de 80 bits. El máximo de la herramienta, 128 caracteres, es exactamente el doble de la longitud máxima que el NIST obliga a aceptar a los verificadores: no hay ningún caso realista en el que una contraseña generada fuera demasiado larga para que un servidor la aceptara.

RockYou: el desastre que todavía persigue en 2026

En diciembre de 2009, la empresa de juegos sociales RockYou sufrió una brecha mediante una inyección SQL de manual. La brecha expuso más de 32 millones de cuentas de usuario, incluidas las contraseñas de esas cuentas en texto plano: RockYou las había almacenado sin cifrar. La política de contraseñas de la empresa en aquel momento solo exigía cinco caracteres y no permitía caracteres especiales, lo que había agravado la vulnerabilidad.

El archivo filtrado, pronto apodado rockyou.txt, se publicó abiertamente y sigue siendo la lista de palabras de contraseñas más citada del mundo. Se incluye de forma predeterminada con Kali Linux para los analistas de penetración; todas las herramientas de ataque de diccionario del planeta lo consultan; los servicios comerciales de relleno de credenciales lo mantienen como referencia. Dieciséis años después, los atacantes siguen cazando cuentas activas que usan contraseñas que aparecieron por primera vez en la filtración de 2009. Las lecciones que se propagaron: los servidores nunca deberían ver las contraseñas en texto plano (esta herramienta genera del lado del cliente, así que el servidor no las ve en absoluto); las contraseñas almacenadas deberían cifrarse con una función lenta, con sal y de uso intensivo de memoria, como Argon2id o bcrypt, no con un hash rápido como MD5 o SHA-1 sin sal; las contraseñas únicas por sitio son la única defensa frente al ataque de repetición de credenciales robadas que ha dominado la última década de brechas.

Have I Been Pwned y el corpus de filtraciones

Have I Been Pwned (HIBP), gestionado por el director regional de Microsoft Troy Hunt, se ha convertido en la fuente autorizada estándar para «¿ha aparecido esta contraseña en una filtración?». Hunt lanzó HIBP en 2013 como un índice consultable de direcciones de correo electrónico filtradas; más tarde añadió el corpus Pwned Passwords, una lista descargable de todas las contraseñas vistas en una filtración pública, indexada por hash SHA-1. Pwned Passwords V2 se lanzó el 22 de febrero de 2018 e introdujo la API de k-anonimato del conjunto de datos (construida con Cloudflare): un cliente envía solo los cinco primeros caracteres del hash SHA-1; el servidor devuelve todos los hashes completos que empiezan por esos cinco caracteres junto con el número de veces observado; el cliente compara localmente. La contraseña (e incluso su hash completo) nunca sale del dispositivo del usuario.

Para un generador masivo, la relevancia es doble. Cualquier contraseña que ya esté en HIBP no es, por definición, una contraseña nueva útil: será lo primero que pruebe cualquier atacante de relleno de credenciales. Y como esta herramienta genera con aleatoriedad CSPRNG completa a partir de un alfabeto de 94 caracteres, la probabilidad de que una contraseña de 16 caracteres recién generada ya esté en HIBP es, a efectos prácticos, cero. (El número total de contraseñas de 16 caracteres con símbolos ASCII es 94^16 ≈ 3,7 × 10³¹; HIBP contiene aproximadamente 10⁹ contraseñas conocidas; la probabilidad de colisión es ≈ 10⁻²².)

Qué significan «X bits de entropía» en tiempo real de descifrado

El número que da sentido concreto a los bits de entropía es «¿cuánto tardaría un atacante moderno?», y la respuesta depende por completo del algoritmo de hash. El banco de pruebas publicado por la comunidad para hashcat v6.2.6 en una sola Nvidia RTX 4090 registra aproximadamente 300 GH/s para los hashes NTLM (el viejo hash de Windows de Microsoft) y 200 kH/s para bcrypt. La diferencia de cuatro órdenes de magnitud entre ambos es el dato decisivo: NTLM se diseñó para la velocidad, bcrypt se diseñó para ser lento.

Las muy citadas tablas de contraseñas de Hive Systems convierten los bancos de pruebas en cifras de tiempo de descifrado. La versión de 2025 calculada frente a hashes MD5 (casi tan rápidos como NTLM) da ~59 minutos en una RTX 4090 para descifrar por fuerza bruta una contraseña de 8 caracteres del conjunto completo. La misma contraseña de 8 caracteres frente a un hash bcrypt tarda ~99 años en el mismo hardware. Esa diferencia de cuatro órdenes de magnitud es la diferencia entre «filtrada ayer, descifrada a la hora de comer» y «filtrada ayer, te sobrevivirá».

El usuario final controla la longitud y el conjunto de caracteres de la contraseña. No controla el algoritmo de hash que el servidor usa para almacenarla. La mayoría de los servicios modernos bien gestionados usan bcrypt, scrypt o Argon2id, todos deliberadamente lentos. Los servicios más antiguos y los servicios vulnerados usaban con frecuencia MD5 o SHA-1 sin sal, y por eso los corpus de filtraciones antiguas pueden descifrarse a las velocidades citadas arriba. Para una contraseña generada por esta herramienta: una contraseña aleatoria de 16 caracteres es segura frente a bcrypt esencialmente para siempre y más o menos segura frente a MD5 por ahora; una contraseña de 20 caracteres es excesiva frente a cualquiera de los dos. No existe ningún modelo de amenaza realista en el que 20 caracteres o más de salida de un CSPRNG sean el eslabón débil.

FIDO2, WebAuthn y la transición a las claves de acceso

La predicción más antigua del sector de la seguridad es que las contraseñas van a desaparecer. Desde 2019 por fin tiene un sustituto creíble: las claves de acceso, el nombre comercial para los consumidores de las credenciales emitidas según los estándares FIDO2 / WebAuthn. WebAuthn Level 1 se convirtió en recomendación del W3C el 4 de marzo de 2019; el Level 2 le siguió el 8 de abril de 2021. El modelo criptográfico es asimétrico: cuando un usuario se registra, el autenticador genera un par de claves pública/privada, envía la clave pública al servidor y almacena la clave privada en hardware local seguro. La autenticación usa un desafío-respuesta firmado con la clave privada. El servidor nunca ve el secreto, lo que significa que una brecha del lado del servidor no puede exponer las credenciales de inicio de sesión.

Los despliegues de las principales plataformas avanzaron al unísono a lo largo de 2022-2023: Apple mostró las claves de acceso en la WWDC el 6 de junio de 2022 y las lanzó públicamente con iOS 16, iPadOS 16 y macOS Ventura en septiembre de 2022, con sincronización mediante el Llavero de iCloud cifrado de extremo a extremo. Google anunció la compatibilidad con claves de acceso para Android y Chrome el 12 de octubre de 2022; la compatibilidad estable de Chrome llegó con Chrome 108 en diciembre de 2022, con sincronización mediante el Administrador de contraseñas de Google. Microsoft anunció la gestión de claves de acceso para Windows 11 el 21 de septiembre de 2023, integrada con Windows Hello.

Las claves de acceso resuelven las clases más dolorosas de fallo de contraseña (phishing, relleno de credenciales, brecha del servidor), pero no han eliminado las contraseñas porque: muchos sitios y la mayoría de los sistemas heredados todavía exigen una; las claves de acceso están ligadas a un dispositivo o a un ecosistema de sincronización (los usuarios sin una cuenta de Apple, Google o Microsoft necesitan una alternativa); los sistemas sin interfaz (dispositivos IoT, cuentas de servicio del lado del servidor, escenarios de alta por lotes) no pueden depender de un autenticador biométrico en el paso de registro; y muchas políticas de contraseñas empresariales, sistemas bancarios y portales gubernamentales siguen exigiendo contraseñas. La generación masiva de contraseñas encaja de lleno en las categorías segunda y tercera: un administrador de sistemas que aprovisiona 50 cuentas nuevas no puede pedir a cada futuro usuario que registre una clave de acceso antes de que exista la cuenta.

Por qué importa específicamente la generación del lado del cliente

Imagina una herramienta de la competencia que envía mediante POST la solicitud del usuario a un servidor, el servidor ejecuta el generador aleatorio y devuelve la lista como JSON. Aunque todo funcione como se anuncia, las siguientes partes pueden ver las contraseñas generadas en texto claro: la memoria de proceso del servidor mientras se gestiona la solicitud; los registros de solicitudes del servidor (si el registro es ingenuo); cualquier servicio de APM o de seguimiento de errores al que esté conectado el servidor; el proxy inverso que termina el TLS (Cloudflare, el balanceador de carga de AWS, nginx); cualquier herramienta de depuración que se ejecute en el servidor; cualquier atacante futuro que obtenga acceso a alguno de esos registros. Se aplica el modelo de RockYou, con todas sus consecuencias.

Cuando la generación ocurre mediante window.crypto.getRandomValues() en el navegador del usuario, nada de eso se aplica. Los bytes se producen dentro del proceso del navegador, en la máquina del usuario, mediante código que el usuario puede auditar (el código fuente de la página es visible). Nunca cruzan la red. El servidor de Absolutool nunca los ve, nunca los registra y no puede filtrarlos en una brecha futura porque nunca los tuvo. Las únicas entidades que ven las contraseñas generadas son el usuario, cualquiera con acceso a la sesión del navegador del usuario (normalmente solo el usuario) y cualquier extensión del navegador que se ejecute en la página. Este es el mismo modelo de seguridad que el generador local de un gestor de contraseñas, y más fuerte que el modelo de cualquier servicio web que devuelve contraseñas generadas desde un servidor.

Mirai 2016: el ejemplo negativo de los valores predeterminados del IoT

El ejemplo negativo de manual de «usemos sin más la misma contraseña predeterminada en cada unidad» es la botnet Mirai. Mirai explotó una lista codificada de unas 62 combinaciones de usuario/contraseña predeterminadas de fábrica (admin/admin, root/root, root/xc3511, root/vizxv) para infectar cientos de miles de cámaras IP, grabadores DVR y routers domésticos a finales de 2016, y luego las usó el 21 de octubre de 2016 para tumbar al gran proveedor de DNS Dyn, dejando fuera de servicio brevemente a Twitter, Reddit, Netflix y GitHub. Un generador masivo de contraseñas es exactamente la primitiva adecuada para la alternativa: producir un valor predeterminado único y fuerte por unidad en la línea de producción, imprimirlo en una pegatina y enviarlo dentro de la caja.

Más preguntas

¿Por qué el NIST recomienda la longitud antes que la complejidad?

Porque forzar la complejidad (un dígito, un símbolo, una letra mayúscula) empuja a los usuarios hacia patrones predecibles que el atacante ya ha modelado. Password1! tiene matemáticamente más entropía que password, pero en la práctica la lista de palabras de todo atacante empieza ahí. Una cadena de 20 caracteres todos en minúsculas procedente de un CSPRNG tiene ~94 bits de entropía y no puede adivinarla ninguna lista de palabras porque no coincide con ninguna lista de palabras. La NIST SP 800-63B Rev 4 (julio de 2025) convierte la prohibición de las reglas de composición en un requisito obligatorio de tipo SHALL NOT.

¿Debería usar frases de contraseña en su lugar?

Para las contraseñas que tienes que memorizar, sí: eso es lo que defendía el xkcd #936 (10 de agosto de 2011). El método Diceware (Arnold Reinhold, 1995) da 12,9 bits por palabra a partir de una lista de 7.776 palabras; seis palabras ≈ 77,5 bits es la recomendación moderna. La EFF publicó listas de palabras compatibles con Diceware actualizadas en julio de 2016. Pero para el caso de aprovisionamiento masivo al que sirve esta herramienta (tokens temporales que se cambian en el primer inicio de sesión), el ASCII aleatorio es la primitiva adecuada porque el usuario nunca necesita teclearlo.

¿Excluir los caracteres ambiguos es un compromiso de seguridad?

Sí, técnicamente: eliminar i, l, 1, L, O, 0, o reduce el alfabeto de 94 a 87 y baja la entropía por carácter de 6,55 bits a 6,44 bits. Con 16 caracteres eso son 103,0 bits en lugar de 104,8 bits, algo completamente irrelevante. El compromiso merece la pena cuando las personas tienen que leer la contraseña en voz alta o transcribirla de una hoja impresa, que es justamente el escenario de distribución masiva al que sirve esta herramienta.

¿Cuál es la forma más segura de distribuir una lista generada?

Trata la lista generada como un artefacto de un solo uso. Distribúyela por un canal acordado de antemano (correo cifrado con PGP/GPG, transferencia segura de archivos, importación a un gestor de contraseñas, entrega en mano para contextos de alto riesgo). Configura los sistemas para que exijan un cambio de contraseña en el primer inicio de sesión. Elimina el archivo tras la distribución. Nunca envíes por correo listas en texto plano, nunca las subas al control de versiones, nunca las pegues en un chat. Las contraseñas generadas están pensadas como tokens de un solo uso: el valor está en la aleatoriedad criptográfica para la entrega inicial, no en la retención a largo plazo.

Herramientas relacionadas