Un gestor de contraseñas no piensa una contraseña como lo harías tú. Para cada carácter, le pide al sistema operativo un byte genuinamente aleatorio, descarta los que inclinarían el resultado hacia una parte del alfabeto y traduce lo que queda al conjunto de caracteres que elegiste. Nada del resultado está pensado para ser memorable, pronunciable o libre de algo que un humano reconocería como un patrón: la memorabilidad es justo la propiedad que una buena generación de contraseñas destruye a propósito.
¿De dónde sale en realidad la aleatoriedad?
No de Math.random(). Todo motor de JavaScript trae esa función, y es rápida, está bien distribuida y es completamente incorrecta para este trabajo: es un algoritmo determinista con un estado interno pequeño y fijo, y su salida nunca se construyó para resistir a alguien que intente predecirla. V8, el motor detrás de Chrome y Node, usa un algoritmo llamado xorshift128+, y hay investigadores de seguridad que publicaron métodos que funcionan y que reconstruyen todo su estado interno a partir de una tanda corta de salidas consecutivas; después de eso, cada llamada futura es predecible, y también lo son las que ya se hicieron. El propio blog técnico del equipo de V8 dice sin rodeos que no se use para nada relacionado con la seguridad. Un generador de contraseñas construido sobre Math.random() no es realmente aleatorio: está ofuscado, que es algo distinto y mucho más débil.
Un generador de verdad, incluido el de esta página, llama en cambio a crypto.getRandomValues(). En un navegador, esa función se apoya en la propia fuente aleatoria criptográfica del sistema operativo —/dev/urandom en Linux y macOS, BCryptGenRandom en Windows—, el mismo pozo de imprevisibilidad que el sistema usa para generar claves de cifrado y datos de sesión TLS. La app de escritorio o de celular de un gestor de contraseñas nativo llama directamente a la API equivalente de la plataforma en lugar de pasar por un navegador. Nadie en esta cadena inventa aleatoriedad: todos sacan del mismo pozo que el sistema operativo mantiene revuelto justo para esto.
¿Por qué un byte aleatorio no se convierte sin más en un carácter?
Porque un byte tiene 256 valores posibles, y un conjunto de caracteres casi nunca divide ese número de forma exacta. Toma el conjunto por defecto de esta página —minúsculas, mayúsculas, dígitos y símbolos— y da 86 caracteres. 256 dividido 86 deja un resto de 84, así que mapear un byte a un carácter con un módulo simple haría que los primeros 84 caracteres del conjunto aparecieran un poquito más seguido que los dos últimos. El sesgo es pequeño en un solo carácter, pero es real y medible, y no desaparece a medida que la contraseña se hace más larga: solo se vuelve más difícil de notar.
La solución es lo que los criptógrafos llaman muestreo por rechazo: sacar un byte y, si cae en ese rango sobrante de 84 valores, descartarlo y sacar otro en lugar de usarlo. Cuesta un byte extra de vez en cuando y nada más, y a cambio cada carácter de la contraseña final es realmente igual de probable, no solo aproximadamente. Un generador que se salta este paso produce contraseñas que son más débiles de lo que su longitud sugiere, de una forma que ningún medidor de fortaleza posterior puede detectar jamás: el medidor no tiene forma de ver cómo se eligieron los caracteres, solo en qué terminaron.
¿Qué significan los "bits de entropía" en una contraseña generada?
Para una contraseña que inventó una persona, la entropía hay que estimarla, porque el costo real para un atacante depende de lo adivinable que sea el patrón subyacente; ese problema de estimación es todo el tema de cuánto se tarda en realidad en descifrar una contraseña. Para una contraseña sacada de forma uniformemente aleatoria, la cuenta es exacta en lugar de estimada: la entropía es el largo de la contraseña multiplicado por el logaritmo en base 2 del tamaño del conjunto de caracteres. Veinte caracteres de ese conjunto de 86 dan poco más de 128 bits, y cada uno de esos bits hace trabajo de verdad, porque el valor de ningún carácter estaba correlacionado con ningún otro carácter de la contraseña.
¿Por qué una contraseña que nunca escribes es un modelo de seguridad distinto?
Memorizar una contraseña obliga a dos concesiones que un generador no tiene que hacer: tiene que ser lo bastante corta como para caber en tu cabeza y, como recordar cuarenta distintas no es realista, termina reutilizada entre sitios. La reutilización es lo que de verdad vacía la mayoría de las cuentas, por credential stuffing y no por fuerza bruta. Un gestor que genera y guarda la contraseña elimina las dos concesiones a la vez: el largo deja de ser un impuesto a la memoria, y una contraseña única por sitio pasa de ser una aspiración que nadie sostiene a ser lo predeterminado.
También cambia de qué te estás defendiendo día a día. El autocompletado de un gestor de contraseñas comprueba el dominio exacto de la página antes de escribir nada, así que una página de inicio de sesión falsa y convincente en un dominio parecido no consigue nada de él: una comprobación que tu propia memoria no puede hacer, porque no puedes comparar dos nombres de dominio carácter por carácter tan bien como lo hace un software. Copiar y pegar la contraseña a mano en lugar de dejar que lo haga el autocompletado tira por la borda justo esa protección, porque un portapapeles no tiene ni idea de en qué página está a punto de pegarse.
Lo que ganas a cambio es un punto único de fallo que antes no tenías: la bóveda en sí, desbloqueada con una contraseña maestra o una credencial del dispositivo, y cifrada de la forma que sea antes de sincronizarse entre tus dispositivos. Esa bóveda es ahora lo que vale la pena atacar, y por eso su contraseña maestra es de las pocas que todavía conviene elegir como una frase de contraseña larga y memorizada en vez de un string generado: es la única contraseña que no tiene una bóveda propia que la guarde. Y una bóveda que deriva su clave de cifrado con una función rápida en lugar de una deliberadamente lenta como Argon2id tiene la misma debilidad que un hash a secas tiene para guardar cualquier contraseña, algo que vale la pena comprobar antes de confiarle a un gestor todo lo demás que tienes.
Lo que este generador no hace
Genera, y nada más. No guarda un historial de lo que produjo, no sincroniza nada entre dispositivos y no completa ningún formulario por ti: cerrar la pestaña descarta la contraseña junto con todo lo demás de la página. Eso es una limitación real frente a un gestor de contraseñas completo, y también es el punto: nada de esto necesita que le confíes tus cuentas, porque nunca las retiene el tiempo suficiente como para que importe.
El generador de contraseñas usa exactamente el mecanismo descrito arriba —crypto.getRandomValues() y muestreo por rechazo— y muestra la entropía resultante y un tiempo de descifrado en vivo frente a cinco atacantes mientras arrastras el control de longitud. Nada de lo que escribes o generas ahí sale de la página.
Para el puñado de credenciales que no puedes dejar en manos de un gestor, como la contraseña maestra que protege la bóveda misma, contraseña o frase de contraseña repasa cuándo una frase memorizada le gana de verdad a un string aleatorio, y cuándo no.
Preguntas frecuentes
¿Por qué Math.random() no es seguro para generar una contraseña?
Es un algoritmo determinista con un estado interno pequeño y fijo, y su salida nunca se construyó para resistir la predicción. Hay investigadores que publicaron métodos que funcionan para reconstruir ese estado interno a partir de una tanda corta de salidas consecutivas de la implementación de V8, y a partir de ahí cada llamada futura es predecible. Una contraseña construida con eso es tan segura como ese estado siga siendo secreto, y normalmente no lo es.
¿Qué es el muestreo por rechazo y por qué lo necesita un generador de contraseñas?
Es la técnica de descartar un byte aleatorio y sacar otro cada vez que ese byte cae en un rango que haría que algunos caracteres fueran un poco más probables que otros. Un byte tiene 256 valores posibles, y un conjunto de caracteres rara vez divide 256 de forma exacta, así que sin este paso la salida de un generador parece aleatoria pero está sesgada de forma medible hacia una parte del conjunto.
¿Una contraseña generada me protege por sí sola del phishing?
Solo de forma indirecta, a través del gestor que la guarda. El autocompletado de un gestor de contraseñas comprueba el dominio exacto antes de escribir nada, así que no hace nada en una página de inicio de sesión falsa y convincente: una comprobación que tu memoria no puede hacer. Copiar y pegar la contraseña a mano en vez de dejar que lo haga el autocompletado tira esa protección por la borda.
¿Cómo se calcula la entropía de una contraseña generada?
Es el largo de la contraseña multiplicado por el logaritmo en base 2 del tamaño del conjunto de caracteres: por ejemplo, 20 caracteres sacados de un conjunto de 86 dan poco más de 128 bits. Esa cifra es exacta y no estimada, porque supone que cada carácter se eligió de forma uniformemente aleatoria, algo cierto solo para una contraseña que produjo un generador, no una que inventó una persona.
¿Esta herramienta es en sí misma un gestor de contraseñas?
No. Genera una contraseña y muestra su entropía y su tiempo de descifrado, y nada de lo que produce se guarda, se sincroniza ni se rellena automáticamente en un formulario. Cerrar la pestaña descarta la contraseña. Igual necesitas un gestor de contraseñas de verdad para guardarla, autocompletarla y obtener la protección de comprobación de dominio que viene con eso.
Última actualización 24 de septiembre de 2026
