TL;DR
Leaked password protection saa Supabase Authin hylkäämään salasanat, jotka esiintyvät Have I Been Pwnedin vuotokorpuksessa. Se on saatavilla Pro-paketista ylöspäin. 23. lokakuuta 2026 korpuksessa oli password123 2 266 543 kertaa, ja paikallinen Supabase Authini oletusasetuksilla hyväksyi sen rekisteröitymisessä. Se ei arvioi vahvuutta: Lovable2026! esiintyi 0 kertaa. Ota se käyttöön, missä voit, ja aseta pidempi vähimmäispituus joka tapauksessa.
Ilmainen Supabase-tietoturvatarkistukseni lukee projektin Auth-asetukset, ja “Vuotaneiden salasanojen suojaus pois päältä” on yksi sen säännöistä, “Lyhyt salasanan vähimmäispituus” -säännön vieressä. Tässä muistiinpanossa selitän, mitä asetus oikeasti tarkistaa, ja kerron luvut, jotka hain samasta palvelusta, jota se käyttää.
Mikä leaked password protection on Supabasessa?
Se on yksi projektisi Auth-asetusten salasanaasetuksista Dashboardissa. Kun se on päällä, Supabase Auth tarkistaa jokaisen uuden salasanan Have I Been Pwnedin Pwned Passwords -palvelusta ja hylkää ne, jotka löytyvät sieltä. Supabasen salasanaturvallisuusopas listaa sen vähimmäispituuden ja vaadittujen merkkien rinnalla ja toteaa, että se on saatavilla Pro-paketista ylöspäin.
Tarkistus ei koskaan lähetä salasanaa. Pwned Passwords käyttää k-anonymity range -kyselyä: asiakas laskee salasanasta SHA-1-tiivisteen, lähettää vain tiivisteen viisi ensimmäistä merkkiä ja vertaa palautettuja loppuosia paikallisesti.
Kuinka usein yleiset salasanat esiintyvät vuodoissa?
Ajoin saman range-kyselyn itse 23. lokakuuta 2026 muutamalle salasanalle, joita näen testitileillä ja tekoälyn tuottamassa seed-datassa:
| Salasana | Kertaa nähty vuodoissa |
|---|---|
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 jätetty kaaviosta pois, koska se litistäisi kaikki muut palkit. Kolme viimeistä riviä ovat pointti: salasana voi puuttua kaikista vuodoista ja olla silti helppo arvata. Leaked password protection estää credential stuffing -hyökkäykset tunnetuilla salasanoilla. Se ei mittaa vahvuutta.
Mitä tapahtuu ilman sitä?
Paikallisella Supabase-stackilla (CLI 2.109.1, Auth v2.192.0) oletusasetuksilla rekisteröin testikäyttäjän salasanalla password123. Auth vastasi 200 ja loi käyttäjän. Ainoa, minkä se hylkäsi, oli 5 merkin salasana, vastauksella 422 weak_password ja syyllä length, koska paikallinen oletus vähimmäispituudelle on 6 merkkiä.
Ilman asetusta käyttäjän ja miljoonia kertoja vuotaneen salasanan välillä ei siis ole mitään pituussääntöä lukuun ottamatta.
Mitä kannattaa asettaa?
- Pro-paketissa ja ylöspäin: ota leaked password protection käyttöön. Olemassa olevat käyttäjät voivat edelleen kirjautua sisään, ja oppaan mukaan ne, joiden salasana ei täytä uusia vaatimuksia, saavat
WeakPasswordError-virheen, joka selittää syyn, joten voit pyytää heitä vaihtamaan sen. - Kaikissa paketeissa: nosta vähimmäispituutta. Opas kutsuu alle 8 merkkiä ei-suositelluksi; tarkistukseni sääntö ehdottaa 12:ta tai enemmän.
- Vaadi merkkiluokkia vain, jos käyttäjäsi sietävät sen; pituus tekee enemmän kuin vaadittu erikoismerkki.
- Lisää MFA tileille, joilla on merkitystä, ja vaadi nykyinen salasana tai uudelleentunnistautumisen nonce salasanan vaihtoon; molemmat ovat samassa oppaassa.
Leaked password protection on yksi niistä Auth-asetuksista, jotka ovat vain hostatun projektin konfiguraatiossa, eivät repossasi. Loput siitä, mitä tarkistan Supabase-sovelluksesta, RLS:stä sisäänkirjautumisen nopeusrajoituksiin, löytyy Lovable-sovelluksen tietoturvatarkistuslistastani, ja se, mitä Supabase kattaa ja mikä on sinun, selviää artikkelista onko Supabase turvallinen.