Lühidalt
Leaked password protection paneb Supabase Auth’i tagasi lükkama paroole, mis esinevad Have I Been Pwned lekete andmekogus. See on saadaval Pro plaanis ja kõrgemates. 23. oktoobril 2026 oli selles andmekogus password123 2 266 543 korda ja minu kohalik Supabase Auth vaikeseadetega võttis selle registreerimisel vastu. See ei hinda tugevust: Lovable2026! esines 0 korda. Lülitage see sisse, kus saate, ja seadke pikem minimaalne pikkus igal juhul.
Minu tasuta Supabase’i turvakontroll loeb projekti Auth-seadeid ja “Lekkinud paroolide kaitse väljas” on üks selle reegleid, “Lühike minimaalne paroolipikkus” kõrval. See märkus selgitab, mida seade tegelikult kontrollib, numbritega, mille tõmbasin samast teenusest, mida see kasutab.
Mis on leaked password protection Supabase’is?
See on üks paroolisätetest teie projekti Auth-seadetes Dashboardis. Kui see on sees, kontrollib Supabase Auth iga uut parooli Have I Been Pwned teenuse Pwned Passwords vastu ja lükkab sealt leitud paroolid tagasi. Supabase’i password security guide loetleb selle koos minimaalse pikkuse ja nõutud märkidega ning märgib, et see on saadaval Pro plaanis ja kõrgemates.
Kontroll ei saada parooli kunagi. Pwned Passwords kasutab k-anonymity vahemikupäringut: klient räsib parooli SHA-1-ga, saadab ainult räsi esimesed 5 märki ja võrdleb tagastatud järelliiteid lokaalselt.
Kui sageli esinevad levinud paroolid lekete andmekogudes?
Tegin sama vahemikupäringu ise 23. oktoobril 2026, mõne parooli jaoks, mida näen testkontodes ja AI-genereeritud seemneandmetes:
| Parool | Mitu korda lekkeis nähtud |
|---|---|
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 on diagrammilt välja jäetud, sest see lamendaks kõik teised tulbad. Viimased kolm rida on mõte: parool võib puududa igast lekkest ja olla siiski lihtne ära arvata. Leaked password protection peatab credential stuffing’u teadaolevate paroolidega. See ei mõõda tugevust.
Mis juhtub ilma selleta?
Kohalikul Supabase’i pinul (CLI 2.109.1, Auth v2.192.0) vaikeseadetega registreerisin testkasutaja parooliga password123. Auth vastas 200 ja lõi kasutaja. Ainus, mida see tagasi lükkas, oli 5-märgiline parool, vastusega 422 weak_password ja põhjusega length, sest kohalik vaikeminimum on 6 märki.
Seega, ilma selle seadeta ei seisa kasutaja ja miljoneid kordi lekkinud parooli vahel midagi peale pikkusereegli.
Mida peaks seadma?
- Pro plaanis ja kõrgemates: lülitage leaked password protection sisse. Olemasolevad kasutajad logivad edasi sisse ja juhendi järgi saavad need, kelle parool ei vasta uutele nõuetele,
WeakPasswordError-i, mis selgitab põhjust, nii et saate neil paluda parooli vahetada. - Igas plaanis: tõstke minimaalset pikkust. Juhend nimetab alla 8 märgi pikkust mittesoovitatavaks; minu kontrolli reegel soovitab 12 või rohkem.
- Nõudke märgiklasse ainult siis, kui teie kasutajad sellega elada saavad; pikkus annab rohkem kui kohustuslik sümbol.
- Lisage MFA olulistele kontodele ning nõudke parooli vahetamiseks praegust parooli või uuesti autentimise nonce’i; mõlemad on samas juhendis.
Leaked password protection on üks mitmest Auth-seadest, mis eksisteerivad ainult hostitud projekti konfiguratsioonis, mitte teie repos. Ülejäänu, mida Supabase’i rakenduses kontrollin, RLS-ist sisselogimise päringupiiranguteni, on minu Lovable’i rakenduse turvanimekirjas ning mida Supabase katab ja mis on teie, on artiklis kas Supabase on turvaline.