---
title: "O que é credential stuffing? Como detectar e impedir"
description: "Credential stuffing é a reutilização automatizada de logins e senhas vazados em outros sites. Como funciona, os sinais nos seus logs e como impedir."
url: https://proxynet.io/pt-br/blog/what-is-credential-stuffing
date: 2026-09-28
author: "Acar Diveroli"
category: "Proxy 101"
lang: pt-BR
---

# O que é credential stuffing? Como detectar e impedir

Uma pequena loja virtual tem seu banco de clientes vazado. Semanas depois, um serviço de streaming de vídeo recebe uma onda de logins em contas que nunca deram problema; uma plataforma de jogos vê o mesmo, e um banco também. Nenhum deles foi invadido. Os mesmos pares de e-mail e senha da loja simplesmente funcionaram nas páginas de login deles, porque muita gente usa uma única senha para tudo.

Este artigo olha o credential stuffing do lado de quem defende: como ele difere da força bruta e do password spraying, por que chega por milhares de endereços IP, que sinais deixa nos seus logs, quais controles o detêm e o que os usuários podem fazer. Há dois exemplos curtos em Python, ambos defensivos.

> **Nota: Resposta rápida**
>
> Credential stuffing (literalmente, "enchimento de credenciais") é um ataque automatizado em que alguém pega pares de usuário e senha vazados de um site e os testa nas páginas de login de outros sites, apostando que as pessoas reutilizam senhas. Ele só dá certo onde um usuário repetiu a senha. Donos de sites o impedem com autenticação multifator, recusando senhas que aparecem em listas de vazamentos, limitando tentativas falhas por conta e com detecção de bots. Bloquear endereços IP sozinho não funciona, porque as tentativas se espalham por muitos endereços. Os usuários o impedem dando a cada conta uma senha própria ou uma passkey.

## O que é credential stuffing?

Credential stuffing é a reutilização em grande escala de dados de login roubados. O atacante começa com pares que já se sabe serem reais, obtidos em um vazamento anterior de outro serviço, e os envia a um formulário de login com software automatizado. A maioria dos pares falha. Os que funcionam são de contas cujos donos usaram a mesma senha no site vazado e no alvo.

A [OWASP Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) o define como o teste de pares de usuário e senha "obtidos no vazamento de outro site". As senhas do próprio site atacado não foram roubadas e o código dele não tem falha; o ponto fraco é a reutilização de senhas.

O que o atacante quer é a tomada de conta (account takeover, ATO): um login válido em uma conta que guarda algo de valor. Podem ser pontos de fidelidade, um cartão salvo, saldo de vale-presente, dados pessoais ou simplesmente uma conta confiável para enviar spam. Contas tomadas costumam ser revendidas.

## Como funciona um ataque de credential stuffing?

De forma geral, um ataque passa por cinco etapas. Conhecê-las ajuda você a decidir onde colocar cada defesa.

1. **Um vazamento em outro lugar.** Um serviço é comprometido e sua lista de usuários, com e-mails e senhas (ou hashes de senha quebrados depois), passa a circular.
1. **Coleta.** Pares vazados de muitos incidentes são reunidos em listas enormes. Vazamentos antigos mantêm o valor por anos, porque muita gente nunca troca uma senha reutilizada.
1. **Automação.** Um software envia os pares ao formulário ou à API de login do alvo, muito mais rápido do que uma pessoa conseguiria digitar.
1. **Distribuição.** Para escapar de limites simples por IP, as requisições são espalhadas por muitos endereços IP, muitas vezes por botnets de dispositivos infectados ou redes de proxies alugadas, de modo que cada endereço envia só algumas tentativas.
1. **Uso dos acertos.** Os pares que funcionam são avaliados e depois usados ou vendidos. Alguns atacantes trocam na hora o e-mail e a senha para deixar o dono real de fora.

A etapa 1 acontece no servidor de outra pessoa. Suas defesas atuam nas etapas 3 a 5: tornar os logins automatizados caros, fazer com que uma senha correta não baste sozinha e perceber cedo uma tomada de conta. Verificar senhas contra listas de vazamentos vira a etapa 2 contra o atacante.

## Credential stuffing, força bruta e password spraying

Os três ataques miram as páginas de login, mas usam entradas diferentes e deixam rastros diferentes. As definições abaixo seguem a cheat sheet da OWASP.

| Ataque | O que é testado | Padrão | Taxa de sucesso típica por tentativa | Defesa principal |
|---|---|---|---|---|
| Força bruta | Muitas senhas contra uma conta | Uma conta, muitas senhas | Muito baixa, a menos que a senha seja fraca | Limites de tentativas por conta, senhas longas |
| Password spraying | Uma senha comum contra muitas contas | Muitas contas, uma ou poucas senhas | Baixa, depende de senhas fracas | Lista de bloqueio de senhas comuns, MFA |
| Credential stuffing | Pares reais vazados, cada um testado uma vez | Muitas contas, uma senha cada | Maior, porque cada par era real em algum lugar | MFA, verificação de senhas vazadas, detecção de bots |

Bloquear uma conta após cinco senhas erradas detém a força bruta. Quase não afeta o credential stuffing, porque cada conta costuma receber uma só tentativa.

## Por que proxies e IPs residenciais aparecem nesses ataques

Bloquear um endereço IP após vinte logins falhos parece proteção, então os atacantes passam as requisições por muitos endereços: roteadores domésticos sequestrados, dispositivos infectados, servidores na nuvem e redes de proxies. Endereços de conexões domésticas são difíceis de bloquear, porque clientes reais também podem usá-los.

Por isso a cheat sheet da OWASP diz que o bloqueio por IP e a reputação de IP "não devem ser usados como defesa única ou principal". Há três problemas práticos:

- **Pouco volume por endereço.** Quando cada endereço envia uma ou duas tentativas, nenhum limite por IP é acionado.
- **Endereços compartilhados.** Operadoras móveis e muitos provedores domésticos colocam muitos clientes atrás de um único endereço público (NAT de nível de operadora, CGNAT). Bloquear esse endereço pode deixar usuários reais de fora.
- **Rotatividade.** Os endereços mudam rápido, então uma lista de bloqueio fica desatualizada quase assim que é escrita.

Ainda assim, dados de IP são úteis como um sinal entre vários. Um [IP fraud score](/pt-br/blog/ip-fraud-score) ou uma ocorrência em uma [lista negra de IP](/pt-br/blog/ip-blacklist) pode elevar o risco de um login e acionar uma verificação extra em vez de um bloqueio direto.

Uma observação sobre a nossa própria rede: os [Termos de serviço](/pt-br/tos) da Proxynet proíbem tentativas de acesso não autorizado, e contas que violam as regras de uso aceitável podem ser suspensas sem aviso. Usos legítimos, como testar o seu próprio site a partir de outros países, estão na nossa página de [segurança de dados](/pt-br/data-security).

## Sinais de que você está sob ataque

Nenhum sinal isolado prova um ataque, mas vários juntos são difíceis de ignorar. Estes são os que valem um lugar no painel:

- **Um salto na taxa de logins falhos.** A maioria dos pares vazados não confere, então uma rodada faz subir bruscamente uma taxa normalmente estável.
- **Muitas falhas de "usuário desconhecido".** Listas vazadas contêm e-mails que nunca se cadastraram no seu site.
- **Muitas contas, uma tentativa cada.** A razão entre nomes de usuário distintos e tentativas fica perto de um, o oposto do padrão de força bruta.
- **Muitos endereços IP, poucas tentativas cada,** muitas vezes de redes que raramente enviam usuários reais para você.
- **Impressões digitais de cliente idênticas** em milhares de usuários "diferentes"; [como funciona a detecção de bots](/pt-br/blog/how-bot-detection-works) explica esses sinais.
- **Logins sem visualização de página.** Requisições que vão direto à API de login sem carregar a página de login, seus scripts ou imagens.
- **O que acontece depois do acerto.** Um login seguido, em segundos, de uma troca de e-mail, senha ou dados de recebimento.

Muitas vezes os usuários percebem antes de você: um [alerta de login suspeito do banco](/pt-br/blog/bank-suspicious-login-location) ou um e-mail de "novo acesso" que eles não provocaram. Facilite para que possam avisar.

## Como impedir credential stuffing no seu site

A cheat sheet da OWASP lista as defesas em ordem aproximada de valor. A lista abaixo mantém esse espírito e acrescenta o que o [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) (Revisão 4, definitiva desde agosto de 2025) exige dos sistemas de senha.

1. **Autenticação multifator.** A OWASP chama a MFA de "de longe, a melhor defesa" contra ataques a senhas: uma senha vazada correta já não basta. Exija-a em contas de administração e em ações de risco, e acione-a quando os sinais acima dispararem.
1. **Passkeys.** Uma passkey substitui a senha por um par de chaves guardado no dispositivo do usuário. A [FIDO Alliance](https://fidoalliance.org/passkeys/) as descreve como resistentes a phishing, e não há no seu servidor nenhum segredo compartilhado para vazar ou reutilizar. Uma conta que entra só com passkey não deixa nada para o credential stuffing testar.
1. **Verificação de senhas vazadas.** O NIST SP 800-63B, na seção 3.1.1.2, determina que os verificadores comparem cada nova senha com uma lista de bloqueio de valores "comumente usados, previsíveis ou comprometidos". Verifique no cadastro e na troca de senha, e force uma troca quando houver indício de comprometimento.
1. **Limites de tentativas que acompanham a conta, não só o IP.** A seção 3.2.2 do NIST limita a no máximo 100 as tentativas falhas consecutivas em uma conta. Combine isso com limites por dispositivo, por faixa de IP e por endpoint de login, e desacelere as respostas aos poucos em vez de bloquear contas.
1. **Gestão de bots.** Verifique se o cliente executa JavaScript e se a impressão digital da conexão corresponde ao navegador que ele diz ser. Um CAPTCHA é uma lombada, não a defesa inteira.
1. **A mesma resposta para toda falha.** Retorne a mesma mensagem e um tempo parecido para "senha errada" e "usuário inexistente", para que o formulário de login não sirva para descobrir quais e-mails têm conta.
1. **Avise os usuários e observe a conta depois do login.** Envie alertas de acesso por dispositivo novo e de alterações na conta, e peça um segundo fator antes dessas alterações.

## Código: verificação de senhas vazadas com k-anonimato

A [API Pwned Passwords](https://haveibeenpwned.com/API/v3#PwnedPasswords) do Have I Been Pwned permite verificar uma senha contra vazamentos conhecidos sem enviar a senha, nem mesmo o hash completo. Você envia só os cinco primeiros caracteres do hash SHA-1; o serviço devolve todos os sufixos de hash que começam com eles, com uma contagem, e você procura o seu sufixo localmente. Esse é o modelo de k-anonimato (k-anonymity). A API de faixas não exige chave de API, e o cabeçalho `Add-Padding` acrescenta linhas falsas (contagem 0) para que o tamanho da resposta não revele nada.

```python
import hashlib
import time
import urllib.error
import urllib.request

API = "https://api.pwnedpasswords.com/range/"

def breach_count(password: str, retries: int = 3) -> int:
    """Retorna quantas vezes uma senha aparece no Pwned Passwords (0 = não encontrada)."""
    digest = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = digest[:5], digest[5:]
    request = urllib.request.Request(
        API + prefix,
        headers={"User-Agent": "example-signup-check", "Add-Padding": "true"},
    )
    for attempt in range(retries):
        try:
            with urllib.request.urlopen(request, timeout=5) as response:
                body = response.read().decode("utf-8")
            break
        except (urllib.error.URLError, TimeoutError):
            if attempt == retries - 1:
                raise
            time.sleep(2 ** attempt)
    for line in body.splitlines():
        candidate, _, count = line.partition(":")
        if candidate == suffix:
            return int(count)  # linhas de preenchimento têm contagem 0
    return 0

if __name__ == "__main__":
    for pw in ["password123", "correct horse battery staple", "vX9#qL2-mT8!rW4zK7"]:
        hits = breach_count(pw)
        verdict = "reject: seen in breaches" if hits else "not in the breach list"
        print(f"{pw!r}: {hits} -> {verdict}")
```

Ao rodar, as duas primeiras senhas aparecem como encontradas, com contagens que crescem conforme a base é atualizada; a sequência aleatória retorna 0. Em um formulário de cadastro, chame `breach_count` no servidor, recuse qualquer resultado diferente de zero com uma mensagem clara e decida de antemão o que acontece se a API estiver fora do ar.

## Código: identificar uma rodada de stuffing nos logs de login

A maioria dos sites já registra cada tentativa de login. O script abaixo lê um log CSV com as colunas `time`, `ip`, `username` e `result`, agrupa as tentativas por minuto e mostra os minutos em que a taxa de falhas é anormal, com a parcela de usuários desconhecidos e o número de contas e endereços distintos.

```python
import csv
from collections import defaultdict

ALERT_FAIL_RATE = 0.50
MIN_ATTEMPTS = 50

# Agrupa as tentativas de login em intervalos de um minuto.
buckets = defaultdict(lambda: {"total": 0, "failed": 0, "unknown": 0, "users": set(), "ips": set()})
with open("logins.csv", newline="") as f:
    for row in csv.DictReader(f):
        b = buckets[row["time"][:16]]          # "2026-09-28T10:41"
        b["total"] += 1
        b["users"].add(row["username"])
        b["ips"].add(row["ip"])
        if row["result"] != "ok":
            b["failed"] += 1
        if row["result"] == "unknown_user":
            b["unknown"] += 1

for minute in sorted(buckets):
    b = buckets[minute]
    fail_rate = b["failed"] / b["total"]
    unknown_share = b["unknown"] / b["total"]
    if b["total"] >= MIN_ATTEMPTS and fail_rate >= ALERT_FAIL_RATE:
        print(f"{minute}  attempts={b['total']}  failed={fail_rate:.0%}  "
              f"unknown-user={unknown_share:.0%}  accounts={len(b['users'])}  ips={len(b['ips'])}")
```

Com um log de teste que mistura tráfego normal e uma rajada simulada, a saída fica assim:

```text
2026-09-28T10:40  attempts=80  failed=78%  unknown-user=49%  accounts=80  ips=69
2026-09-28T10:41  attempts=80  failed=79%  unknown-user=45%  accounts=80  ips=70
```

Oitenta contas, quase o mesmo número de endereços e metade dos usuários desconhecidos: o padrão do credential stuffing. Defina os limites a partir do seu próprio tráfego normal.

## O que os usuários podem fazer

O credential stuffing só funciona com senhas reutilizadas, então os usuários têm controle real sobre ele.

- **Use um gerenciador de senhas** para que cada site tenha a sua própria senha aleatória.
- **Ative a autenticação de dois fatores**, começando pelo e-mail e pelo banco; um app autenticador ou uma chave de segurança é melhor que códigos por SMS.
- **Mude para passkeys** onde o site oferecer. Não sobra nenhuma senha para vazar ou reutilizar.
- **Consulte o seu e-mail no Have I Been Pwned** e troque qualquer senha que você tenha reutilizado.
- **Reaja aos alertas de "novo acesso"** que você não provocou: troque a senha e encerre as outras sessões.
- **Evite fazer login por redes desconhecidas.** Um proxy gratuito mantido por um estranho pode ler o seu tráfego; veja [Proxies gratuitos são seguros?](/pt-br/blog/are-free-proxies-safe).

## Onde isso mais importa

- **Lojas virtuais e marketplaces.** Cartões salvos, vales-presente e pontos de fidelidade fazem as contas valerem a tomada; veja na nossa página de [e-commerce](/pt-br/e-commerce-proxy) como as lojas testam as próprias vitrines.
- **Bancos e fintechs.** A tomada de conta leva direto à movimentação de dinheiro; a página de [finanças](/pt-br/finance) mostra como equipes financeiras verificam suas páginas públicas a partir de outras regiões.
- **Streaming e jogos.** Contas compartilhadas e revendidas são um mercado constante para logins roubados.
- **Qualquer site que colete dados pessoais.** Uma tomada de conta expõe os dados salvos do usuário, o que é um problema de proteção de dados além de fraude; [Como tratar dados pessoais (PII) em dados de scraping](/pt-br/blog/personal-data-in-scraped-datasets) trata do manuseio para equipes de dados.

## Erros comuns

- **Confiar no bloqueio por IP.** Ele falha contra ataques distribuídos.
- **Bloquear contas após poucas falhas.** Isso permite que atacantes deixem seus clientes de fora.
- **Mensagens de erro diferentes para "senha errada" e "conta inexistente".** Isso transforma seu formulário de login em um verificador de e-mails gratuito.
- **Proteger o formulário web mas não a API.** Apps móveis e versões antigas da API muitas vezes têm o próprio endpoint de login com limites mais fracos.
- **Exigir trocas periódicas de senha.** O NIST SP 800-63B diz para não fazer isso; force uma troca só quando houver indício de comprometimento.
- **Observar só o login.** A tomada de conta aparece com mais clareza no que acontece depois.

## Guia de decisão

| A sua situação | O que fazer primeiro |
|---|---|
| Os logins falhos disparam e a maioria dos usuários é desconhecida | Trate como credential stuffing: aumente a fricção em sessões de risco e peça um segundo fator nos logins bem-sucedidos a partir de dispositivos novos |
| Você mantém um site pequeno sem equipe de segurança | Adicione MFA, uma verificação de senhas vazadas no cadastro e na troca, e um serviço gerenciado de proteção contra bots na frente do login |
| Contas de administração ou da equipe usam só senha | Exija MFA ou passkeys para elas agora |
| Clientes relatam logins que não fizeram | Force a redefinição nas contas afetadas, avise os titulares e revise o que mudou depois do login |
| Hoje você só bloqueia IPs | Mantenha isso como um sinal; acrescente limites por conta e por endpoint e verificações de dispositivo |
| Você é um usuário que reutiliza senhas | Passe a usar um gerenciador de senhas e ative a autenticação de dois fatores, começando pelo e-mail |

## Perguntas frequentes

### Credential stuffing é crime?

Sim. Entrar na conta de outra pessoa sem permissão é acesso não autorizado segundo as leis de crimes informáticos da maioria dos países, qualquer que seja a ferramenta. Testes só são legais em sistemas que são seus ou para os quais você tem permissão por escrito.

### Qual a diferença entre credential stuffing e vazamento de dados?

Um vazamento é o roubo de dados de um serviço. O credential stuffing é o que vem depois, quando os pares roubados são testados em outros serviços. O site atacado pode nunca ter sofrido um vazamento.

### Um CAPTCHA impede o credential stuffing?

Ele desacelera e encarece o ataque, mas não é uma defesa completa. A OWASP o coloca como uma camada entre várias, atrás da autenticação multifator.

### Por que não bloquear a conta após três senhas erradas?

No credential stuffing cada conta costuma receber uma única tentativa, então o bloqueio raramente é acionado. Quando é, pode ser usado para deixar usuários reais de fora. Limites distribuídos entre conta, dispositivo e endpoint funcionam melhor.

### Verificar senhas no Pwned Passwords é seguro para os meus usuários?

Com a API de faixas, você envia só os cinco primeiros caracteres do hash SHA-1 da senha, e a comparação acontece no seu servidor. O serviço nunca vê a senha completa nem o hash completo.

### As passkeys acabam com o credential stuffing?

Para contas que entram só com passkey, sim: não existe senha reutilizável para testar. Enquanto um site ainda aceitar senhas como alternativa, essa alternativa precisa das mesmas proteções.

## Em resumo

O credential stuffing transforma o vazamento de um site em tomadas de conta em muitos outros, porque as pessoas reutilizam senhas. Ele se espalha por muitos endereços IP, então o bloqueio por IP sozinho não o detém. As defesas que funcionam são a autenticação multifator ou as passkeys, recusar senhas que aparecem em listas de vazamentos como exige o NIST SP 800-63B, limites de tentativas ligados a contas e dispositivos, detecção de bots e atenção ao que acontece depois de cada login. Os usuários fecham a porta do lado deles com um gerenciador de senhas e senhas únicas. Para testar de forma legítima os seus próprios fluxos de login e páginas a partir de outras regiões, veja nossos [serviços de proxy](/pt-br/proxy) e [Proxies residenciais](https://proxynet.io/pt-br/residential-proxy).