Blocklist-Propagierung: Wie ein bestätigter Missbrauchsfall das gesamte Netzwerk lahmlegt (DE)

Es gibt einen spezifischen Moment, in dem die meisten Missbrauchsprogramme an Wert verlieren: der Moment, nachdem man gewonnen hat.

Ihre Traffic-Schicht markiert ein Konto. Ein Analyst untersucht. Die Beweise sind solide, der Fall ist bestätigt, das Konto wird gesperrt. Und Stunden später ist derselbe Betreiber mit neuen Konten wieder da, weil Ihre Durchsetzung nur eine Zeile in einer Benutzertabelle betroffen hat.

Anthropic beschrieb genau diese Dynamik in seinem Bericht vom Februar 2026 über Distillationskampagnen – ein Proxy-Netzwerk, das „gleichzeitig mehr als 20.000 betrügerische Konten verwaltete“ und diese ersetzte, sobald sie entfernt wurden. Die Entfernung war nicht der Engpass. Die Regeneration war billiger als die Entfernung.

Die Lösung besteht darin, die Durchsetzung auf Identifikatoren statt auf Konten zu beziehen. Die Lists API von Didit basiert auf einem Mechanismus, der dies in einem einzigen Aufruf erledigt.

Wichtige Erkenntnisse

• Das Blocklisting mit reference_session_id lässt Didit den richtigen Wert automatisch aus der Sitzung extrahieren – Gesicht, Dokument, Telefon, E-Mail, IP oder Gerät –, das zugrunde liegende Modell als blocklistet markieren und den Eintrag mit der Quellsitzung verknüpfen.
• 12 Eintragstypen: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• Blocklisten sind systemerstellt, pro Eintragstyp einmalig und unveränderlich. Sie können sie nicht erstellen, was die Durchsetzung einheitlich macht.
• Einträge werden sofort zur Verifizierungszeit wirksam. Das Löschen eines Eintrags hebt die Blockierung der Übereinstimmung auf.
• ip_address akzeptiert einen CIDR-Bereich, sodass Sie die Infrastruktur und nicht eine einzelne Adresse blocklisten können.
• Allowlists für dieselben 12 Typen halten vertrauenswürdige Entwickler aus jedem Eskalationspfad fern.

Die zwei wichtigen Listentypen

Die API verfügt über drei Listentypen, und die Unterscheidung zwischen ihnen ist bewusst gewählt.

Blocklisten werden vom System erstellt – eine pro Eintragstyp – und sind unveränderlich. Sie können sie nicht erstellen, umbenennen oder löschen. Sie fügen Einträge hinzu und entfernen sie. Diese Einschränkung ist ein Feature: Es bedeutet, dass „blocklisted“ in Ihrem gesamten Unternehmen genau eine Bedeutung hat, und es gibt keine Möglichkeit, am Ende vier konkurrierende Gesichts-Blocklisten zu haben, die verschiedene Dienste inkonsistent überprüfen.

Allowlists können Sie selbst erstellen. Hier gehören bekannte gute Geräte, Adressbereiche, Geschäftseinheiten und Benutzer hin.

Benutzerdefinierte Listen sind für alles andere – Ihre eigenen Taxonomien, Überwachungsgruppen, Überprüfungskohorten.

# Die Gesichts-Blocklist finden
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

Der Mechanismus, der zählt

Hier ist die gewöhnliche Art, etwas zu blocklisten, und sie ist in fast jeder realen Situation der falsche Weg:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Das blocklistet eine Adresse. Währenddessen enthielt die Sitzung, die Sie untersuchten, auch ein Gesicht, eine Dokumentennummer, ein Telefon, eine E-Mail und einen Geräte-Fingerabdruck – jeder davon ein Identifikator, den der Betreiber ersetzen muss, bevor er zurückkehrt.

Der bessere Aufruf:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Übergeben Sie reference_session_id, und Didit extrahiert automatisch den richtigen Wert für den Eintragstyp dieser Liste aus der Sitzung, markiert das zugrunde liegende Modell als blocklistet und verknüpft den Eintrag mit der Sitzung, damit die Konsole Ihnen zeigen kann, woher er stammt.

Daraus ergeben sich drei Dinge, und alle drei sind operativ wichtig:

Keine manuelle Extraktion. Ihr Analyst liest keinen Geräte-Fingerabdruck vom Bildschirm ab und tippt ihn erneut ein. Transkriptionsfehler in Durchsetzungsdaten sind stille Fehler – die Sperre wird einfach nicht ausgelöst, und niemand findet es heraus.

Die Herkunft bleibt erhalten. Jeder Eintrag verweist auf die Sitzung, die ihn gerechtfertigt hat. Wenn jemand in vier Monaten fragt, warum dieses Gerät blockiert ist, ist die Antwort ein einziger Klick und kein archäologisches Projekt.

Die Durchsetzung ist wiederholbar. Derselbe Aufruf gegen jede Blocklist des Eintragstyps deckt die gesamte Identifikator-Oberfläche der Sitzung ab.

Wenn eine Sitzung mehrere Instanzen desselben Typs enthält, übergeben Sie value zusammen mit reference_session_id zur Disambiguierung.

Sie können auch außerhalb einer Verifizierungssitzung durchsetzen. reference_object_uuid zusammen mit metadata.reference_type – transaction, vendor_user oder vendor_business – blocklistet von einer Transaktion oder von einem Anbieterbenutzer oder -unternehmen und behält denselben Link zur Quelle bei.

Die 12 Eintragstypen

Eintragstyp	Blockiert	Anmerkungen
face	Die Person	Auch direkt über Gesichtsupload ladbar
document	Die Berechtigung
phone	Die Nummer	Automatisch auf E.164 normalisiert
email	Die Adresse
ip_address	Die Adresse oder der Bereich	Akzeptiert CIDR, z.B. 10.0.0.0/8
device_fingerprint	Die Maschine	Mindestens 8 alphanumerische Zeichen
wallet_address	Die On-Chain-Adresse
bank_account	Das Konto
user	Der Benutzerdatensatz
business	Die Entität
country	Die Jurisdiktion
key	Ein benutzerdefinierter Schlüssel

Zwei davon sind für dieses Problem besonders erwähnenswert.

ip_address akzeptiert einen CIDR-Bereich. Das Blocklisting von 203.0.113.0/24 blockiert die Infrastruktur, nicht eine einzelne Adresse. Wenn ein Farming-Betrieb auf einem gemieteten Subnetz läuft, ist dies der Unterschied zwischen einer skalierbaren Durchsetzung und einer Durchsetzung, die Whack-a-Mole spielt. Verwenden Sie es vorsichtig – ein Bereich umfasst auch echte Benutzer, und zu breite Bereiche führen dazu, dass Sie stillschweigend den Mobilfunkbetreiber eines Landes sperren.

face unterstützt den direkten Upload. Wenn Sie ein Bild, aber keine Sitzung haben, laden Sie es direkt hoch:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-kodiertes Bild>" }'

Didit extrahiert die Biometrie. Von da an wird dieses Gesicht bei jeder Verifizierung überprüft.

Was passiert, nachdem ein Eintrag gelandet ist

Das Hinzufügen zu einer System-Blocklist blockiert zukünftige Übereinstimmungen sofort zum Zeitpunkt der Verifizierung. Es gibt keine Propagationsverzögerung und keinen Batch-Job.

Bei der nächsten Verifizierung äußert sich die Durchsetzung als Warnungen:

• FACE_IN_BLOCKLIST – eindeutige Übereinstimmung, Verifizierung abgelehnt. POSSIBLE_FACE_IN_BLOCKLIST ist eine grenzwertige Übereinstimmung unterhalb des harten Schwellenwerts und sollte zur Überprüfung weitergeleitet werden, nicht zur Ablehnung.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST – Netzwerk- und Geräte-Treffer.

Bei der Gesichts-Suche ist eine Blocklist-Übereinstimmung das einzige, was den status auf „Declined“ setzt. Jede Übereinstimmung in der Antwort enthält auch is_blocklisted, sodass eine Untersuchung Ihnen sofort zeigt, welche Teile eines Clusters bereits unter Durchsetzung stehen und welche noch aktiv sind.

Die Entfernung ist symmetrisch: Das Löschen eines Eintrags hebt die Blockierung der übereinstimmenden Entität auf. Die Durchsetzung ist reversibel, was wichtig ist, da eine zu breite Durchsetzung ein echtes Risiko darstellt und Sie einen sauberen Weg zurück benötigen.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Allowlists: Schutz der gewünschten Entwickler

Eine Durchsetzung, die nur eskaliert, erstickt das Produkt irgendwann. Dieselben 12 Eintragstypen unterstützen Allowlists, und sie sind das Überdruckventil.

Allowlisten Sie die Büro-IP-Bereiche eines Designpartners. Allowlisten Sie die Geräte des Engineering-Teams eines Unternehmenskunden. Allowlisten Sie eine verifizierte Geschäftseinheit, damit ihre Benutzer niemals einen Eskalationspfad erreichen. IP_ADDRESS_IN_ALLOWLIST und DEVICE_FINGERPRINT_IN_ALLOWLIST werden ausgelöst, wenn eine Übereinstimmung auftritt, sodass Sie die angewendete Ausnahme bestätigen können, anstatt davon auszugehen, dass sie angewendet wurde.

Dies ist der Mechanismus, der aggressive Durchsetzung überlebensfähig macht. Sie können sich eine strenge Richtlinie für unbekannte Infrastruktur leisten, gerade weil Ihre bekannten guten Benutzer explizit ausgeschlossen sind.

Fehler, die es zu behandeln gilt

• 400 – der Wert hat den Validator des Eintragstyps nicht bestanden, der list_type ist für den Vorgang falsch (z. B. ein Gesichtsupload gegen eine Nicht-Gesichtsliste), oder reference_session_id enthält keine Daten des angeforderten Typs. Dieser letzte Fall ist häufig und harmlos: Nicht jede Sitzung erfasst jeden Identifikator.
• 403 – {"detail": "Sie haben keine Berechtigung, diese Aktion auszuführen."}

Beachten Sie, dass ein 400 von „Sitzung hat keine Daten dieses Typs“ erwartet wird, wenn Sie eine Sitzung über alle Blocklisten des Eintragstyps durchlaufen. Behandeln Sie es als Überspringen, nicht als Fehler.

Ein ausgearbeiteter Durchsetzungsablauf

Ein Analyst hat Missbrauch auf Konto acct_8842 bestätigt.

1. Lösen Sie zuerst den Cluster auf. Eine Gesichtssuche auf das Gesicht der Sitzung ergibt zwölf Konten; die Geräte- und IP-Korrelation zieht ein weiteres Dutzend hinzu. Die Durchsetzung vor der Auflösung sperrt ein Konto und warnt den Betreiber.
2. Blocklisten Sie von der bestätigten Sitzung aus – reference_session_id gegen die Gesichts-, Geräte-, IP-, E-Mail-, Telefon- und Dokumenten-Blocklisten. Sechs Aufrufe, keine manuelle Extraktion, vollständige Herkunft.
3. Berücksichtigen Sie den Bereich. Wenn die Netzwerkbeweise auf gemietete Infrastruktur hinweisen, deckt ein CIDR-Eintrag das Subnetz ab. Überprüfen Sie zuerst, was sich sonst noch dort befindet.
4. Handeln Sie nach dem Cluster gemäß Ihrer eigenen Richtlinie – die Konten, die Sie bereits identifiziert haben, entsperren sich nicht von selbst.
5. Überprüfen Sie die Durchsetzung. Führen Sie die Gesichtssuche erneut aus. Übereinstimmungen sollten nun is_blocklisted: true anzeigen.
6. Warten Sie auf den Regenerationsversuch. Das nächste Konto, das mit diesem Gesicht, Gerät oder Subnetz erstellt wird, wird bei der Verifizierung abgelehnt, anstatt drei Wochen später in Ihrem Traffic aufzutauchen.

Schritt 6 ist der springende Punkt. Die Kosten des Betreibers für die Rückkehr sind nicht länger „eine neue E-Mail-Adresse erstellen“. Es ist „neue Hardware, neues Netzwerk und eine neue Person beschaffen“.

Anwendungsfälle

AI-API-Plattformen, die einen bestätigten Distillations- oder Missbrauchsfall in eine Durchsetzung über jeden vom Betreiber betroffenen Identifikator umwandeln.

Test- und Kreditmissbrauch, bei dem dasselbe Gerät und Gesicht immer wieder für eine neue kostenlose Zuteilung zurückkehren.

Marktplätze, die entfernte Verkäufer daran hindern, sich unter einem neuen Unternehmen erneut zu registrieren.

iGaming, das Selbstsperren durchsetzt, wobei ein zurückkehrender ausgeschlossener Spieler ein regulatorisches Versagen darstellt und die Durchsetzung auf Gesichtsebene die einzige zuverlässige Kontrolle ist.

Häufig gestellte Fragen

Kann ich meine eigene Blocklist erstellen?

Nein. Blocklisten werden vom System erstellt, pro Eintragstyp einmalig und unveränderlich – Sie fügen Einträge hinzu und entfernen sie. Sie können Allowlists und benutzerdefinierte Listen frei erstellen. Die Einschränkung sorgt dafür, dass „blocklisted“ überall die gleiche Bedeutung hat.

Wie schnell wird ein Eintrag wirksam?

Sofort, bei der nächsten Verifizierung.

Was passiert, wenn ich etwas versehentlich blockliste?

Löschen Sie den Eintrag, und die Entität wird entsperrt. Deshalb ist die Herkunft wichtig – jeder aus einer Sitzung erstellte Eintrag verweist darauf, sodass Sie überprüfen können, wofür ein Eintrag war, bevor Sie ihn entfernen.

Beeinträchtigt das Blocklisting eines IP-Bereichs legitime Benutzer in diesem Bereich?

Ja, und das ist das Risiko. Ein CIDR-Eintrag blockiert alles darin. Verwenden Sie Bereiche, wenn die Beweise auf dedizierte Infrastruktur hinweisen, verwenden Sie ansonsten einzelne Adressen und allowlisten Sie zuerst bekannte gute Bereiche.

Kann ich von etwas blocklisten, das keine Verifizierungssitzung ist?

Ja. reference_object_uuid plus metadata.reference_type (transaction, vendor_user oder vendor_business) deckt Transaktionen und Anbieterbenutzer oder -unternehmen ab.

Stoppt dies die Modell-Extraktion?

Nein. Es hindert einen bestimmten bekannten Akteur daran, über die von Ihnen durchgesetzten Identifikatoren wieder einzudringen, und es erhöht die Kosten der Regeneration. Die Erkennung der Extraktion ist die Aufgabe Ihrer Traffic-Schicht, und die Begrenzung dessen, was die Extraktion liefert, ist die Aufgabe Ihrer Modellschicht. Dies ist der Durchsetzungsarm einer dreischichtigen Verteidigung, kein Ersatz für die anderen beiden.

Bereit zum Start?

Die Lists API ist für jedes Didit-Konto verfügbar.

• Lesen Sie die Dokumentation – Übersicht über die Lists API und den IP & Geräte-Warnkatalog.
• Sehen Sie sich das Produkt an – Benutzerverifizierung.
• Überprüfen Sie die Preise – öffentlich gelistet, Pay-per-Success, keine Mindestmengen.
• Kostenlos starten – business.didit.me, 500 KYC-Verifizierungen pro Monat kostenlos.