Quem reutiliza a mesma senha em vários serviços entrega a conta de todos eles no dia em que um só vaza, e o atacante não precisa adivinhar nada: ele testa a lista pronta. A resposta curta: a senha nova é comparada com uma lista de senhas comuns e vazadas no cadastro, na troca e no reset, como manda a NIST SP 800-63B-4, e a senha certa que aparece em vazamento no login vira troca obrigatória, porque a mesma norma manda forçar a troca quando há evidência de comprometimento.
Em resumo
- A NIST SP 800-63B-4 (seção 3.1.1.2) manda comparar toda senha nova com uma lista de senhas comuns, esperadas ou comprometidas.
- A comparação é da senha inteira, e a recusa diz o motivo para a pessoa escolher outra.
- Trocar a senha por calendário é proibido; trocar porque ela vazou é obrigatório.
- O OWASP ASVS 5.0 separa duas checagens: a lista das senhas mais comuns (V6.2.4) e o conjunto de senhas vazadas (V6.2.12).
- No login, a senha só é declarada vazada depois de provada certa, para o aviso não virar oráculo para o atacante.
O que a norma manda checar
A revisão 4 da publicação da NIST sobre autenticação, a SP 800-63B-4, trata a lista de bloqueio como requisito, não como boa prática. A regra está na seção 3.1.1.2, a dos verificadores de senha.
When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords. The entire password SHALL be subject to comparison, not substrings or words that might be contained therein.
A mesma seção dá três exemplos do que entra na lista: senhas tiradas de vazamentos anteriores, palavras de dicionário e palavras do contexto, como o nome do serviço, o nome de usuário e as variações deles. E manda que, quando a senha cai na lista, a pessoa escolha outra e receba o motivo da recusa. Nada de "senha inválida" sem explicação: quem não sabe por que foi recusado tenta a mesma senha com um número no fim.
O OWASP Application Security Verification Standard, na versão 5.0, quebra o mesmo assunto em dois requisitos do capítulo V6: o 6.2.4 pede a checagem contra pelo menos as 3.000 senhas mais comuns que passam na regra de tamanho, e o 6.2.12 pede a checagem contra um conjunto de senhas vazadas. São duas listas com papéis diferentes. A primeira é pequena, fica local e pega a senha óbvia sem depender de nada externo. A segunda é enorme, muda toda semana e pega a senha que parece forte mas já está nas mãos de quem ataca.
Quando checar: os quatro momentos
| Momento | O que a norma pede | O que acontece quando cai na lista |
|---|---|---|
| Cadastro | Comparar a senha proposta (800-63B-4, 3.1.1.2) | A pessoa escolhe outra e vê o motivo |
| Troca de senha | Comparar a senha nova (800-63B-4, 3.1.1.2) | A troca não conclui com a senha vazada |
| Reset por esquecimento | É uma troca: a mesma comparação | O reset pede outra senha |
| Login com a senha certa | Forçar a troca quando há evidência de comprometimento (800-63B-4, 3.1.1.2) | O acesso segue para a troca obrigatória, não para a conta |
As três primeiras linhas são a regra literal. A quarta é a que mais falta na prática. A senha cadastrada há dois anos estava limpa no dia do cadastro e pode ter vazado ontem em outro serviço. A norma cobre esse caso na mesma seção, com duas frases em sequência: os verificadores "SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised." A senha que aparece num vazamento público é essa evidência.
Atenção
A ordem no login importa. Se o sistema avisa "esta senha vazou" antes de saber se ela é a senha da conta, o atacante ganha um oráculo: testa a lista e descobre quais senhas o serviço reconhece como vazadas. O aviso só aparece depois de a senha ser provada certa, e o caminho seguinte é a troca, nunca a entrada direta.
Como consultar sem entregar a senha
Mandar a senha da pessoa, ou o hash completo dela, para um serviço de consulta de vazamentos seria criar o vazamento que se quer evitar. O método que se firmou é a consulta por faixa de hash: o sistema calcula o hash da senha, envia só um prefixo curto dele e recebe de volta todos os sufixos conhecidos que começam com aquele prefixo. A comparação final acontece do lado de quem consulta. O serviço consultado nunca vê a senha nem sabe qual dos sufixos da resposta interessava.
Dois cuidados fecham a consulta. O primeiro é o tamanho da resposta: sem preenchimento, o número de linhas devolvidas pode dizer algo sobre o prefixo, e por isso as respostas desse tipo de serviço costumam vir completadas até um tamanho uniforme. O segundo é a falha: se a consulta externa não responde, a lista local continua valendo e o cadastro não para. Recusar todo cadastro porque um serviço externo caiu é trocar um risco por outro, e o comportamento escolhido fica registrado com métrica para ninguém descobrir a falha meses depois.
Nota
A lista de bloqueio não substitui o limite de tentativas. A própria NIST lembra, na mesma seção, que a lista defende contra força bruta justamente porque as tentativas sem sucesso são limitadas. As duas defesas trabalham juntas, e o ataque que testa senhas vazadas em muitas contas ao mesmo tempo está no artigo sobre tomada de conta.
O que não fazer no lugar da lista
A lista de bloqueio costuma ser trocada por regras que parecem mais rigorosas e protegem menos. A NIST SP 800-63B-4 proíbe duas delas na mesma seção 3.1.1.2: regra de composição ("SHALL NOT impose other composition rules", como exigir mistura de tipos de caractere) e troca periódica. A composição obrigatória leva a senhas previsíveis, como a palavra com maiúscula no início e um número com símbolo no fim, que estão nas listas de vazamento justamente por isso. A troca periódica leva à senha anterior com o número aumentado em um.
O que a norma pede no lugar é tamanho. A senha usada como fator único tem no mínimo 15 caracteres, e a senha que só vale junto com um segundo fator pode ter no mínimo 8. O sistema deve aceitar pelo menos 64 caracteres e todos os caracteres imprimíveis, inclusive o espaço, para que a frase longa caiba. Com tamanho, lista de bloqueio e segundo fator quando o login é arriscado, a senha deixa de ser o elo que decide sozinho. O segundo fator e quando pedi-lo estão no artigo sobre TOTP e aplicativo autenticador.
Perguntas frequentes
Preciso obrigar o usuário a trocar a senha a cada 90 dias?
Não. A NIST SP 800-63B-4, seção 3.1.1.2, proíbe a troca periódica obrigatória. A troca passa a ser obrigatória quando há evidência de que a senha foi comprometida, como o aparecimento dela num vazamento.
Checar a senha num serviço de vazamentos expõe a senha?
Não quando a consulta é por faixa de hash: só um prefixo curto do hash sai do sistema, a resposta traz todos os sufixos daquele prefixo e a comparação final é local. O serviço consultado não vê a senha nem o hash inteiro.
O que mostrar para a pessoa quando a senha é recusada?
O motivo. A NIST SP 800-63B-4 manda informar a razão da recusa quando a senha cai na lista de bloqueio, para a pessoa escolher outra senha de verdade e não a mesma com um caractere a mais.
A senha certa e vazada deve bloquear o login?
Ela não deve abrir a conta direto. O caminho é provar a senha, informar que ela apareceu em vazamento e exigir a troca antes do acesso, o que atende à regra de forçar a troca diante de evidência de comprometimento.
Fontes citadas
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, seção 3.1.1 (senhas) e 3.1.1.2 (verificadores de senha), em pages.nist.gov
- OWASP, Application Security Verification Standard 5.0.0, capítulo V6, requisitos 6.2.4 e 6.2.12, no repositório oficial