Kurz gesagt
Leaked password protection lässt Supabase Auth Passwörter ablehnen, die im Datenbestand von Have I Been Pwned vorkommen. Es ist im Pro-Tarif und darüber verfügbar. Am 23. Oktober 2026 enthielt dieser Bestand password123 2.266.543-mal, und mein lokales Supabase Auth mit Standardeinstellungen akzeptierte es bei der Registrierung. Es beurteilt keine Stärke: Lovable2026! kam 0-mal vor. Schalten Sie es ein, wo Sie können, und setzen Sie in jedem Fall eine längere Mindestlänge.
Mein kostenloser Supabase-Sicherheitscheck liest die Auth-Einstellungen eines Projekts, und “Schutz vor geleakten Passwörtern aus” ist eine seiner Regeln, neben “Kurze Mindestlänge für Passwörter”. Diese Notiz erklärt, was die Einstellung tatsächlich prüft, mit Zahlen, die ich vom selben Dienst geholt habe, den sie nutzt.
Was ist leaked password protection in Supabase?
Es ist eine der Passwort-Einstellungen in den Auth-Einstellungen Ihres Projekts im Dashboard. Ist sie an, prüft Supabase Auth jedes neue Passwort gegen den Dienst Pwned Passwords von Have I Been Pwned und lehnt die ab, die dort gefunden werden. Supabases Leitfaden zur Passwortsicherheit führt sie neben Mindestlänge und erforderlichen Zeichen auf und vermerkt, dass sie im Pro-Tarif und darüber verfügbar ist.
Die Prüfung sendet das Passwort nie. Pwned Passwords nutzt eine k-Anonymity-Bereichsabfrage: Der Client hasht das Passwort mit SHA-1, sendet nur die ersten 5 Zeichen des Hashs und vergleicht die zurückgegebenen Suffixe lokal.
Wie oft tauchen gängige Passwörter in Datenlecks auf?
Dieselbe Bereichsabfrage habe ich am 23. Oktober 2026 selbst ausgeführt, für ein paar Passwörter, die ich in Testkonten und KI-generierten Seed-Daten sehe:
| Passwort | Häufigkeit in Datenlecks |
|---|---|
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 fehlt im Diagramm, weil es alle anderen Balken plattdrücken würde. Die letzten drei Zeilen sind der Punkt: Ein Passwort kann in keinem Datenleck vorkommen und trotzdem leicht zu erraten sein. Leaked password protection stoppt Credential Stuffing mit bekannten Passwörtern. Es misst keine Stärke.
Was passiert ohne sie?
Auf einem lokalen Supabase-Stack (CLI 2.109.1, Auth v2.192.0) mit Standardeinstellungen habe ich einen Testnutzer mit password123 registriert. Auth antwortete 200 und legte den Nutzer an. Abgelehnt wurde nur ein Passwort mit 5 Zeichen, mit 422 weak_password und dem Grund length, weil die lokale Standard-Mindestlänge 6 Zeichen beträgt.
Ohne die Einstellung steht also nichts zwischen einem Nutzer und einem Passwort, das millionenfach geleakt ist, außer der Längenregel.
Was sollten Sie setzen?
- Ab Pro: Schalten Sie leaked password protection ein. Bestehende Nutzer melden sich weiter an, und laut Leitfaden bekommen die, deren Passwort die neuen Anforderungen nicht erfüllt, einen
WeakPasswordError, der den Grund nennt, sodass Sie sie zum Ändern auffordern können. - In jedem Tarif: Erhöhen Sie die Mindestlänge. Der Leitfaden nennt alles unter 8 Zeichen nicht empfehlenswert; die Regel meines Checks schlägt 12 oder mehr vor.
- Verlangen Sie Zeichenklassen nur, wenn Ihre Nutzer damit leben können; Länge bringt mehr als ein Pflichtsymbol.
- Fügen Sie MFA hinzu für Konten, die zählen, und verlangen Sie das aktuelle Passwort oder einen Reauthentication-Nonce, um ein Passwort zu ändern; beides steht im selben Leitfaden.
Leaked password protection ist eine von mehreren Auth-Einstellungen, die nur in der Konfiguration des gehosteten Projekts existieren, nicht in Ihrem Repo. Alles Weitere, was ich bei einer Supabase-App prüfe, von RLS bis zu Rate Limits beim Login, steht in meiner Sicherheits-Checkliste für Lovable-Apps, und was Supabase abdeckt und was Ihre Sache ist, in Wie sicher ist Supabase.