Quando a preguiça do usuário final vira uma vulnerabilidade no seu backlog

Se você é desenvolvedor, provavelmente já revirou os olhos ao ver “admin” como senha em algum ambiente de produção. Agora respire fundo: a sétima edição do levantamento anual da NordPass em parceria com a NordStellar acaba de confirmar que “admin” é oficialmente a senha mais usada no Brasil em 2025. Sim, em produção, em painéis administrativos, em contas de usuários reais, e muito provavelmente em algum sistema que seu time mantém.

A pesquisa analisou as 200 senhas mais comuns em 44 países e trouxe uma fotografia incômoda: mesmo com alertas constantes, campanhas de conscientização e manchetes frequentes sobre vazamentos, o brasileiro médio continua tratando autenticação como um obstáculo a ser driblado com a menor fricção possível. E adivinhe quem paga a conta quando o inevitável acontece? O time de engenharia.

O top 20 brasileiro é um manual de como não proteger uma conta

Antes de entrar na discussão técnica, vale olhar para o retrato completo do que os usuários estão escolhendo como primeira linha de defesa em suas contas:

1. admin

2. 123456

3. 12345678

4. 102030

5. 123456789

6. 12345

7. 12345678910

8. 123mudar

9. 10203040

10. gvt12345

11. password

12. 22446688

13. 142536

14. mudar123

15. 1234567

16. escola1234

17. 111111

18. 1234567890

19. 123123

20. 1q2w3e4r

Perceba algo curioso: a presença de “123mudar” e “mudar123” sugere que os usuários sabem que precisam trocar a senha padrão. Eles simplesmente escolhem outra senha igualmente fraca. É o equivalente a trocar uma fechadura quebrada por uma fita adesiva.

Outro ponto que merece atenção de quem desenvolve produtos corporativos: “gvt12345” e “escola1234” indicam fortemente senhas padrão distribuídas por instituições e provedores, que provavelmente nunca foram alteradas pelos usuários finais. Se o seu onboarding gera credenciais temporárias, essa é uma pista importante.

Caracteres especiais não são mágicos (e os atacantes sabem disso)

Uma das tendências globais mais interessantes do relatório é o crescimento de caracteres especiais: de 6 para 32 senhas com caracteres especiais no top 200 mundial em apenas um ano. Parece uma vitória, mas é uma vitória ilusória.

O caractere mais popular é o “@”, e as senhas mais comuns com caracteres especiais são coisas como P@ssw0rd, Admin@123 e Abcd@1234. Qualquer wordlist moderna usada em ataques de força bruta ou credential stuffing inclui essas variações há anos. Regras de complexidade que exigem “uma letra maiúscula, um número e um caractere especial” produzem exatamente esse tipo de senha, fraca, previsível e em conformidade com a sua política.

Se a sua política de senhas ainda é baseada apenas em complexidade sintática, está na hora de revisitar as recomendações do NIST SP 800-63B, que há anos prioriza comprimento sobre complexidade forçada e recomenda a verificação contra listas de senhas comprometidas.

A geração Z autentica como os Baby Boomers

Um mito que o relatório demole com elegância: o de que nativos digitais têm hábitos de segurança melhores. Karolis Arbaciauskas, chefe de produto da NordPass, resume bem: “Em relação às senhas, os jovens de 18 anos têm hábitos similares a pessoas de 80”. A diferença principal é estética, enquanto Baby Boomers usam nomes próprios (Maria lidera no Brasil entre essa faixa), a geração Z prefere combinações numéricas sequenciais e memes como “skibidi”.

Para quem desenha produto, isso significa parar de assumir que a segmentação por idade resolve o problema de UX de autenticação. Não resolve. O comportamento é transgeracional, e a solução precisa ser arquitetural.

80% das violações começam em uma senha ruim

O dado que deveria estar colado no monitor de todo tech lead: aproximadamente 80% das violações de dados são causadas por senhas comprometidas, fracas ou reutilizadas. Isso significa que a maior parte do perímetro de segurança das aplicações que construímos depende da capacidade do usuário final de criar uma string aleatória, algo para o qual o cérebro humano é notoriamente incompetente.

A conclusão inevitável é que o problema não pode ser resolvido no lado do usuário. Precisa ser resolvido no lado do sistema.

O que cabe ao dev fazer a partir de agora

A responsabilidade por proteger contas não pode continuar terceirizada para o usuário final. Algumas ações concretas que deveriam estar no roadmap de qualquer produto em 2026:

Adote passkeys como caminho principal. O padrão FIDO2/WebAuthn já é suportado nativamente pelos principais navegadores e sistemas operacionais. Passkeys eliminam o problema na raiz: não existe senha para ser fraca, reutilizada ou vazada. Plataformas como Google, Apple e Microsoft já oferecem login sem senha como padrão, e bibliotecas como SimpleWebAuthn facilitam a implementação.

Verifique senhas contra bases de vazamento. Serviços como o Have I Been Pwned oferecem uma API (Pwned Passwords) que permite checar se uma senha já apareceu em algum vazamento sem enviar a senha completa, usando k-anonymity. Implementar essa checagem no momento do cadastro e da troca de senha bloqueia automaticamente boa parte do top 200 da NordPass.

Imponha MFA como requisito, não como opção. A autenticação multifator não deveria ser um toggle escondido nas configurações. Para contas administrativas, acesso a APIs sensíveis ou dados críticos, MFA precisa ser obrigatória. TOTP via apps autenticadores é barato de implementar e elimina a dependência de SMS, que tem seus próprios problemas (SIM swap ainda é um vetor real).

Aumente o comprimento mínimo e abandone regras cosméticas. Uma senha de 16 caracteres aleatórios é ordens de magnitude mais segura que P@ssw0rd1. Siga a recomendação do NIST: mínimo de 8, recomendado de 15 ou mais, sem forçar composição, mas verificando contra listas de comprometidas.

Pare de gerar senhas padrão previsíveis. Se o seu sistema cria credenciais iniciais (como parece ser o caso de “gvt12345” e “escola1234”), use geradores criptograficamente seguros e force a troca no primeiro login. Melhor ainda: envie um link mágico único e descartável em vez de uma senha inicial.

Monitore comportamentos anômalos. Rate limiting em endpoints de autenticação, detecção de credential stuffing, lockout progressivo e logs auditáveis são básicos que ainda faltam em muitas aplicações brasileiras. Ferramentas como Cloudflare Turnstile ou implementações próprias de throttling resolvem boa parte do problema.

A senha está morrendo, só falta o seu produto entender isso

O próprio relatório reconhece que “o mundo está lentamente passando a empregar chaves de acesso”. A migração para autenticação sem senha não é mais uma discussão sobre se, mas sobre quando. E enquanto a transição acontece, cabe a nós, desenvolvedores, construir as pontes: oferecer passkeys como primeira opção, manter senhas robustas como fallback e parar de publicar produtos que dependem do usuário ser um especialista em segurança.

Enquanto “admin” continuar liderando qualquer ranking, o problema não é do usuário. É de quem permitiu que “admin” fosse aceito como senha em primeiro lugar.