TL;DR
Leaked password protection får Supabase Auth til å avvise passord som finnes i Have I Been Pwned-korpuset over lekkasjer. Det er tilgjengelig fra Pro-planen og oppover. Den 23. oktober 2026 inneholdt korpuset password123 2 266 543 ganger, og min lokale Supabase Auth, med standardinnstillinger, godtok det ved registrering. Det vurderer ikke styrke: Lovable2026! forekom 0 ganger. Slå det på der du kan, og sett en lengre minstelengde uansett.
Min gratis Supabase-sikkerhetssjekk leser Auth-innstillingene i et prosjekt, og “Vern mot lekkede passord av” er en av reglene, ved siden av “Kort minste passordlengde”. Dette notatet forklarer hva innstillingen faktisk sjekker, med tall jeg hentet fra den samme tjenesten den bruker.
Hva er leaked password protection i Supabase?
Det er en av passordinnstillingene i prosjektets Auth-innstillinger i Dashboard. Når det er på, sjekker Supabase Auth hvert nytt passord mot tjenesten Pwned Passwords fra Have I Been Pwned og avviser dem som finnes der. Supabases guide om passordsikkerhet lister det sammen med minste lengde og påkrevde tegn, og merker at det er tilgjengelig fra Pro-planen og oppover.
Sjekken sender aldri passordet. Pwned Passwords bruker en k-anonymity range-spørring: klienten hasher passordet med SHA-1, sender bare de første 5 tegnene i hashen og sammenligner de returnerte suffiksene lokalt.
Hvor ofte finnes vanlige passord i lekkasjer?
Jeg kjørte den samme range-spørringen selv 23. oktober 2026, for noen passord jeg ser i testkontoer og AI-genererte seed-data:
| Passord | Ganger sett i lekkasjer |
|---|---|
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 er utelatt fra diagrammet fordi det ville flatet ut alle de andre søylene. De tre siste radene er poenget: et passord kan mangle i alle lekkasjer og likevel være lett å gjette. Leaked password protection stopper credential stuffing med kjente passord. Det måler ikke styrke.
Hva skjer uten det?
På en lokal Supabase-stack (CLI 2.109.1, Auth v2.192.0) med standardinnstillinger registrerte jeg en testbruker med password123. Auth svarte 200 og opprettet brukeren. Det eneste den avviste, var et passord på 5 tegn, med 422 weak_password og årsaken length, fordi den lokale standarden for minstelengde er 6 tegn.
Så uten innstillingen står ingenting mellom en bruker og et passord som har lekket millioner av ganger, bortsett fra lengderegelen.
Hva bør du sette?
- På Pro og oppover: slå på leaked password protection. Eksisterende brukere kan fortsatt logge inn, og guiden sier at de hvis passord ikke oppfyller nye krav, får en
WeakPasswordErrorsom forklarer hvorfor, så du kan be dem bytte det. - På alle planer: øk minstelengden. Guiden kaller alt under 8 tegn ikke anbefalt; regelen i sjekken min foreslår 12 eller mer.
- Krev tegnklasser bare hvis brukerne dine kan leve med det; lengde gjør mer enn et påkrevd symbol.
- Legg til MFA for kontoer som betyr noe, og krev det nåværende passordet eller en reautentiserings-nonce for å bytte passord; begge står i den samme guiden.
Leaked password protection er én av flere Auth-innstillinger som bare finnes i konfigurasjonen til det hostede prosjektet, ikke i repoet ditt. Resten av det jeg sjekker på en Supabase-app, fra RLS til rate limits på innlogging, står i sikkerhetsjekklisten min for Lovable-apper, og hva Supabase dekker og hva som er ditt, står i er Supabase trygt.