Prevenir enumeração de contas em cadastro, login e redefinição

Como a enumeração de contas se parece na prática

A enumeração de contas ocorre quando alguém consegue dizer se um e‑mail, nome de usuário ou número de telefone está registrado apenas pelo modo como seu app responde. Não é preciso entrar. Basta tentar muitas combinações e observar diferenças em mensagens, códigos de status, tempo de resposta ou efeitos colaterais.

Cadastro, login e redefinição de senha são alvos comuns porque são públicos e naturalmente se comportam de forma diferente quando a conta existe. Isso facilita vazar pistas por acidente.

Um exemplo simples: um formulário de redefinição diz:

• “Enviamos um link de redefinição por e‑mail” quando o e‑mail existe
• “Conta não encontrada” quando não existe

Um atacante pode subir uma lista de 50.000 e‑mails e descobrir rapidamente quem usa seu produto. Essa lista pode ser vendida, usada para assédio ou para phishing direcionado (“Sei que você tem uma conta, clique neste link”). Também torna ataques de credential stuffing mais eficientes, porque o invasor foca apenas nos e‑mails já confirmados.

A enumeração é também uma questão de privacidade. Mesmo confirmar que alguém tem uma conta pode ser sensível em produtos de saúde, finanças, trabalho ou educação.

O objetivo é simples: fazer com que o resultado visível ao usuário seja indistinguível, exista a conta ou não, mantendo visão interna forte. Os usuários devem ver a mesma mensagem, o mesmo padrão de código de status e um tempo de resposta semelhante. Internamente, você ainda registra a verdade em logs e métricas.

Sinais que atacantes usam para adivinhar se uma conta existe

Atacantes não precisam do seu banco de dados. Precisam apenas de pequenas diferenças no que seu app retorna quando alguém digita um e‑mail ou telefone.

Os sinais mais óbvios estão na própria resposta: um 404 para “usuário não encontrado” vs 200 para “reset enviado”, ou JSON como error: \"no_such_user\". Mesmo que o texto pareça amigável, códigos de status diferentes, códigos de erro ou formatos de resposta distintos facilitam a automação.

O comportamento da UI pode ser igualmente revelador. Se o web app diz “Conta não encontrada” no login, mas o app móvel sempre diz “Verifique seu e‑mail”, atacantes usarão o caminho mais fácil. O mesmo aparece quando páginas HTML diferem das APIs JSON: uma pode vazar uma dica no corpo, em um header ou em um redirecionamento.

Sinais comuns que atacantes medem:

• Códigos de status e códigos de erro (200 vs 404, USER_NOT_FOUND vs INVALID_PASSWORD)
• Texto da mensagem e estados da UI (banners diferentes, campos destacados, botões desativados)
• Tempo de resposta (falha rápida para usuários desconhecidos, caminho mais lento para usuários reais)
• Prompts secundários (CAPTCHA aparece apenas após um “e‑mail real”)
• Efeitos fora de banda (e‑mail/SMS só enviados para contas existentes)

Diferenças de tempo importam mais do que a maioria das equipes espera. Se um pedido de reset retorna em 40 ms para um e‑mail ausente, mas 400 ms quando gera um token, grava no banco e enfileira um e‑mail, atacantes podem usar essa diferença como sinal confiável.

Também fique de olho em vazamentos acidentais por meio de tooling. Se detalhes internos de erro ou códigos de razão forem espelhados para o cliente (diretamente ou via logs client‑side verbosos), atacantes podem aprender “usuário existe” sem que sua UI diga isso.

Escolha um padrão seguro de resposta para cada endpoint

A maneira mais rápida de reduzir o risco de enumeração é decidir desde o início o que o usuário verá em cada fluxo e manter isso: mesma mensagem, mesma tela e mesmo próximo passo.

Trate cada fluxo separadamente (login, cadastro, reset), mas seja consistente dentro do fluxo. Use linguagem neutra e não comprometedora. Evite frases que confirmem existência como “não encontrado”, “conta não encontrada”, “já registrado” ou “usuário não existe”.

Padrões de resposta seguros que normalmente funcionam:

• Login: use uma falha genérica como “Não conseguimos autenticar. Verifique seus dados e tente novamente.” Mantenha as mesmas opções de ajuda sempre disponíveis.
• Cadastro: mostre algo como “Se você pode receber e‑mails nesse endereço, você receberá os próximos passos em breve.” Não altere a UI com base em o endereço já estar em uso.
• Redefinição de senha: mostre sempre “Se existe uma conta para esse e‑mail, enviamos instruções de redefinição.” Direcione sempre para a mesma tela de confirmação.

Texto é só parte disso. Atacantes observam o comportamento completo. Mantenha estes pontos alinhados entre os resultados:

• Mesmo padrão de código de status HTTP
• Intervalo de tempo de resposta parecido (evite caminhos de falha rápida óbvios)
• Mesma página, botões e calls to action
• Mesmo número de passos antes da confirmação

Uma abordagem prática para reset: mostre imediatamente a tela de confirmação e faça o trabalho em background. Internamente, registre se um e‑mail foi enviado, se houve bounce, supressão ou bloqueio, mas nunca reflita isso na resposta.

Passo a passo: torne as respostas indistinguíveis

Você precisa de um contrato claro: um endpoint deve parecer igual para um chamador externo, exista a conta ou não. Isso significa casar a mensagem visível, o status HTTP e a “sensação” da resposta.

Comece anotando o que você tem hoje e depois ajuste com pequenas mudanças testáveis:

• Faça um inventário de todos os pontos de entrada de auth: cadastro, login, redefinição de senha, verificação de e‑mail, “reenviar código”, além de cada cliente que os chama (web, mobile, API pública).
• Construa uma matriz de respostas para cada endpoint (sucesso, senha errada, e‑mail desconhecido, conta bloqueada, MFA exigido). Marque quais campos, códigos de status e ramos de UI diferem hoje.
• Padronize o que o cliente pode ver: escolha uma estratégia de código de status por endpoint e um corpo de resposta que nunca confirme existência de conta.
• Normalize o tempo: se um caminho sai cedo, aproxime‑o ao caminho mais lento. Você pode adicionar pequeno jitter ou fazer o mesmo tipo de trabalho em ambos os caminhos.
• Atualize o comportamento da UI para corresponder ao contrato: não mostre “e‑mail não encontrado”. Mostre sempre o mesmo próximo passo.

Depois trave isso com testes, para que não regressemos quando o código mudar.

Testes para manter respostas indistinguíveis

Checagens automatizadas devem comparar saídas entre casos que costumavam vazar sinais:

• Asserte o mesmo código de status e forma de resposta para “e‑mail conhecido” vs “e‑mail desconhecido”.
• Asserte que mensagens de falha são idênticas (ou igualmente vagas) entre os casos de falha.
• Meça o tempo dos dois caminhos e falhe no teste se a diferença exceder um pequeno limite.
• Adicione um teste de integração que simule um pedido de reset completo e confirme que a interface não ramifica com base em “conta existe”.

Cadastro, login e reset: modelos práticos de mensagem

Para evitar enumeração, suas respostas públicas devem parecer iguais exista a conta ou não. O truque é ser entediante externamente enquanto se mantém preciso internamente (logs, métricas, ferramentas de suporte).

Modelos de resposta do endpoint (o que o cliente vê)

Mantenha códigos de status e formato de mensagem consistentes. Se você retornar JSON, sempre retorne os mesmos campos.

• Login (qualquer falha): 401 com { \"error\": \"Invalid email or password.\" }
• Cadastro (aceitar solicitação, mesmo que o e‑mail já exista): 200 com { \"message\": \"If you can sign up, you’ll receive an email with next steps.\" }
• Redefinição de senha (sempre): 200 com { \"message\": \"If an account exists for that email, we sent reset instructions.\" }

No login, é normal retornar 401 para autenticação falhada. O essencial é que todas as falhas de login pareçam iguais (e‑mail desconhecido vs senha errada), incluindo forma de resposta e tempo.

Modelos de e‑mail/SMS (o que o usuário recebe)

O conteúdo da mensagem também pode vazar existência. Evite e‑mails do tipo “Conta não encontrada”. Prefira comportamento silencioso ou notas genéricas.

Exemplos que funcionam:

• Verificação de cadastro: “Confirme seu e‑mail para continuar. Se você não solicitou isso, ignore esta mensagem.”
• E‑mail de redefinição: “Recebemos um pedido para redefinir sua senha. Se você não solicitou, ignore esta mensagem.”
• SMS de reset: “Seu código de redefinição é 123456. Se você não solicitou, ignore esta mensagem.”

Para contas inexistentes, o padrão mais seguro frequentemente é silencioso: mostre a mesma mensagem na tela, mas não envie nada.

Preserve analytics e ferramentas de suporte sem vazar informação

Respostas uniformes não significam ficar às cegas. Você pode capturar exatamente o que aconteceu; apenas mantenha o detalhe no lado do servidor.

Um padrão simples: retorne a mesma mensagem visível, mas grave um código de razão interno estável para cada solicitação. Esses códigos nunca devem aparecer nas respostas de API, texto da UI ou logs client‑side.

Exemplos de códigos de razão internos:

• login_failed_no_user
• login_failed_wrong_password
• login_failed_mfa_required
• reset_requested_no_user
• reset_sent

Associe cada requisição de auth a um correlation ID gerado no servidor. Use‑o em logs e eventos de auditoria para traçar uma requisição entre seu serviço de auth, provedor de e‑mail e banco de dados sem expor nada ao usuário. Se mostrar um request ID ao usuário para suporte, mantenha‑o genérico e assegure que não revele o status da conta.

Times de suporte ainda precisam ajudar usuários reais. Mantenha as ferramentas de busca de suporte protegidas por autenticação interna e por padrão com saída mínima. “Conta encontrada” é aceitável dentro do console; nunca deve ser algo que um chamador público possa inferir.

Seja rigoroso com PII. Registre o mínimo que seja útil:

• Hash ou tokenize e‑mails nos logs quando possível
• Armazene e‑mails completos apenas em sistemas que já têm política para eles
• Mantenha retenção curta, salvo exigência de compliance

Adicione guardrails: limitação, detecção e controles de abuso

Mensagens uniformes são a base, mas não a defesa completa. Você também precisa de guardrails que tornem a automação cara e ajudem a detectar padrões cedo.

Throttling e atrasos progressivos

Comece com limites que tornem a automação cara sem atrapalhar usuários normais. Aplique limites por IP e fingerprint de dispositivo, e adicione uma checagem cuidadosa no identificador submetido (e‑mail/telefone) sem transformá‑la em um novo sinal. Uma abordagem comum é manter contadores separados e aplicar o resultado mais restritivo.

Após tentativas repetidas, adicione atrasos que crescem ao longo do tempo. Mantenha o comportamento de atraso igual exista a conta ou não. Se aplicar bloqueio, não diga “conta bloqueada” na mensagem ao usuário. Trate bloqueio como um estado interno.

Um setup prático:

• Teto por IP (janela curta) para impedir rajadas
• Teto por dispositivo para pegar IPs compartilhados (cafés, escritórios)
• Teto por identificador para desacelerar adivinhação direcionada
• Atraso progressivo após N falhas, aplicado uniformemente
• Bloqueio suave com cooldown, mais alerta interno

CAPTCHA ajuda, mas não o mostre apenas quando um e‑mail existe. Dispare‑o com base em sinais de risco (volume, velocidade, automação suspeita) e mantenha o texto visível consistente.

Detecção e monitoramento de abuso

Enumeração tem padrões que você pode monitorar. Um bot pode tentar centenas de e‑mails únicos de um só IP, ou poucos e‑mails de muitos IPs.

Monitore e alerte sobre:

• Alto volume de requisições para login/reset/cadastro
• Muitos identificadores únicos por IP ou dispositivo
• Tentativas repetidas com baixa taxa de sucesso
• Picos em horários estranhos ou vindos de novas regiões
• Padrões entre endpoints (reset seguido de login com mesmos identificadores)

Erros comuns que reintroduzem enumeração

Muitas equipes consertam o texto óbvio e então vazam existência por canais laterais. Atacantes testam o fluxo inteiro, não só a frase na tela.

Códigos de status HTTP diferentes são um sinal instantâneo. Se um e‑mail conhecido retorna 200 mas um e‑mail desconhecido retorna 404 (ou 422), bots percebem imediatamente.

Tempo é o próximo delator. Um caminho acessa o banco, envia e‑mail ou faz hashing de senha enquanto o outro retorna cedo. Você não precisa de tempo constante perfeito, mas deve evitar diferenças consistentes entre falha rápida e caminho mais lento.

Conteúdo de e‑mail pode vazar também. E‑mails de reset que incluem nome do plano, último login ou saudação personalizada confirmam que a conta é real. Mantenha e‑mails de reset genéricos até o usuário provar controle da caixa seguindo o token.

Lógica de UI vaza com frequência. Um prompt “Criar conta” que aparece somente quando o e‑mail é desconhecido é uma dica. Validação inline como “e‑mail já usado” ajuda usuários honestos, mas também é um diretório para atacantes.

Checklist rápido:

• Retorne a mesma estratégia de código de status e o mesmo JSON com formato idêntico para ambos os resultados
• Mantenha o tempo de resposta na mesma faixa para ambos os caminhos
• Evite erros por campo que impliquem existência
• Não altere opções de UI com base em se o e‑mail existe
• Mantenha e‑mails de reset genéricos até o usuário verificar controle

Verificações rápidas antes de enviar para produção

Antes de fazer deploy, teste como um atacante. Um chamador externo não deve conseguir dizer se uma conta existe, enquanto sua equipe continua a ver a verdade na telemetria interna.

Um checklist rápido:

• Para login e reset, confirme que você retorna o mesmo padrão de códigos de status para contas existentes e não existentes.
• Compare corpos de resposta lado a lado. Eles devem ter os mesmos campos, tipos de dados e tamanho aproximadamente similar.
• Leia o conteúdo de e‑mail e SMS como um estranho. Mensagens nunca devem confirmar que um endereço ou telefone está registrado.
• Verifique se logs internos registram o resultado real (usuário encontrado vs não encontrado, token criado vs ignorado) com um request ID que o suporte possa buscar.
• Confirme que ferramentas de suporte mostram resultados apenas após autenticação da equipe, não em respostas públicas.

Em seguida faça um teste de timing. Escolha um endpoint (reset é um bom começo) e execute 20–30 requisições com um e‑mail que exista e outro que não exista. Procure uma diferença clara e repetível. Se houver, prefira preencher o caminho rápido ou mover trabalho caro para um job assíncrono.

Exemplo: corrigindo um fluxo de redefinição de senha que vaza

Uma pequena equipe SaaS começa a receber relatos de clientes: “Alguém fica tentando redefinir minha senha.” Os logs mostram muitos pedidos de reset para endereços que parecem uma lista de clientes. O padrão é clássico: alguém está sondando quais e‑mails existem.

O endpoint antigo tinha dois resultados fáceis de identificar:

• Se o e‑mail não existia: “E‑mail não encontrado. Tente se cadastrar.”
• Se o e‑mail existia: “Verifique sua caixa de entrada por um link de redefinição.”

Essa diferença é suficiente para confirmar contas válidas em escala. Mesmo que a UI pareça similar, pequenas mudanças em código de status, corpo de resposta ou tempo ainda vazam.

A correção é tornar a resposta pública idêntica sempre, e registrar o resultado real internamente usando códigos de razão.

Comportamento público (novo): mesma mensagem de UI e mesmo HTTP para todas as requisições, por exemplo: “Se existe uma conta para esse e‑mail, enviamos instruções.”

Comportamento interno (novo): grave um evento estruturado para que analytics, segurança e suporte possam agir:

{
  "event": "password_reset_requested",
  "email_hash": "sha256(...)" ,
  "result": "SENT" ,
  "reason_code": "OK",
  "ip": "203.0.113.10",
  "user_agent": "...",
  "request_id": "..."
}

Se o e‑mail não existir, mantenha a mesma resposta pública mas registre result: "NOOP" com reason_code: "ACCOUNT_NOT_FOUND". Se você bloquear por controles de abuso, registre reason_code: "RATE_LIMIT".

O suporte ainda pode ajudar sem confirmar nada publicamente. Se alguém disser “Não recebi o e‑mail”, o suporte pode buscar o último evento de reset por hash do e‑mail ou request ID. Se os eventos mostrarem repetidos NOOP, provavelmente o usuário digitou o endereço errado. Se os eventos mostrarem SENT mas sem entrega, você pode checar bounces no provedor de e‑mail sem alterar o que o formulário de reset revela.

Para validar a correção, faça um teste antes/depois: tente reset com um e‑mail conhecido e um aleatório, compare códigos de status, corpo de resposta e tempo. Eles devem ser indistinguíveis externamente, enquanto seus logs ainda mostram os resultados reais.

Próximos passos: implante com segurança e peça uma segunda opinião

Padronize um endpoint por vez. Redefinição costuma ser o de maior valor porque é fácil de sondar e frequentemente vaza diferenças óbvias. Depois que reset estiver consistente, passe para login e então cadastro.

Antes de deploy, mantenha um plano de testes simples que cubra sua UI web e quaisquer clientes de API (apps móveis, integrações, CLIs). Seja rigoroso sobre o que “mesma resposta” significa em todos eles.

• Teste e‑mails/nomes de usuário válidos e inválidos e compare códigos de status, forma do corpo e timing
• Teste contas bloqueadas, e‑mails não verificados e usuários com MFA
• Confirme que a UI ainda guia usuários reais sem dizer “essa conta existe”
• Verifique que logs e métricas ainda capturem o resultado real internamente
• Cheque localizações, já que traduções podem reintroduzir mensagens diferentes

Se você está lidando com código de autenticação gerado por IA, assuma que há vazamentos ocultos (campos JSON extras, retornos precoces, tratamento de erro diferente entre clientes). FixMyMess (fixmymess.ai) foca em diagnosticar e reparar esses tipos de problemas em produção, incluindo apertar respostas de auth enquanto mantém telemetria interna útil para suporte e segurança.