Kort sagt
Leaked password protection får Supabase Auth att avvisa lösenord som finns i Have I Been Pwned-korpusen över läckor. Det finns på Pro-planen och uppåt. Den 23 oktober 2026 innehöll korpusen password123 2 266 543 gånger, och min lokala Supabase Auth, med standardinställningar, godtog det vid registrering. Det bedömer inte styrka: Lovable2026! förekom 0 gånger. Slå på det där du kan, och ställ in en längre minimilängd oavsett.
Min gratis Supabase-säkerhetskontroll läser ett projekts Auth-inställningar, och “Skydd mot läckta lösenord av” är en av dess regler, vid sidan av “Kort minsta lösenordslängd”. Den här anteckningen förklarar vad inställningen faktiskt kontrollerar, med siffror jag hämtade från samma tjänst som den använder.
Vad är leaked password protection i Supabase?
Det är en av lösenordsinställningarna i projektets Auth-inställningar i Dashboard. När det är på kontrollerar Supabase Auth varje nytt lösenord mot tjänsten Pwned Passwords från Have I Been Pwned och avvisar dem som finns där. Supabases guide om lösenordssäkerhet listar det tillsammans med minsta längd och obligatoriska tecken, och noterar att det finns på Pro-planen och uppåt.
Kontrollen skickar aldrig lösenordet. Pwned Passwords använder en k-anonymity range-fråga: klienten hashar lösenordet med SHA-1, skickar bara de första 5 tecknen i hashen och jämför de returnerade suffixen lokalt.
Hur ofta förekommer vanliga lösenord i läckor?
Jag körde samma range-fråga själv den 23 oktober 2026, för några lösenord jag ser i testkonton och AI-genererad seed-data:
| Lösenord | Gånger sett i läckor |
|---|---|
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 är utelämnat ur diagrammet eftersom det skulle trycka ihop alla andra staplar. De tre sista raderna är poängen: ett lösenord kan saknas i varje läcka och ändå vara lätt att gissa. Leaked password protection stoppar credential stuffing med kända lösenord. Det mäter inte styrka.
Vad händer utan det?
På en lokal Supabase-stack (CLI 2.109.1, Auth v2.192.0) med standardinställningar registrerade jag en testanvändare med password123. Auth svarade 200 och skapade användaren. Det enda den avvisade var ett lösenord på 5 tecken, med 422 weak_password och orsaken length, eftersom den lokala standarden för minimilängd är 6 tecken.
Så utan inställningen står inget mellan en användare och ett lösenord som har läckt miljontals gånger, förutom längdregeln.
Vad bör du ställa in?
- På Pro och uppåt: slå på leaked password protection. Befintliga användare kan fortfarande logga in, och guiden säger att de vars lösenord inte uppfyller nya krav får ett
WeakPasswordErrorsom förklarar varför, så att du kan be dem byta. - På alla planer: höj minimilängden. Guiden kallar allt under 8 tecken inte rekommenderat; regeln i min kontroll föreslår 12 eller mer.
- Kräv teckenklasser bara om dina användare står ut med det; längd gör mer än ett obligatoriskt specialtecken.
- Lägg till MFA för konton som betyder något, och kräv det nuvarande lösenordet eller en reautentiserings-nonce för att byta lösenord; båda finns i samma guide.
Leaked password protection är en av flera Auth-inställningar som bara finns i det hostade projektets konfiguration, inte i ditt repo. Resten av vad jag kontrollerar på en Supabase-app, från RLS till rate limits på inloggning, finns i min säkerhetschecklista för Lovable-appar, och vad Supabase täcker och vad som är ditt finns i är Supabase säkert.