Três ataques chegam pela mesma tela de login: a força bruta testa muitas senhas numa conta, o credential stuffing testa pares de e-mail e senha vazados de outro site, e o password spraying testa uma senha fraca em muitas contas. A resposta curta: cada um pede um contador diferente, por conta, por origem e pelo conjunto das falhas, e a defesa boa é graduada e temporária, como recomenda a OWASP, com o teto da NIST SP 800-63B-4 de no máximo 100 falhas seguidas por autenticador antes de desativá-lo.
Em resumo
- A OWASP separa os três ataques: força bruta (muitas senhas, uma conta), credential stuffing (pares vazados) e password spraying (uma senha, muitas contas).
- A NIST SP 800-63B-4 manda limitar as falhas seguidas num autenticador a no máximo 100, desativando-o.
- Bloquear a conta inteira por falha de senha deixa o atacante trancar quem ele quiser; o bloqueio do par conta e origem não.
- A OWASP pede resposta graduada e temporária, sem depender de um único limite previsível de volume.
- O segundo fator é, para a OWASP, a defesa mais eficaz contra os três.
Três ataques, três formas
A Credential Stuffing Prevention Cheat Sheet da OWASP abre com a tabela que organiza o assunto, e a diferença entre as linhas define onde contar.
| Ataque | O que o atacante faz | Onde o sinal aparece |
|---|---|---|
| Força bruta | Testa muitas senhas contra uma conta | Falhas seguidas na mesma conta |
| Credential stuffing | Testa pares de usuário e senha vazados de outro site | Muitas contas diferentes com falha a partir da mesma origem, e acertos raros espalhados |
| Password spraying | Testa uma senha fraca em muitas contas | Poucas falhas por conta, muitas contas no total |
A consequência prática é que nenhum contador sozinho basta. Contar só por conta não vê o spraying, que erra uma vez em cada conta. Contar só por IP não vê o ataque distribuído por muitas origens, cada uma com volume baixo. A OWASP pede, na seção de mitigação por IP, que a decisão considere "a multitude of abuse scenarios, and not rely on a single predictable volume limit", olhando rajadas curtas e períodos longos.
O teto da norma e o bloqueio que ajuda o atacante
A NIST SP 800-63B-4 fixa o limite de falhas na seção 3.2.2, a de limitação de taxa.
Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator.
O texto diz duas coisas que costumam passar batido. O número é um teto, não uma meta: pode ser menos. E o que se desativa é o autenticador, a senha, não a conta. A pessoa continua podendo entrar por outro caminho, como um código, e reativa a senha pela recuperação.
O erro comum é o oposto: trancar a conta inteira depois de poucas falhas, venham de onde vierem. Isso transforma a defesa numa arma, porque qualquer um que saiba o e-mail da vítima tranca a conta dela errando a senha de propósito. O desenho que evita isso tem dois níveis. O primeiro bloqueia o par formado pela conta e pela origem que errou: quem erra a partir de um lugar fica parado ali, e a pessoa legítima, de outro lugar, entra normalmente. O segundo é o teto da norma sobre a conta, que desativa só a senha quando as falhas se acumulam de todas as origens.
Nota
Origem não é sinônimo de pessoa. Muitas operadoras põem milhares de clientes atrás do mesmo endereço IP, e um limite por IP calibrado para uma casa tranca um bairro inteiro. Esse efeito está no artigo sobre IP compartilhado.
Resposta graduada, não muro
A OWASP descreve a resposta ao abuso como uma escada, não como um interruptor: "It is more effective to have a graduated response to abuse that leverages multiple defensive measures depending on different factors of the attack". E acrescenta que a mitigação, especialmente o bloqueio de IP, deve ser temporária, com processo para sair do estado de mitigação quando o abuso cai.
Na prática, os degraus vão do mais barato para quem é legítimo ao mais caro. Primeiro, desacelerar: a mesma cheat sheet cita o desafio computacional ("Proof-of-Work computational puzzle") e a espera antes da resposta como formas de aumentar o custo do ataque sem rastrear o usuário. Depois, desafiar a origem que acumula falhas em muitas contas. Por último, bloquear por tempo limitado. Toda falha conta; acerto não conta. Um limite que olha volume de acerto corta o cliente bom no pico de acesso, e o objetivo é cortar quem erra.
A OWASP pede ainda métrica em cada camada: volume detectado e mitigado, filtrável por origem, porque a defesa que falha em silêncio parece igual à defesa que funciona. O artigo sobre CAPTCHA no cadastro mostra o mesmo raciocínio de custo e conversão aplicado à porta de entrada.
O que vem depois do acerto
O credential stuffing bem-sucedido não erra a senha: ele acerta, porque o par veio de um vazamento. Por isso a cheat sheet da OWASP coloca o segundo fator como "by far the best defense against the majority of password-related attacks", e sugere pedi-lo nas circunstâncias suspeitas, como aparelho ou IP novos, país incomum ou IP que já tentou várias contas. Quando o segundo fator falha depois de uma senha certa, a OWASP recomenda avisar a pessoa para trocar a senha, porque a senha já está com alguém. A sequência completa da tomada de conta está em tomada de conta.
Perguntas frequentes
Quantas tentativas de senha devo permitir antes de bloquear?
A NIST SP 800-63B-4, seção 3.2.2, fixa o teto de 100 falhas seguidas no mesmo autenticador, desativando-o. O número da sua operação pode ser menor, e o bloqueio mais curto costuma ser o do par conta e origem, não o da conta.
Bloquear a conta depois de algumas senhas erradas é seguro?
Bloquear a conta inteira permite que qualquer um tranque a vítima errando a senha de propósito. A norma manda desativar o autenticador, e o bloqueio por origem impede a força bruta sem trancar a pessoa legítima.
Qual a diferença entre credential stuffing e força bruta?
Na força bruta, o atacante testa muitas senhas numa conta. No credential stuffing, ele testa pares de usuário e senha vazados de outro site, normalmente em muitas contas, e acerta sem errar a senha da vítima.
Bloquear IP resolve credential stuffing?
Sozinho, não. A OWASP diz que o bloqueio de IP não deve ser a defesa única ou principal, porque o ataque se distribui por muitas origens; pede resposta graduada, temporária e combinada com segundo fator.
Fontes citadas
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, seção 3.2.2 (limitação de taxa), em pages.nist.gov
- OWASP, Credential Stuffing Prevention Cheat Sheet, no repositório oficial