Guias de Segurança
Falhas de design na redefinição de senha: 5 formas de tomar contas mesmo com login forte, e como corrigir
Uma senha longa e a autenticação multifator não ajudam se o 'Esqueceu sua senha?' for fraco: o atacante pode tomar a conta pela redefinição em vez do login. As cinco formas como a redefinição falha, o que o OWASP exige e como decidir o que a orientação deixa para você.
"Esqueceu sua senha?" leva a um mecanismo para deixar alguém que não sabe a senha definir uma nova. Isso o torna um caminho de autenticação — e normalmente o mais fraco que o serviço tem.
Por que fortalecer só o login não evita isso
Caminho habitual: login
Senhas longas · multifator · limitação de taxa · detecção de força bruta
─────── mesma conta ───────
Caminho separado: redefinição de senha
Funciona se o e-mail chegar · muitas vezes sem segundo fator · a força do token não aparece
A redefinição é construída como uma conveniência para os usuários, o que significa que muitas vezes ela não é projetada nem revisada com o mesmo rigor da autenticação. Na prática, porém, ela entrega o controle de uma conta a alguém que não sabe a senha. Ela pertence à mesma categoria do próprio login.
Isso bate com o que encontramos ao classificar os incidentes japoneses de 2026 pela forma como os atacantes entraram: entrar com credenciais válidas é mais comum do que explorar uma vulnerabilidade. Um fluxo de redefinição é onde um serviço emite essas credenciais pelo seu próprio procedimento oficial.
As cinco formas que a falha assume
- 1. Tokens adivinháveis
- Valores sequenciais, carimbos de tempo, strings curtas ou aleatoriedade não criptográfica. A redefinição de outra pessoa pode ser concluída por adivinhação ou força bruta
- 2. Tokens que nunca morrem
- Sem expiração, ainda válidos após o uso, reutilizáveis. Um link emitido uma vez continua funcionando indefinidamente
- 3. Links que continuam vivos numa caixa de e-mail
- Quem lê a caixa de e-mail pode ler o link de redefinição. Regras de encaminhamento, contas compartilhadas, a caixa de um colega que saiu — o e-mail é visto por mais olhos do que você imagina
- 4. Destinos definidos de fora
- Monte a URL de redefinição a partir do cabeçalho
Hostda requisição e um valor fornecido de fora pode acabar virando o link do seu e-mail (injeção de cabeçalho Host) - 5. Respostas que entregam a conta
- Uma mensagem prestativa de "não cadastrado", ou uma diferença no tempo de resposta, transforma o formulário em um jeito de verificar de fora quem tem conta (enumeração de usuários)
CWE-640, "Weak Password Recovery Mechanism for Forgotten Password" (mecanismo fraco de recuperação de senha esquecida), é o nome dado a essa classe. A definição: o produto "contém um mecanismo para os usuários recuperarem ou alterarem a senha sem saber a senha original, mas o mecanismo é fraco". Repare no que isso diz — o problema não é ter o recurso, é o recurso não ser tão forte quanto a autenticação que ele pode substituir.
Não faça das perguntas de segurança o único caminho
A posição do OWASP sobre perguntas de segurança é que elas não devem ser usadas como único mecanismo de redefinição de senha, porque as respostas muitas vezes são fáceis de adivinhar ou de obter pelos atacantes — embora observe que elas podem servir como camada adicional quando combinadas com outros métodos. O nome de solteira da mãe não é segredo numa época de perfis em redes sociais e registros públicos.
O que a orientação exige e o que ela deixa para você
É aqui que as implementações hesitam. Mantenha as duas coisas separadas.
Declarado explicitamente pelo OWASP
・Gerar tokens com um gerador de números aleatórios criptograficamente seguro
・Torná-los longos o bastante para resistir a força bruta
・Invalidá-los após o uso
・Retornar uma mensagem igual para contas que existem e que não existem
・Manter também tempos de resposta iguais, para evitar a enumeração
・Usar limitação de taxa, CAPTCHA ou controles parecidos contra envios automatizados
・Invalidar as sessões existentes automaticamente, ou perguntar ao usuário se deve fazê-lo
・Avisar o usuário por e-mail que a senha foi redefinida — e não colocar a senha nele
・Não depender do cabeçalho Host ao montar URLs de redefinição (fixe no código ou valide contra uma lista de domínios confiáveis)
・Garantir que a URL use HTTPS
Números que a orientação não fixa (cabe a você decidir)
・O tamanho real do token — só se diz "longo o bastante"
・O prazo de expiração — a invalidação no uso é exigida; o limite de tempo não recebe um número
Não leia a ausência de um número como "isso não precisa ser decidido". Precisa ser decidido com um motivo, e registrado por escrito.
Nossos padrões práticos: pelo menos 128 bits de aleatoriedade numa codificação segura para URL; expiração na casa das dezenas de minutos; invalidação no uso; e invalidação dos tokens antigos sempre que um novo for emitido para a mesma conta. Os números importam menos que as três propriedades — impossível de adivinhar, não reutilizável, não eterno.
Ordem de implementação
Torne o token impossível de adivinhar (primeira prioridade)
Gere-o com uma fonte aleatória criptográfica e codifique-o de forma segura para URL. Não use uma função aleatória de uso geral — "parece aleatório" e "não pode ser previsto" são propriedades diferentes. Guarde um hash do token em vez do próprio token, para que um banco de dados legível não entregue de imediato tokens utilizáveis (o mesmo raciocínio de armazenamento de senhas, hash e salt).
Dê a ele uma validade e permita um único uso
Invalide no uso e também por tempo. Quando um novo token for emitido para a mesma conta, invalide também os antigos — esqueça isso e você volta à forma 2.
Nunca monte a URL a partir de entrada externa
Gere o link de redefinição a partir da configuração ou valide-o contra uma lista de domínios confiáveis. Não repasse um cabeçalho da requisição para o e-mail. O OWASP cita este ponto diretamente.
Uniformize as respostas e limite a taxa
Retorne o mesmo texto e o mesmo tempo nos dois casos e envie e-mail só quando a conta existir de fato. Adicione limitação de taxa por conta ou um CAPTCHA contra envios automatizados. Os usuários não são prejudicados; de fora, os dois casos ficam indistinguíveis.
Feche o processo na conclusão
Ao concluir uma redefinição, invalide as sessões existentes — se a conta já tinha sido tomada, essa é a única forma de expulsar o atacante — e envie um aviso de que a senha foi redefinida (sem a senha nele). Onde puder, exija um segundo fator também no caminho de redefinição, para que ela não vire o jeito de contornar a autenticação multifator.
Do que a redefinição realmente depende é a caixa de e-mail
Faça tudo o que está acima e a segurança da redefinição ainda depende de só o titular da conta poder receber o e-mail. Se a conta de e-mail estiver comprometida, um fluxo de redefinição bem construído entrega a conta ao atacante com mais confiabilidade do que um mal feito. Por isso a prioridade do lado do usuário cai no mesmo lugar: dê à conta de e-mail a sua proteção mais forte — uma senha forte e exclusiva e autenticação multifator, de preferência uma passkey. Esse também é o caminho pelo qual uma violação no provedor chega até você (o que fazer quando o seu provedor de hospedagem é invadido).
Como isso aparece do lado do usuário
- Um e-mail de redefinição que você não pediu é um aviso de que alguém tentou. Não siga o link — entre no serviço por conta própria e verifique (o phishing chega com exatamente a mesma aparência).
- Ser desconectado dos outros dispositivos após uma redefinição é sinal de uma implementação correta. Um serviço que mantém as outras sessões vivas após uma redefinição não lhe dá como cortar um invasor.
- Nenhum segundo fator pedido durante a redefinição significa que a autenticação multifator pode ser contornável por esse caminho naquele serviço. Vale testar uma vez nas contas que importam.
- Acabar com a reutilização de senhas é um trabalho melhor entregue a um gerenciador de senhas.
A visão deste site: construa como autenticação, não como conveniência
Fluxos de redefinição ficam fracos não por serem tecnicamente difíceis, mas por serem classificados na categoria errada. O login é construído com cuidado pelo pessoal de autenticação; o "Esqueceu sua senha?" é construído às pressas como um canal de suporte. Essa diferença de tratamento é a fraqueza. Nossa posição é simples: qualquer operação que entrega o controle de uma conta é um recurso de autenticação — redefinição, troca do endereço de e-mail, novo cadastro de um segundo fator, recuperação manual por um atendente. A força é definida pelo caminho mais fraco, não pelo mais forte. Liste todas as rotas que chegam a uma conta no seu próprio serviço; geralmente há mais do que você imaginava.
Fontes (primárias)
- OWASP Cheat Sheet Series, "Forgot Password Cheat Sheet" — cheatsheetseries.owasp.org (todo requisito listado acima como "declarado explicitamente" vem deste documento; ele não informa um tamanho de token nem um prazo de expiração)
- MITRE, CWE-640 "Weak Password Recovery Mechanism for Forgotten Password" — cwe.mitre.org
Leia a seguir
- Defesa: como escolher e usar um gerenciador de senhas / armazenamento de senhas, hash e salt
- Termos: o que é a autenticação de dois fatores / o que é uma passkey / o que é phishing
- Controle de abuso: limitação de taxa e controle de abuso (onde fica a limitação de taxa do caminho de redefinição)
- Tendência: em 2026, os atacantes chegaram mais com credenciais do que com exploits
FAQ
QSe a autenticação multifator está ativada, uma redefinição de senha fraca ainda importa?
Sim. Muitas implementações não exigem um segundo fator no caminho de redefinição e, quando é assim, a redefinição é uma forma de retomar a conta contornando o segundo fator. O que você protege não é a força da tela de login, mas a força de todos os caminhos que chegam à conta. Invalide as sessões existentes quando uma redefinição for concluída e, onde puder, exija o segundo fator também no caminho de redefinição.
QQual deve ser o tamanho de um token de redefinição e quanto tempo ele deve durar?
O OWASP Forgot Password Cheat Sheet diz que os tokens devem ser gerados com um gerador de números aleatórios criptograficamente seguro, ser longos o bastante para resistir a força bruta e ser invalidados após o uso — ele não informa um número de caracteres nem de minutos. Isso cabe a você decidir. Nossos padrões práticos: pelo menos 128 bits de aleatoriedade numa codificação segura para URL, expiração na casa das dezenas de minutos, invalidação no uso e invalidação dos tokens antigos sempre que um novo for emitido para a mesma conta. Os números importam menos que as três propriedades: impossível de adivinhar, não reutilizável, não eterno.
QMostrar 'esse e-mail não está cadastrado' não é o mais útil?
Útil para os seus usuários, e uma forma gratuita de o atacante verificar quais endereços têm conta com você. O OWASP pede uma mensagem igual para contas que existem e que não existem, e respostas que voltem num tempo igual. Mostre a mesma coisa nos dois casos e envie e-mail só quando houver de fato uma conta — os usuários não são prejudicados e a diferença fica invisível de fora.
QO que posso fazer como usuário?
Um e-mail de redefinição que você não pediu é um aviso de que alguém tentou redefinir a sua conta. Não siga o link — entre no serviço por conta própria e verifique se a senha não é reutilizada em outro lugar e se a autenticação multifator está ativada. E lembre do que a redefinição realmente depende: a sua caixa de e-mail. Se alguém consegue ler o seu e-mail, consegue redefinir as senhas de várias das suas contas em sequência. Dê à conta de e-mail a sua proteção mais forte.