Le pedí a Claude que generase 50 contraseñas. 18 eran la misma.

La semana pasada hice algo que probablemente tú también has hecho alguna vez: le pedí a una IA que me generase una contraseña segura.

"Genera una contraseña de 16 caracteres con mayúsculas, minúsculas, números y caracteres especiales."

Lo que me devolvió parecía perfecto: G7$kL9#mQ2&xP4!w. Dieciséis caracteres, mezcla de todo, imposible de adivinar a simple vista. Si la metes en cualquier verificador de fortaleza de contraseñas, te sale barra verde y un "excelente".

El problema es que esa contraseña es una mentira. Parece fuerte. No lo es. Y lo peor: la misma IA me la va a volver a generar si se lo pido mañana.

La firma de seguridad Irregular acaba de publicar una investigación que debería hacer replantearse cosas a cualquier persona que haya usado ChatGPT, Claude o Gemini para generar una contraseña. Que, según los datos que manejo, somos prácticamente todos.

El experimento: 50 contraseñas, 50 mentiras

Los investigadores de Irregular hicieron algo simple pero revelador: le pidieron a cada modelo que generase 50 contraseñas de 16 caracteres en conversaciones independientes. Misma petición, ventanas separadas, sin contexto compartido. Y analizaron los resultados.

Claude Opus 4.6 (Anthropic)

De las 50 contraseñas generadas, solo 30 eran únicas. Las otras 20 eran duplicados. Y de esas 20, 18 eran exactamente la misma cadena de caracteres.

Léelo otra vez: el 36% de las veces, Claude generó la misma contraseña.

Pero hay más. Analizaron los patrones:

• Casi todas empezaban con la letra "G" mayúscula
• El segundo carácter era casi siempre el dígito "7"
• Los caracteres L, 9, m, 2, $ y # aparecían en las 50 contraseñas
• La mayoría del alfabeto nunca apareció en ninguna de las 50 opciones
• Cero caracteres repetidos dentro de cada contraseña — algo que, paradójicamente, delata la falta de aleatoriedad real

ChatGPT GPT-5.2 (OpenAI)

• Casi todas las contraseñas empezaban por "v" minúscula
• Casi la mitad usaban "Q" como segundo carácter
• El modelo se apoyaba en un subconjunto reducido del alfabeto, ignorando la mayoría de caracteres disponibles

Gemini 3 Flash (Google)

• La mayoría empezaban por "K" o "k"
• Los caracteres que seguían eran casi siempre variaciones de #, P o 9

¿Ves el patrón? Cada modelo tiene su "firma". Un atacante que conozca qué modelo usaste puede reducir drásticamente el espacio de búsqueda.

Las matemáticas que lo explican todo

Aquí es donde la cosa pasa de preocupante a alarmante.

Una contraseña verdaderamente aleatoria de 16 caracteres (usando mayúsculas, minúsculas, números y símbolos) tiene una entropía de aproximadamente 98 bits. Eso significa 2^98 combinaciones posibles. Para ponerlo en perspectiva: un supercomputador necesitaría billones de años para probarlas todas.

Las contraseñas generadas por los LLM tienen una entropía real de aproximadamente 27 bits.

Métrica	Contraseña aleatoria real	Contraseña generada por LLM
Entropía total	~98 bits	~27 bits
Entropía por carácter	6,13 bits	2,08 bits
Combinaciones posibles	3,17 × 10²⁹	134.217.728
Tiempo de crackeo (GPU moderna)	Billones de años	Segundos a horas

No es un error tipográfico. 27 bits de entropía equivalen a unos 134 millones de combinaciones. Una GPU moderna prueba miles de millones de combinaciones por segundo. Estamos hablando de segundos para crackear lo que parece una contraseña "fuerte" de 16 caracteres.

Como lo resumió Irregular: "LLM-generated passwords could feasibly be brute-forced in a few hours, even on a decades-old computer."

Ni siquiera necesitas hardware moderno. Un portátil de hace diez años puede con esto.

¿Por qué los LLM nunca podrán generar buenas contraseñas?

La razón por la que las contraseñas LLM son débiles no es un bug que se pueda corregir con un parche. Es una limitación estructural del funcionamiento de estos modelos.

Un LLM funciona prediciendo el token más probable dado el contexto anterior. Toda su arquitectura está optimizada para producir secuencias plausibles y predecibles. Eso es exactamente lo que hace que sean buenos escribiendo texto: eligen la siguiente palabra que tiene más sentido.

Pero generar una contraseña segura requiere exactamente lo contrario: aleatoriedad uniforme e impredecible. Cada carácter debería ser completamente independiente del anterior. No debería haber ningún patrón, ninguna preferencia, ninguna tendencia.

Pedirle a un LLM que genere una contraseña segura es como pedirle a un pianista de jazz que toque notas completamente aleatorias. Por muy bueno que sea, su cerebro tiende a patrones armónicos. Es lo que sabe hacer. No puede evitarlo.

Los investigadores fueron categóricos:

"Passwords generated through direct LLM output are fundamentally weak, and this is unfixable by prompting or temperature adjustments: LLMs are optimized to produce predictable, plausible outputs, which is incompatible with secure password generation."

Subirle la temperatura, pedirle "sé más aleatorio", darle instrucciones más específicas... nada funciona. El problema está en la arquitectura, no en el prompt. No se puede arreglar con prompt engineering.

Lo que encontraron en GitHub es lo que me quita el sueño

Si esto fuera solo un problema teórico, podríamos archivarlo en el cajón de "curiosidades de seguridad". Pero no lo es.

Los investigadores de Irregular cogieron los patrones característicos de cada modelo — subcadenas como K7#mP9 o k9#vL — y los buscaron en GitHub y en la web abierta. Lo que encontraron:

• Docenas de repositorios reales con contraseñas generadas por LLM
• Credenciales de bases de datos en ficheros docker-compose.yml
• API keys en ficheros .env subidos por error
• Contraseñas en scripts de setup y documentación técnica

Y aquí viene lo que realmente debería preocupar a cualquier CISO: los agentes de código lo están haciendo sin que se lo pidas.

Herramientas como Claude Code, Codex y Gemini-CLI generan contraseñas automáticamente durante tareas de desarrollo. Cuando un agente crea un docker-compose.yml y necesita una contraseña para PostgreSQL, la genera él mismo. Cuando monta un .env de ejemplo, inventa las credenciales. Y el desarrollador, que ve una cadena de 16 caracteres con símbolos, asume que es segura.

No lo es. Nunca lo fue. Y ahora hay repositorios en producción con estas contraseñas.

Para ponerlo en contexto: en 2023, más de 12 millones de secretos y credenciales se filtraron en repositorios públicos de GitHub. A eso súmale que los datasets de entrenamiento de LLMs ya contenían 12.000 secretos activos (API keys, tokens, contraseñas) embebidos en HTML, JavaScript y ficheros de configuración de webs públicas. Los modelos no solo generan contraseñas débiles: aprendieron de contraseñas reales que estaban expuestas.

El ataque de diccionario que viene

Un atacante inteligente ya está tomando nota de esta investigación. El siguiente paso es obvio:

1. Generar miles de contraseñas con cada modelo principal (GPT, Claude, Gemini)
2. Catalogar los patrones de cada uno: caracteres iniciales, posiciones frecuentes, subconjuntos utilizados
3. Construir un diccionario especializado en contraseñas LLM
4. Lanzar ataques dirigidos contra servicios que saben que usan agentes de código IA

Un ataque de fuerza bruta estándar prueba todas las combinaciones posibles. Un ataque de diccionario prueba primero las más probables. Con 27 bits de entropía real, el diccionario de contraseñas LLM ni siquiera necesita ser grande.

Y lo más inquietante: no hay forma de saber, desde fuera, si una contraseña fue generada por un LLM o por un generador criptográfico real. Ambas parecen iguales a simple vista. La diferencia es que una tiene 98 bits de entropía y la otra tiene 27. La diferencia entre billones de años y segundos.

Mi opinión como CISO

Esto es un problema serio y me preocupa especialmente por tres razones:

Primera: la adopción de agentes de código se está acelerando a un ritmo que los equipos de seguridad no pueden seguir. Cada vez más desarrolladores usan Cursor, Claude Code, Copilot, Windsurf... y estos agentes toman decisiones de seguridad (como generar credenciales) sin supervisión humana. El desarrollador confía en el agente, el agente confía en el LLM, y el LLM genera basura criptográfica que parece oro.

Segunda: no hay visibilidad. ¿Cuántas contraseñas en tu infraestructura fueron generadas por un LLM? No lo sabes. Yo tampoco lo sé de la mía, y eso es exactamente el problema. No existe un escáner que distinga una contraseña LLM de una contraseña real. La única forma de saberlo es auditar el proceso de generación, y en la mayoría de organizaciones ese proceso no está documentado.

Tercera: la confianza ciega en la IA. He visto a ingenieros senior asumir que si Claude genera una contraseña, será segura. Al fin y al cabo, es una IA avanzada, ¿no? La realidad es que un LLM sabe menos de criptografía que /dev/urandom. Literalmente. Un generador de números pseudoaleatorios de los años 90 produce mejores contraseñas que el modelo de IA más avanzado del mercado.

No es culpa de los modelos. Están haciendo exactamente lo que fueron diseñados para hacer: predecir la siguiente secuencia más probable. El error es nuestro por pedirles algo para lo que no están diseñados y asumir que el resultado es seguro porque parece complejo.

¿Cómo generar contraseñas seguras de verdad?

La regla es simple y no tiene excepciones:

Nunca uses un LLM para generar secretos. Nunca. Bajo ninguna circunstancia.

Esto incluye contraseñas, API keys, tokens, secrets de JWT, claves de cifrado, seeds, nonces, y cualquier valor que requiera aleatoriedad criptográfica.

Lo que sí deberías usar:

Necesidad	Herramienta correcta	Por qué
Contraseñas personales	Gestor de contraseñas (1Password, Bitwarden, KeePass)	Usan CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
Contraseñas en código	secrets de Python, crypto.randomBytes de Node.js, /dev/urandom	Fuentes de entropía del sistema operativo
Secretos en infraestructura	Vault (HashiCorp), AWS Secrets Manager, Azure Key Vault	Generación, rotación y auditoría centralizada
Contraseñas en CI/CD	Variables de entorno cifradas, OIDC tokens	Nunca hardcodeadas, nunca generadas por el agente

Para los más técnicos, esto es todo lo que necesitas en un terminal:

# Python — 32 caracteres criptográficamente seguros
python3 -c "import secrets, string; print(''.join(secrets.choice(string.ascii_letters + string.digits + string.punctuation) for _ in range(32)))"

# OpenSSL — 32 bytes en base64
openssl rand -base64 32

# /dev/urandom directo
head -c 32 /dev/urandom | base64

Cualquiera de estas opciones produce contraseñas con entropía real, no la entropía de atrezzo que genera un LLM.

Plan de acción: 5 cosas que hacer esta semana

1. Audita las contraseñas generadas por agentes de código. Revisa los últimos 30 días de commits en vuestros repositorios. Busca ficheros .env, docker-compose.yml, config.yaml y cualquier fichero que contenga credenciales. Si fueron generados por un agente de IA, asume que las contraseñas son débiles y rótalas.

2. Establece una política de generación de secretos. Documéntalo y comunícalo: "Los secretos se generan con [herramienta X], nunca con ChatGPT, Claude ni ningún otro LLM." Parece obvio, pero si no lo escribes, alguien lo hará mal.

3. Integra secret scanning en vuestro pipeline. Herramientas como GitHub Secret Scanning, GitLeaks, TruffleHog o Nightfall detectan credenciales comprometidas en repositorios. Si no las tienes activadas, hazlo hoy. Son la red de seguridad para cuando alguien comete un error.

4. Configura los agentes de código para que no generen secretos. Si usas Claude Code, Cursor o similar, revisa la configuración. Algunos permiten restringir qué tipo de contenido genera el agente. Como mínimo, añade instrucciones en tu CLAUDE.md o equivalente: "No generes contraseñas ni secretos. Usa siempre placeholders como CHANGE_ME y referencia al gestor de secretos."

5. Rota cualquier contraseña que sospeches que fue generada por IA. Si no puedes demostrar que una contraseña fue generada por un CSPRNG, trátala como comprometida. Es mejor rotar 50 contraseñas innecesariamente que descubrir en una brecha que la de tu base de datos de producción tenía 27 bits de entropía.

Referencias

• Irregular — Vibe Password Generation: Predictable by Design — Investigación original con metodología completa.
• The Register — LLM-generated passwords 'fundamentally weak' — Cobertura técnica detallada.
• Malwarebytes — AI-generated passwords are a security risk — Análisis y recomendaciones.
• Gizmodo — AI-Generated Passwords Are Quite Easy to Crack — Patrones por modelo.
• The Hacker News — 12,000 API Keys in LLM Training Data — Secretos en datasets de entrenamiento.

---

98 bits frente a 27. Esa es la diferencia entre una contraseña que protege y una que solo lo parece.

Vivimos en un momento extraño: la tecnología más avanzada del planeta es incapaz de hacer algo que un script de tres líneas hace perfectamente. Y millones de personas confían en ella para proteger sus cuentas, sus datos y sus sistemas.

La pregunta de esta semana: ¿cuántas contraseñas en tu infraestructura fueron generadas por un LLM? Si la respuesta es "no lo sé", ya tienes tu primera tarea del lunes. Revisa, rota y documenta.