---
title: "Supabase leaked password protection: o que bloqueia"
description: "O que a leaked password protection do Supabase verifica, porque pede o plano Pro, quantas vezes as palavras-passe comuns surgem em fugas e o que definir."
url: "https://madsalt.tech/pt/notes/supabase-leaked-password-protection/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/pt/about/"
language: "pt"
published: 2026-10-30
---

# Supabase leaked password protection: o que bloqueia

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](https://madsalt.tech/pt/tools/supabase-security-check/) 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](https://haveibeenpwned.com/Passwords) do Have I Been Pwned e rejeita as que lá constam. O [guia de segurança das palavras-passe](https://supabase.com/docs/guides/auth/password-security) 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:

![Quantas vezes cada palavra-passe aparece em fugas conhecidas. API de intervalos do Pwned Passwords, 23 de outubro de 2026. qwerty123: 13 871 714; password123: 2 266 543; Password1!: 584 516; Welcome1!: 239 099; Summer2026!: 45; supabase123: 7; Lovable2026!: 0.](https://madsalt.tech/charts/pt/supabase-leaked-password-protection.svg)

*Fonte: API de intervalos do Pwned Passwords, do Have I Been Pwned, consultada a 23 de outubro de 2026.*

| 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?

1. **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 `WeakPasswordError` que explica o motivo, por isso pode pedir-lhes que a mudem.
2. **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.
3. **Exija classes de caracteres** só se os seus utilizadores o aguentarem; o comprimento faz mais do que um símbolo obrigatório.
4. **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](https://madsalt.tech/pt/blog/lovable-app-security-checklist/), e o que o Supabase cobre face ao que é seu está em [o Supabase é seguro?](https://madsalt.tech/pt/blog/is-supabase-secure/).