admin123: a senha que ainda protege sistemas caros por aí

A reunião começou como tantas outras. Um fornecedor queria me apresentar o sistema que vendia, um painel de gestão usado por empresas da região. O homem era conhecido, tinha boa reputação, cobrava caro e se apresentava como o maior nome do setor por ali. Na hora da demonstração, ele digitou o login do painel administrativo na minha frente: o usuário era admin e a senha era admin123.

Ninguém na sala reagiu. Para quem trabalha com desenvolvimento, porém, aquela cena dizia muito. Não era um descuido isolado: era o retrato de um problema que o mercado de software repete há décadas, e que quase nunca vira assunto. Sistemas são vendidos com falhas de segurança conhecidas, e os clientes herdam o risco sem saber.

#Por que admin123 é tão grave

Pode parecer exagero se preocupar com uma senha. Não é. Senhas como admin123, 123456 e senha@123 são as primeiras que qualquer ataque automatizado tenta. Existem listas públicas com milhões de senhas vazadas em ordem de popularidade, e robôs percorrem essas listas contra painéis de login o dia inteiro, em todos os sites que encontram.

O relatório anual de vazamentos de dados da Verizon, um dos estudos mais citados do setor, mostra o tamanho do problema. Na edição de 2025, o uso de credenciais comprometidas foi o ponto de entrada em 22% dos vazamentos analisados.

Em outras palavras: na maioria das vezes, o invasor não precisa ser um gênio. Ele só precisa tentar a senha que todo mundo usa.

#O problema não é só do usuário

É comum culpar quem escolheu a senha fraca. Mas, no caso que eu vi, a responsabilidade era maior do que a de uma pessoa distraída. Um sistema vendido para várias empresas que permite admin123 como senha de administrador tem um defeito de fábrica.

Esse defeito tem até nome no catálogo internacional de falhas de software, o CWE, mantido pela organização americana MITRE: CWE-1392, uso de credenciais padrão. Ele descreve exatamente isso: produtos que usam senhas ou chaves padrão para funções críticas. Existe também o CWE-798, para senhas e chaves escritas direto no código-fonte.

O OWASP, a principal referência aberta em segurança de aplicações, coloca as falhas de identificação e autenticação entre os dez riscos mais importantes da web. Entre os exemplos estão permitir senhas padrão, fracas ou conhecidas.

#Como esse problema se espalha

Do lado de quem desenvolve, o roteiro costuma ser assim:

1. O sistema nasce com um usuário administrador de teste, com senha simples, para facilitar a instalação.
2. O sistema é vendido para o primeiro cliente, e a senha de teste vai junto.
3. Ninguém obriga a troca no primeiro acesso.
4. O mesmo pacote é vendido para o segundo, o terceiro, o décimo cliente.
5. Anos depois, todos estão rodando com a mesma senha, que qualquer funcionário antigo, ex-parceiro ou robô de ataque pode tentar.

É por isso que eu digo que o mercado vende o mesmo sistema com o mesmo problema. A falha não está num cliente: está no produto, replicada em cada instalação.

#O que dizem as regras atuais sobre senhas

Muita gente ainda segue regras antigas: mínimo de 8 caracteres, uma maiúscula, um número, um símbolo e troca a cada 90 dias. As diretrizes mais recentes do NIST, o instituto americano de padrões que serve de referência para o mundo todo, mudaram bastante:

Regra antiga	O que o NIST diz hoje
Mínimo de 8 caracteres	Mínimo de 15 caracteres para senha usada sozinha
Exigir maiúscula, número e símbolo	Proibido impor esse tipo de regra de composição
Trocar a senha a cada 90 dias	Proibido exigir troca periódica; troca só quando há suspeita de vazamento
Nenhuma verificação extra	Obrigatório comparar a senha com listas de senhas comuns e vazadas

A lógica é simples: senha longa vence senha complicada. Tr0c@r! é curta e previsível. cafe com pao de queijo na varanda é longa, fácil de lembrar e muito mais difícil de adivinhar.

#Se você compra ou usa um sistema

Faça estas perguntas ao fornecedor antes de assinar. Um fornecedor sério responde sem rodeio:

• O sistema obriga a trocar a senha inicial no primeiro acesso?
• Ele bloqueia senhas comuns e vazadas?
• Tem verificação em duas etapas (2FA)?
• Como as senhas ficam guardadas no banco de dados? A resposta certa envolve hash com algoritmos próprios para senha, como bcrypt, scrypt ou Argon2. Senha guardada em texto puro é sinal de alerta máximo.
• Com que frequência o sistema recebe atualizações de segurança?
• Existe limite de tentativas de login?

Se o fornecedor não souber responder, você já sabe o suficiente.

#Se você é usuário

1. Use senhas longas e diferentes para cada serviço. Um gerenciador de senhas resolve a parte de lembrar.
2. Ative a verificação em duas etapas em tudo que oferecer, principalmente e-mail, banco e redes sociais.
3. Confira se a sua senha já vazou no Pwned Passwords, do Have I Been Pwned.
4. Troque imediatamente qualquer senha padrão de equipamentos e sistemas: roteador, câmera, painel administrativo.
5. Desconfie de quem pede a sua senha. Nenhum suporte sério precisa dela.

#Se você desenvolve

Uma nota para colegas de profissão, porque o problema começa no nosso teclado:

• Nunca entregue o sistema com credencial padrão. Gere a senha inicial aleatória ou obrigue a criação no primeiro acesso.
• Bloqueie senhas presentes em listas de vazamento no cadastro.
• Guarde senhas só com hash próprio para senha, nunca com criptografia reversível nem em texto puro.
• Ofereça 2FA e limite as tentativas de login.
• Tire segredos do código-fonte. Chave de API e senha de banco ficam em variáveis de ambiente, não no repositório.

No Curtly, por exemplo, a conta tem verificação em duas etapas e as senhas nunca são guardadas em texto. Não por ser um diferencial, mas porque deveria ser o mínimo de qualquer sistema.

#O que fica

Saí daquela reunião sem fechar negócio, mas com um assunto que não saiu da minha cabeça. O fornecedor não era desonesto. Ele simplesmente nunca tinha parado para pensar que a senha mais famosa da internet protegia o painel que ele vendia para dezenas de empresas.

Segurança raramente falha por um ataque sofisticado de filme. Falha por um admin123 que ninguém trocou. A boa notícia é que é um dos problemas mais baratos de resolver: basta alguém, do lado de quem vende ou de quem compra, decidir que ele não vai mais passar.

Fontes: NIST SP 800-63B (diretrizes de senha), CWE-1392: uso de credenciais padrão, CWE-798: credenciais no código, OWASP: falhas de identificação e autenticação, Verizon: pesquisa sobre credential stuffing no DBIR 2025, Have I Been Pwned: Pwned Passwords.