TL;DR
Leaked password protection způsobí, že Supabase Auth odmítne hesla, která se objevují v databázi úniků Have I Been Pwned. Je k dispozici od tarifu Pro. K 23. říjnu 2026 obsahovala tato databáze password123 2 266 543krát a můj lokální Supabase Auth s výchozím nastavením ho při registraci přijal. Sílu hesla neposuzuje: Lovable2026! se objevilo 0krát. Zapněte ho, kde můžete, a nastavte delší minimální délku tak či tak.
Můj bezplatný bezpečnostní checker pro Supabase čte nastavení Auth projektu a „Ochrana před uniklými hesly vypnutá“ je jedno z jeho pravidel, vedle „Krátká minimální délka hesla“. Tato poznámka vysvětluje, co nastavení skutečně kontroluje, s čísly, která jsem stáhl ze stejné služby, kterou používá.
Co je leaked password protection v Supabase?
Je to jedno z nastavení hesel v nastavení Auth vašeho projektu v Dashboardu. Když je zapnuté, Supabase Auth kontroluje každé nové heslo proti službě Pwned Passwords od Have I Been Pwned a hesla, která tam najde, odmítne. Průvodce zabezpečením hesel od Supabase ho uvádí vedle minimální délky a požadovaných znaků a poznamenává, že je k dispozici od tarifu Pro.
Kontrola heslo nikdy neodešle. Pwned Passwords používá dotaz na rozsah s k-anonymitou: klient zahashuje heslo pomocí SHA-1, odešle jen prvních 5 znaků hashe a vrácené přípony porovná lokálně.
Jak často se běžná hesla objevují v únicích?
Stejný dotaz na rozsah jsem pustil sám 23. října 2026 pro několik hesel, která vídám v testovacích účtech a ve seed datech generovaných AI:
| Heslo | Kolikrát viděno v únicích |
|---|---|
123456 |
210 461 208 |
qwerty123 |
13 871 714 |
password123 |
2 266 543 |
Password1! |
584 516 |
Welcome1! |
239 099 |
Summer2026! |
45 |
supabase123 |
7 |
Lovable2026! |
0 |
123456 je z grafu vynecháno, protože by zploštilo všechny ostatní sloupce. Poslední tři řádky jsou podstatou: heslo může chybět ve všech únicích a být přesto snadno uhodnutelné. Leaked password protection zastaví credential stuffing se známými hesly. Sílu neměří.
Co se stane bez něj?
Na lokálním Supabase (CLI 2.109.1, Auth v2.192.0) s výchozím nastavením jsem zaregistroval testovacího uživatele s password123. Auth odpověděl 200 a uživatele vytvořil. Jediné, co odmítl, bylo 5znakové heslo, s 422 weak_password a důvodem length, protože lokální výchozí minimum je 6 znaků.
Bez tohoto nastavení tedy nestojí nic mezi uživatelem a heslem, které uniklo milionykrát, kromě pravidla o délce.
Co nastavit?
- Na Pro a výše: zapněte leaked password protection. Stávající uživatelé se přihlašují dál a podle průvodce ti, jejichž heslo nesplňuje nové požadavky, dostanou
WeakPasswordErrors vysvětlením proč, takže je můžete vyzvat ke změně. - Na každém tarifu: zvyšte minimální délku. Průvodce označuje cokoli pod 8 znaků za nedoporučené; pravidlo mého checkeru navrhuje 12 a více.
- Vyžadujte třídy znaků jen pokud s tím vaši uživatelé vydrží; délka dělá víc než povinný symbol.
- Přidejte MFA pro důležité účty a ke změně hesla vyžadujte aktuální heslo nebo reauthentication nonce; obojí je ve stejném průvodci.
Leaked password protection je jedno z několika nastavení Auth, která existují jen v konfiguraci hostovaného projektu, ne ve vašem repozitáři. Zbytek toho, co na aplikaci na Supabase kontroluji, od RLS po limity požadavků na přihlášení, je v mém checklistu zabezpečení Lovable aplikace a to, co Supabase pokrývá a co je vaše, je v článku je Supabase bezpečný.