Em resumo
A leaked password protection faz com que o Supabase Auth rejeite as palavras-passe que constam do corpus de fugas do Have I Been Pwned. Está disponível no plano Pro e superiores. A 23 de outubro de 2026, esse corpus continha password123 2 266 543 vezes, e o meu Supabase Auth local, com as definições por omissão, aceitou-a no registo. Não avalia a força: Lovable2026! apareceu 0 vezes. Ligue-a onde puder e defina um comprimento mínimo maior, em qualquer caso.
O meu verificador de segurança do Supabase gratuito lê as definições de Auth de um projeto, e “Proteção contra palavras-passe divulgadas desativada” é uma das suas regras, a par de “Comprimento mínimo de palavra-passe curto”. Esta nota explica o que a definição realmente verifica, com números que tirei do mesmo serviço que ela usa.
O que é a leaked password protection no Supabase?
É uma das definições de palavra-passe nas definições de Auth do seu projeto no Dashboard. Quando está ligada, o Supabase Auth verifica cada palavra-passe nova no serviço Pwned Passwords do Have I Been Pwned e rejeita as que lá constam. O guia de segurança das palavras-passe do Supabase lista-a a par do comprimento mínimo e dos caracteres exigidos, e indica que está disponível no plano Pro e superiores.
A verificação nunca envia a palavra-passe. O Pwned Passwords usa uma consulta de intervalo com k-anonimato: o cliente calcula o hash SHA-1 da palavra-passe, envia só os 5 primeiros caracteres do hash e compara localmente os sufixos devolvidos.
Quantas vezes as palavras-passe comuns surgem em fugas?
Executei eu mesmo essa consulta de intervalo a 23 de outubro de 2026, com algumas palavras-passe que vejo em contas de teste e em dados semente gerados por IA:
| Palavra-passe | Vezes vista em fugas |
|---|---|
123456 |
210 461 208 |
qwerty123 |
13 871 714 |
password123 |
2 266 543 |
Password1! |
584 516 |
Welcome1! |
239 099 |
Summer2026! |
45 |
supabase123 |
7 |
Lovable2026! |
0 |
O 123456 ficou fora do gráfico porque achataria todas as outras barras. As três últimas linhas são o essencial: uma palavra-passe pode estar ausente de todas as fugas e ainda assim ser fácil de adivinhar. A leaked password protection trava o credential stuffing com palavras-passe conhecidas. Não mede a força.
O que acontece sem ela?
Numa stack local do Supabase (CLI 2.109.1, Auth v2.192.0) com as definições por omissão, registei um utilizador de teste com password123. O Auth respondeu 200 e criou o utilizador. A única coisa que recusou foi uma palavra-passe de 5 caracteres, com 422 weak_password e o motivo length, porque o mínimo local por omissão é de 6 caracteres.
Por isso, sem a definição, nada se interpõe entre um utilizador e uma palavra-passe que já se divulgou milhões de vezes, para além da regra do comprimento.
O que deve definir?
- No Pro e superiores: ligue a leaked password protection. Os utilizadores existentes continuam a iniciar sessão, e o guia diz que aqueles cuja palavra-passe não cumpra os novos requisitos recebem um
WeakPasswordErrorque explica o motivo, por isso pode pedir-lhes que a mudem. - Em todos os planos: aumente o comprimento mínimo. O guia classifica qualquer valor abaixo de 8 caracteres como não recomendado; a regra do meu verificador sugere 12 ou mais.
- Exija classes de caracteres só se os seus utilizadores o aguentarem; o comprimento faz mais do que um símbolo obrigatório.
- Junte MFA às contas que importam, e exija a palavra-passe atual ou um nonce de reautenticação para a alterar; ambos constam do mesmo guia.
A leaked password protection é uma de várias definições de Auth que só existem na configuração do projeto alojado, não no seu repositório. O resto do que verifico numa app Supabase, do RLS aos limites de pedidos no início de sessão, está na minha lista de segurança para apps Lovable, e o que o Supabase cobre face ao que é seu está em o Supabase é seguro?.