TL;DR
Leaked password protection spôsobí, že Supabase Auth odmietne heslá, ktoré sa objavujú v databáze únikov Have I Been Pwned. Je k dispozícii od tarifu Pro. K 23. októbru 2026 obsahovala táto databáza password123 2 266 543-krát a môj lokálny Supabase Auth s predvoleným nastavením ho pri registrácii prijal. Silu hesla neposudzuje: Lovable2026! sa objavilo 0-krát. Zapnite ho, kde môžete, a nastavte dlhšiu minimálnu dĺžku tak či tak.
Môj bezplatný bezpečnostný checker pre Supabase číta nastavenia Auth projektu a „Ochrana pred uniknutými heslami vypnutá“ je jedno z jeho pravidiel, popri „Krátka minimálna dĺžka hesla“. Táto poznámka vysvetľuje, čo nastavenie skutočne kontroluje, s číslami, ktoré som stiahol z tej istej služby, ktorú používa.
Čo je leaked password protection v Supabase?
Je to jedno z nastavení hesiel v nastaveniach Auth vášho projektu v Dashboarde. Keď je zapnuté, Supabase Auth kontroluje každé nové heslo voči službe Pwned Passwords od Have I Been Pwned a heslá, ktoré tam nájde, odmietne. Sprievodca zabezpečením hesiel od Supabase ho uvádza vedľa minimálnej dĺžky a požadovaných znakov a poznamenáva, že je k dispozícii od tarifu Pro.
Kontrola heslo nikdy neodošle. Pwned Passwords používa dopyt na rozsah s k-anonymitou: klient zahashuje heslo pomocou SHA-1, odošle len prvých 5 znakov hashu a vrátené prípony porovná lokálne.
Ako často sa bežné heslá objavujú v únikoch?
Ten istý dopyt na rozsah som spustil sám 23. októbra 2026 pre niekoľko hesiel, ktoré vídam v testovacích účtoch a v seed dátach generovaných AI:
| Heslo | Koľkokrát videné v únikoch |
|---|---|
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 vynechané, pretože by sploštilo všetky ostatné stĺpce. Posledné tri riadky sú podstatou: heslo môže chýbať vo všetkých únikoch a byť napriek tomu ľahko uhádnuteľné. Leaked password protection zastaví credential stuffing so známymi heslami. Silu nemeria.
Čo sa stane bez neho?
Na lokálnom Supabase (CLI 2.109.1, Auth v2.192.0) s predvoleným nastavením som zaregistroval testovacieho používateľa s password123. Auth odpovedal 200 a používateľa vytvoril. Jediné, čo odmietol, bolo 5-znakové heslo, s 422 weak_password a dôvodom length, pretože lokálne predvolené minimum je 6 znakov.
Bez tohto nastavenia teda nestojí nič medzi používateľom a heslom, ktoré uniklo miliónkrát, okrem pravidla o dĺžke.
Čo nastaviť?
- Na Pro a vyššie: zapnite leaked password protection. Existujúci používatelia sa prihlasujú ďalej a podľa sprievodcu tí, ktorých heslo nespĺňa nové požiadavky, dostanú
WeakPasswordErrors vysvetlením prečo, takže ich môžete vyzvať na zmenu. - Na každom tarife: zvýšte minimálnu dĺžku. Sprievodca označuje čokoľvek pod 8 znakov za neodporúčané; pravidlo môjho checkera navrhuje 12 a viac.
- Vyžadujte triedy znakov len ak to vaši používatelia zvládnu; dĺžka robí viac než povinný symbol.
- Pridajte MFA pre dôležité účty a na zmenu hesla vyžadujte aktuálne heslo alebo reauthentication nonce; oboje je v tom istom sprievodcovi.
Leaked password protection je jedno z niekoľkých nastavení Auth, ktoré existujú len v konfigurácii hostovaného projektu, nie vo vašom repozitári. Zvyšok toho, čo na aplikácii na Supabase kontrolujem, od RLS po limity požiadaviek na prihlásenie, je v mojom checkliste bezpečnosti aplikácie z Lovable a to, čo Supabase pokrýva a čo je vaše, je v článku je Supabase bezpečný.