---
title: "Supabase leaked password protection: was es blockt"
description: "Was Supabase leaked password protection prüft, warum es den Pro-Tarif braucht, wie oft gängige Passwörter in Datenlecks auftauchen und was ohne gilt."
url: "https://madsalt.tech/de/notes/supabase-leaked-password-protection/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/de/about/"
language: "de"
published: 2026-10-30
---

# Supabase leaked password protection: was es blockt

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](https://madsalt.tech/de/tools/supabase-security-check/) 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](https://haveibeenpwned.com/Passwords) von Have I Been Pwned und lehnt die ab, die dort gefunden werden. Supabases [Leitfaden zur Passwortsicherheit](https://supabase.com/docs/guides/auth/password-security) 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:

![Wie oft jedes Passwort in bekannten Datenlecks vorkommt. Pwned Passwords Range API, 23. Oktober 2026. qwerty123: 13.871.714; password123: 2.266.543; Password1!: 584.516; Welcome1!: 239.099; Summer2026!: 45; supabase123: 7; Lovable2026!: 0.](https://madsalt.tech/charts/de/supabase-leaked-password-protection.svg)

*Quelle: Have I Been Pwned, Pwned Passwords Range API, abgefragt am 23. Oktober 2026.*

| 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?

1. **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.
2. **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.
3. **Verlangen Sie Zeichenklassen** nur, wenn Ihre Nutzer damit leben können; Länge bringt mehr als ein Pflichtsymbol.
4. **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](https://madsalt.tech/de/blog/lovable-app-security-checklist/), und was Supabase abdeckt und was Ihre Sache ist, in [Wie sicher ist Supabase](https://madsalt.tech/de/blog/is-supabase-secure/).