Ataques de força bruta no login: bloqueio progressivo sem punir o usuário honesto
Robôs testam milhares de senhas por hora na sua tela de login. Veja como bloquear ataques de força bruta sem trancar do lado de fora o cliente que só esqueceu a senha.
Por Equipe We Codex3 min de leitura
Se o seu sistema tem uma tela de login na internet, ele está sendo testado agora. Robôs percorrem listas de e-mails e senhas vazadas de outros sites, apostando que alguém repetiu a senha. Sem proteção, é questão de tempo até acertarem.
Os tipos de ataque
- Força bruta: muitas senhas para uma mesma conta.
- Credential stuffing: pares e-mail/senha vazados de outros serviços, uma tentativa por conta.
- Ataque distribuído: as mesmas tentativas vindas de milhares de IPs para escapar de bloqueios simples.
Defesa em camadas
- 1.Limite por IP: poucas tentativas por janela de tempo — o mecanismo de Rate limiting em Node.js: como proteger suas APIs contra sobrecarga e abusos sem afetar a UX.
- 2.Limite por conta: depois de algumas falhas, atrasos progressivos naquela conta, venha de onde vier.
- 3.Bloqueio temporário, não permanente: travar a conta para sempre deixa o atacante te usar para bloquear clientes.
- 4.Mensagens neutras: "e-mail ou senha incorretos" — nunca "este e-mail não existe".
- 5.Segundo fator: com 2FA, a senha certa não basta (Autenticação em dois fatores: implementar sem perder usuários).
Atrasos progressivos
Em vez de bloquear de cara, aumente o tempo de resposta a cada falha: 1 segundo, 2, 4, 8. Para um humano, quase imperceptível; para um robô testando milhares de senhas, o ataque fica inviável.
O usuário honesto
Quem errou a senha três vezes precisa de um caminho fácil: recuperação por e-mail funcional, mensagem clara com o tempo de espera e, de preferência, contagem regressiva na tela, como em Gerenciando o erro 429 Too Many Requests: exponential backoff e retry no cliente.
CAPTCHA: depois, não antes
Exigir CAPTCHA de todos piora a experiência. Mostre só quando há sinais de abuso — as alternativas estão em CAPTCHA sem irritar o usuário: honeypot, desafios invisíveis e sinais.
E as senhas guardadas?
Se o banco vazar, as senhas precisam estar protegidas por hash forte — veja Senhas: hash com bcrypt ou Argon2, nunca "criptografia".
Proteção de login faz parte da frente de Segurança Anti-Hacker da We Codex. Avalie o seu sistema.
- Segurança
- Login
- Rate Limit
- Autenticação
Resolver de vez, com quem faz isso todo dia
Quer saber quão exposto está o seu sistema hoje?
Este artigo mostra o caminho. A implementação sob medida — o detalhe que muda o resultado no seu caso — é o trabalho da We Codex, empresa de engenharia do grupo Wocom.
Continue lendo
Tudo sobre Segurança- Ler artigo
Segurança3 min
Autenticação em dois fatores: implementar sem perder usuários
Senhas vazam. O segundo fator impede que uma senha vazada vire uma conta invadida. Veja como implementar 2FA sem afastar usuários.
- Ler artigo
Segurança3 min
Rate limiting em Node.js: como proteger suas APIs contra sobrecarga e abusos sem afetar a UX
Sem limite de requisições, um script mal-intencionado (ou um bug no seu próprio app) derruba a API. Veja como aplicar rate limit no Node.js sem bloquear clientes legítimos.
- Ler artigo
Segurança3 min
Senhas: hash com bcrypt ou Argon2, nunca "criptografia"
"As senhas estão criptografadas" pode significar que alguém consegue revertê-las. Veja a diferença entre criptografia e hash e como guardar senhas do jeito certo.