Por que senhas criadas por LLM são perigosas: parecem ter 100 bits, mas na prática têm 27 bits
(irregular.com)Com base em uma pesquisa da empresa de segurança Irregular, aponta-se que as senhas geradas por LLMs (modelos de linguagem de grande porte) recentes, como Claude, ChatGPT e Gemini, parecem muito fortes à primeira vista, mas na realidade são extremamente vulneráveis.
Principais resultados do experimento
- Repetiram 50 vezes o pedido “gere uma senha” para cada modelo
- Claude Opus 4.6: em 18 de 50 vezes gerou exatamente a mesma senha
G7$kL9#mQ2&xP4!w(36% idêntica), com apenas 30 senhas únicas - Há preferências de padrão bem claras por modelo
- Claude → começa com 'G' + segundo caractere '7'
- ChatGPT → começa com 'v'
- Gemini → começa com 'k' ou 'K'
- Mesmo mudando a temperatura (temperature) de 0.0 a 1.0, quase nada mudou (em 0.0, as 50 execuções geraram exatamente a mesma senha)
A ilusão da entropia (aleatoriedade)
- Em ferramentas como o KeePass, elas são avaliadas como “cerca de 100 bits de entropia, muito forte”
→ parecem exigir bilhões de anos até mesmo com um supercomputador - Mas, no cálculo real de entropia de Shannon, as senhas geradas pelo Claude ficaram em torno de 27 bits
→ senhas fracas que podem ser quebradas em segundos por um computador comum - Exemplo do GPT-5.2: probabilidade de o 15º caractere ser o dígito '2' é de 99,7% (quase fixo)
Por que LLMs não servem para gerar senhas?
- Senhas realmente fortes precisam ser geradas por um CSPRNG (gerador de números aleatórios criptograficamente seguro), com todos os caracteres saindo com probabilidade uniforme
- LLMs, ao contrário, são treinados para prever o próximo token mais plausível → maximizando a previsibilidade
- → Portanto, nem prompts melhores nem ajuste de temperatura resolvem o problema de forma fundamental (conclusão da Irregular)
Um problema ainda maior: o risco dos agentes de codificação com IA
- Claude Code, Gemini-CLI, Codex etc. fazem hardcode de senhas vulneráveis no código
Ex.: MariaDB, PostgreSQL, chaves de API do FastAPI etc. - “gere uma senha” → sugerem métodos seguros como
openssl rand
“recomende uma senha” → o LLM insere imediatamente uma senha padronizada criada por ele - Ao buscar no GitHub padrões como
K7#mP9ek9#vL, encontram-se vários repositórios reais
Conclusão
- LLMs conseguem criar senhas que “parecem fortes”, mas a segurança real não depende da aparência, e sim da entropia e aleatoriedade reais.
- Por causa do seu desenho centrado em previsão, LLMs são estruturalmente inadequados para gerar senhas e, em especial, quando ferramentas de codificação com IA as inserem no código, vulnerabilidades de segurança podem se espalhar de forma silenciosa no processo automatizado de desenvolvimento.
7 comentários
Se
openssl rand -hex 64já faz isso direito, será que realmente precisa fazer o LLM gerar a senha diretamente...?Mesmo quando você pede para uma pessoa criar uma senha, ela acaba fazendo de um jeito com algum padrão fixo para ficar mais fácil de lembrar.
Para desenvolvedores talvez não seja um grande problema. Mas hoje em dia, com o vibe coding, muita gente comum também está programando, então acho que o problema maior são os valores padrão que acabam sendo embutidos automaticamente no código. Por exemplo, senha de conexão com o DB e coisas do tipo...
De fato, considerando que já vi muitos casos em que um serviço web foi colocado no ar, mas arquivos sensíveis como
.envficaram liberados para acesso pela rede externa...Também dá para acontecer de alguém criar um serviço web no OpenClaw sem saber direito o que está fazendo, acabar embutindo a key direto no HTML e ter a chave roubada, recebendo uma cobrança inesperada de repente.
As pessoas também não são boas em escolher algo aleatoriamente. Não deveria haver padrão, mas evitar padrões de propósito também pode ser visto como um padrão.
Fico muito curioso para entender por que o Claude code não gerou uma string aleatória.
Ah... agora entendi por que os professores que ensinam cálculo de novo para os calouros de engenharia fazem aquela expressão.
buá buá, isso é meio pesado