Account‑Enumeration bei Registrierung, Anmeldung und Reset verhindern

Wie Account-Enumeration im echten Leben aussieht

Account-Enumeration ist, wenn jemand allein anhand der Reaktion deiner App erkennen kann, ob eine E-Mail, ein Benutzername oder eine Telefonnummer registriert ist. Sie müssen sich nicht einloggen. Sie müssen nur viele Vermutungen ausprobieren und auf Unterschiede in Meldungen, Statuscodes, Timing oder Nebeneffekten achten.

Signup, Login und Passwort-Zurücksetzen sind häufige Ziele, weil sie öffentlich sind und sich bei vorhandenen Konten natürlicherweise anders verhalten. Das macht es leicht, unbeabsichtigt Hinweise zu verraten.

Ein einfaches Beispiel: Ein Passwort-Reset-Formular sagt:

• „Wir haben dir einen Reset-Link geschickt“ wenn die E-Mail existiert
• „Kein Konto gefunden“ wenn nicht

Ein Angreifer kann eine Liste von 50.000 E-Mails hochladen und schnell herausfinden, wer dein Produkt nutzt. Diese Liste kann verkauft, für Belästigung genutzt oder für gezielte Phishing-Angriffe verwendet werden („Ich weiß, du hast ein Konto, klicke diesen Link“). Außerdem macht es Credential Stuffing effizienter, weil Angreifer sich nur auf bestätigte E-Mails konzentrieren können.

Enumeration ist auch ein Datenschutzproblem. Schon die Bestätigung, dass jemand ein Konto hat, kann sensibel sein – etwa bei Gesundheits-, Finanz-, Arbeits- oder Bildungsprodukten.

Das Ziel ist einfach: Mach das benutzerseitige Ergebnis ununterscheidbar, egal ob das Konto existiert oder nicht, und behalte gleichzeitig starke interne Sichtbarkeit. Nutzer sollten dieselbe Meldung, denselben Statuscodeverlauf und ähnliche Antwortzeiten sehen. Intern protokollierst du weiter die Wahrheit in Logs und Metriken.

Die Signale, die Angreifer nutzen, um zu raten, ob ein Konto existiert

Angreifer brauchen nicht deine Datenbank. Sie brauchen nur winzige Unterschiede in dem, was deine App zurückgibt, wenn jemand eine E-Mail oder Telefonnummer eingibt.

Die offensichtlichsten Signale stecken in der Antwort selbst: ein 404 für „Benutzer nicht gefunden“ vs. 200 für „Reset gesendet“, oder JSON wie error: \"no_such_user\". Selbst wenn der Text freundlich wirkt, machen unterschiedliche Statuscodes, Fehlercodes oder Antwortformen die Automatisierung leicht.

Auch das UI-Verhalten kann verräterisch sein. Wenn die Web-App bei Login „Kein Konto gefunden“ sagt, die mobile App aber immer „Prüfe deine E‑Mails“, nutzen Angreifer die einfachere Variante. Dasselbe Problem tritt auf, wenn HTML-Seiten sich von JSON-APIs unterscheiden: Eine könnte einen Hinweis im Body, einem Header oder Redirect verraten.

Gängige Signale, die Angreifer messen:

• Statuscodes und Fehlercodes (200 vs 404, USER_NOT_FOUND vs INVALID_PASSWORD)
• Nachrichtentext und UI-Zustände (verschiedene Banner, Feldhervorhebungen, deaktivierte Buttons)
• Antwort-Timing (schnelles Fehlschlagen bei unbekannten Benutzern, langsamere Pfade bei echten)
• Sekundäre Aufforderungen (CAPTCHA erscheint nur nach einer „echten“ E‑Mail)
• Out‑of‑band‑Effekte (E‑Mail/SMS wird nur für existierende Konten verschickt)

Timing-Unterschiede sind bedeutender, als viele Teams erwarten. Wenn ein Reset-Request in 40 ms für eine fehlende E‑Mail zurückkehrt, aber 400 ms, wenn ein Token erzeugt, in die DB geschrieben und eine E‑Mail in die Queue gestellt wird, können Angreifer diese Lücke als zuverlässiges Signal nutzen.

Achte auch auf unbeabsichtigte Lecks durch Tools. Wenn interne Fehlermeldungen oder Reason-Codes an den Client gespiegelt werden (direkt oder über ausführliches clientseitiges Logging), kann ein Angreifer „Benutzer existiert“ herausfinden, ohne dass deine UI das je sagt.

Wähle ein sicheres Antwortmuster für jeden Endpunkt

Der schnellste Weg, das Enumerationsrisiko zu reduzieren, ist vorab zu entscheiden, was der Nutzer in jedem Flow sieht, und dann dabei zu bleiben: dieselbe Meldung, derselbe Screen und derselbe nächste Schritt.

Behandle jeden Flow getrennt (Login, Registrierung, Reset), aber sei innerhalb des Flows konsistent. Verwende neutrale, nicht-verbindliche Formulierungen. Vermeide Aussagen, die Existenz bestätigen wie „nicht gefunden“, „kein Konto“, „bereits registriert“ oder „Benutzer existiert nicht“.

Sichere Antwortmuster, die in der Regel funktionieren:

• Login: Nutze ein generisches Fehlschlagen wie „Wir konnten dich nicht anmelden. Überprüfe deine Daten und versuche es erneut.“ Halte die gleichen Hilfsoptionen jedes Mal verfügbar.
• Signup: Zeige etwas wie „Wenn du E‑Mails an diese Adresse empfangen kannst, erhältst du in Kürze die nächsten Schritte.“ Ändere die UI nicht basierend darauf, ob die Adresse bereits in Gebrauch ist.
• Passwort‑Reset: Zeige immer „Wenn ein Konto zu dieser E‑Mail existiert, haben wir Anweisungen gesendet.“ Leite immer auf denselben Bestätigungsbildschirm weiter.

Text ist nur ein Teil. Angreifer beobachten das ganze Verhalten. Halte Folgendes für alle Outcomes übereinstimmend:

• Gleiches HTTP-Statuscode‑Muster
• Ähnliche Antwortzeitspanne (vermeide offensichtliche Fast‑Fail‑Pfadunterschiede)
• Dieselbe Seite, Buttons und Handlungsaufrufe
• Dieselbe Anzahl Schritte bis zur Bestätigung

Ein praktischer Ansatz für Reset: Zeige sofort den Bestätigungsbildschirm und starte die eigentliche Arbeit im Hintergrund. Intern protokollierst du, ob eine E‑Mail gesendet, gebounced, unterdrückt oder blockiert wurde, aber gib das nie in der Antwort wieder.

Schritt für Schritt: Antworten ununterscheidbar machen

Du brauchst einen klaren Vertrag: Ein Endpunkt sollte für einen externen Aufrufer gleich aussehen, egal ob ein Konto existiert oder nicht. Das bedeutet, sichtbare Meldung, HTTP-Status und das „Gefühl“ der Antwort abzugleichen.

Beginne damit, aufzuschreiben, was du heute hast, und verbessere es dann mit kleinen, testbaren Änderungen:

• Inventory aller Auth-Einstiegspunkte: Signup, Login, Passwort-Reset, E‑Mail‑Verifikation, „Code erneut senden“ sowie alle Clients, die sie aufrufen (Web, Mobile, Public API).
• Erstelle eine Antwortmatrix für jeden Endpunkt (Erfolg, falsches Passwort, unbekannte E‑Mail, gesperrtes Konto, MFA erforderlich). Markiere, welche Felder, Statuscodes und UI‑Zweige sich heute unterscheiden.
• Standardisiere, was der Client sehen kann: Wähle eine Statuscode‑Strategie pro Endpunkt und einen Antwortkörper, der niemals die Kontoexistenz bestätigt.
• Normalisiere das Timing: Wenn ein Pfad frühzeitig endet, bring ihn näher an den langsameren Pfad. Du kannst kleines Jitter hinzufügen oder auf beiden Pfaden dieselben Arbeiten durchführen.
• Aktualisiere das UI‑Verhalten, sodass es dem Vertrag entspricht: zeige nicht „E‑Mail nicht gefunden“. Zeige immer denselben nächsten Schritt.

Verriegele das Ganze anschließend mit Tests, damit es sich nicht zurückentwickelt, wenn sich der Code ändert.

Tests, um Antworten ununterscheidbar zu halten

Automatisierte Checks sollten Ausgaben über Fälle vergleichen, die früher Signale geleakt haben:

• Stelle sicher, dass derselbe Statuscode und dieselbe Antwortform für „bekannte E‑Mail“ vs „unbekannte E‑Mail“ zurückgegeben werden.
• Stelle sicher, dass Fehlermeldungen identisch sind (oder gleichermaßen vage) über alle Fehlerfälle hinweg.
• Messe das Timing beider Pfade und lasse den Test fehlschlagen, wenn die Lücke eine kleine Schwelle überschreitet.
• Füge einen Integrationstest hinzu, der einen vollständigen Reset-Request simuliert und bestätigt, dass das UI nicht basierend auf „Konto existiert“ verzweigt.

Signup, Login und Reset: praktische Nachrichtenvorlagen

Um Account-Enumeration zu verhindern, müssen öffentliche Antworten gleich aussehen, egal ob das Konto existiert oder nicht. Der Trick ist außen langweilig zu sein und innen präzise (Logs, Metriken, Support-Tools).

Endpunkt-Antwortvorlagen (was der Client sieht)

Halte Statuscodes und Nachrichtenformen konsistent. Wenn du JSON zurückgibst, gib immer dieselben Felder zurück.

• Login (jegliches Fehlschlagen): 401 mit { \"error\": \"Invalid email or password.\" }
• Signup (Anfrage akzeptieren, auch wenn E‑Mail bereits in Gebrauch): 200 mit { \"message\": \"If you can sign up, you’ll receive an email with next steps.\" }
• Passwort-Reset (immer): 200 mit { \"message\": \"If an account exists for that email, we sent reset instructions.\" }

Beim Login ist es normal, 401 für fehlgeschlagene Authentifizierung zurückzugeben. Der Schlüssel ist, dass alle Login‑Fehler gleich aussehen sollten (unbekannte E‑Mail vs falsches Passwort), inklusive Antwortform und Timing.

E‑Mail/SMS‑Vorlagen (was der Nutzer erhält)

Nachrichteninhalte können ebenfalls Existenz verraten. Vermeide E‑Mails wie „Kein Konto gefunden“. Bevorzuge stilles Verhalten oder generische Hinweise.

Beispiele, die funktionieren:

• Signup-Verifikation: „Bestätige deine E‑Mail, um fortzufahren. Wenn du das nicht angefordert hast, kannst du diese Nachricht ignorieren.“
• Reset-E‑Mail: „Wir haben eine Anfrage zum Zurücksetzen deines Passworts erhalten. Wenn du das nicht angefordert hast, ignoriere diese Nachricht.“
• Reset‑SMS: „Dein Reset-Code ist 123456. Wenn du das nicht angefordert hast, ignoriere diese Nachricht.“

Bei nicht existierenden Konten ist das sicherste Muster oft stumm: zeige dieselbe Onscreen-Erfolgsmeldung, sende aber nichts.

Analytics und Support-Tools behalten, ohne Informationen zu verraten

Einheitliche Antworten bedeuten nicht, dass du blind fliegst. Du kannst genau protokollieren, was passiert ist, du gibst die Details nur serverseitig aus.

Ein einfaches Muster: Gib dieselbe nutzerseitige Meldung zurück, aber zeichne für jede Anfrage einen stabilen internen Reason-Code auf. Diese Codes dürfen niemals in API-Antworten, UI-Texten oder clientseitigen Logs erscheinen.

Beispiele für interne Reason-Codes:

• login_failed_no_user
• login_failed_wrong_password
• login_failed_mfa_required
• reset_requested_no_user
• reset_sent

Koppele jede Auth-Anfrage mit einer servergenerierten Korrelations-ID. Nutze sie in Server-Logs und Audit‑Events, damit du eine Anfrage über Auth-Service, E‑Mail‑Provider und Datenbank hinweg nachverfolgen kannst, ohne etwas an den Nutzer zu offenbaren. Wenn du Nutzern eine Request‑ID für Support zeigst, halte sie generisch und stelle sicher, dass sie keinen Kontostatus verrät.

Support-Teams müssen reale Menschen weiterhin helfen können. Bewahre Lookup-Tools hinter Personal-Authentifizierung auf und stelle sie standardmäßig auf minimale Ausgabe. „Konto gefunden“ ist im internen Console-Tool in Ordnung; es darf niemals etwas sein, das ein öffentlicher Aufrufer ableiten kann.

Sei streng mit PII. Logge so wenig wie möglich und bleibe dabei nützlich:

• Hash oder tokenize E‑Mails in Logs, wo möglich
• Speichere vollständige E‑Mails nur in Systemen, die bereits Richtlinien dafür haben
• Halte die Aufbewahrung kurz, außer Compliance verlangt längere Fristen

Guardrails hinzufügen: Throttling, Erkennung und Abuse-Kontrollen

Einheitliche Meldungen sind die Basis, aber nicht die ganze Verteidigung. Du brauchst zusätzlich Guardrails, die Angreifer verlangsamen und Muster früh erkennen helfen.

Throttling und progressive Verzögerungen

Beginne mit Rate-Limits, die Automatisierung teuer machen, ohne normale Nutzer zu beeinträchtigen. Wende Limits nach IP und Geräte-Fingerprint an und füge eine sorgfältige Prüfung der übermittelten Identifier (E‑Mail/Telefon) hinzu, ohne daraus ein neues Signal zu machen. Ein gängiger Ansatz ist, separate Zähler zu führen und das strengste Ergebnis anzuwenden.

Nach wiederholten Versuchen füge Verzögerungen hinzu, die mit der Zeit wachsen. Halte das Verzögerungsverhalten für existierende und nicht-existierende Konten gleich. Wenn du eine Sperre einführst, sag nicht „Konto gesperrt“ in der Nutzeranzeige. Behandle Sperren als internen Zustand.

Eine praktische Konfiguration:

• Per‑IP‑Limit (kurzes Fenster) um Bursts zu stoppen
• Per‑Gerät‑Limit um gemeinsame IPs (Cafés, Büros) zu erkennen
• Per‑Identifier‑Limit um gezieltes Raten zu verlangsamen
• Progressive Verzögerung nach N Fehlschlägen, einheitlich angewandt
• Soft‑Lockout mit Cooldown plus interne Alarme

CAPTCHA kann helfen, aber zeige es nicht nur, wenn eine E‑Mail existiert. Trigger es auf Basis von Risiko‑Signalen (Volumen, Geschwindigkeit, Hinweise auf Automatisierung) und halte die nutzerseitige Textmeldung konsistent.

Erkennung und Abuse‑Monitoring

Enumeration hat Muster, die du überwachen kannst. Ein Bot versucht möglicherweise hunderte einzigartige E‑Mails von einer IP oder wenige E‑Mails von vielen IPs.

Tracke und alarmiere bei:

• Hoher Request‑Volume auf Login/Reset/Signup
• Viele einzigartige Identifier pro IP oder Gerät
• Wiederholte Versuche mit niedriger Erfolgsrate
• Spitzen zu ungewöhnlichen Zeiten oder aus neuen Regionen
• Mustern über Endpunkte hinweg (z. B. Reset gefolgt von Login mit selben Identifiern)

Häufige Fehler, die Enumeration wieder einführen

Viele Teams beheben den offensichtlichen Nachrichtentext, leaken dann aber Kontoexistenz über Nebenkanäle. Angreifer testen den gesamten Flow, nicht nur den Satz auf dem Bildschirm.

Unterschiedliche HTTP‑Statuscodes sind ein sofortiges Signal. Wenn eine bekannte E‑Mail 200 zurückgibt, eine unbekannte jedoch 404 (oder 422), erkennen Bots das sofort.

Timing ist der nächste Verräter. Ein Pfad greift auf die DB, sendet eine Mail oder macht Passwort-Hashing, während der andere frühzeitig endet. Du brauchst keine perfekte konstante Zeit, aber vermeide konsistente Fast‑Fail vs Slow‑Path‑Lücken.

Auch E‑Mail‑Inhalte können verraten. Reset‑E‑Mails, die Planname, letzte Anmeldung oder eine personalisierte Begrüßung enthalten, bestätigen das Konto. Halte Reset‑E‑Mails generisch, bis der Nutzer Kontrolle über das Postfach beweist, indem er dem Token folgt.

UI‑Logik leakt oft. Ein „Konto erstellen“-Prompt, das nur erscheint, wenn die E‑Mail unbekannt ist, ist ein Hinweis. Inline‑Validierung wie „E‑Mail bereits verwendet“ hilft ehrlichen Nutzern, ist aber auch ein Verzeichnis für Angreifer.

Kurze Checkliste:

• Gib dieselbe Statuscode‑Strategie und dieselbe geformte JSON für beide Outcomes zurück
• Halte die Antwortzeit beider Pfade in derselben Größenordnung
• Vermeide feldspezifische Fehler, die Existenz implizieren
• Ändere UI‑Optionen nicht basierend auf der Frage, ob eine E‑Mail existiert
• Halte Reset‑E‑Mails generisch, bis der Nutzer verifiziert hat

Schnellchecks, bevor du ausrollst

Teste wie ein Angreifer. Ein externer Aufrufer sollte nicht erkennen können, ob ein Konto existiert, während dein Team intern die Wahrheit in der Telemetrie hat.

Eine schnelle Checkliste:

• Für Login und Passwort-Reset: Bestätige, dass du dasselbe Statuscode‑Muster für existierende und nicht‑existierende Konten zurückgibst.
• Vergleiche Antwortbodies nebeneinander. Sie sollten dieselben Felder, Datentypen und ungefähr ähnliche Längen haben.
• Lies E‑Mail‑ und SMS‑Texte wie ein Fremder. Nachrichten dürfen niemals bestätigen, dass eine Adresse oder Telefonnummer registriert ist.
• Verifiziere, dass interne Logs das reale Ergebnis aufzeichnen (Benutzer gefunden vs nicht gefunden, Token erstellt vs übersprungen) mit einer Request‑ID, die dein Support-Team suchen kann.
• Bestätige, dass Support-Tools Ergebnisse nur nach Mitarbeiter-Authentifizierung zeigen, nicht in öffentlichen Antworten.

Mach dann einen Timing‑Sanity‑Check. Wähle einen Endpunkt (Reset ist ein guter Start) und teste 20–30 Requests mit einer existierenden und einer nicht‑existierenden E‑Mail. Du suchst nach einer klaren, wiederholbaren Lücke. Wenn du eine siehst, polstere den schnellen Pfad oder verlagere teure Arbeit in einen asynchronen Job.

Beispiel: Beheben eines undichten Passwort-Reset-Flows

Ein kleines SaaS‑Team erhält Meldungen: „Jemand versucht immer wieder, mein Passwort zurückzusetzen.“ Die Logs zeigen viele Reset‑Requests für Adressen, die wie eine Kundenliste aussehen. Das Muster ist klassisch: Jemand prüft, welche E‑Mails existieren.

Der alte Passwort-Reset‑Endpunkt hatte zwei Outcomes, die leicht erkennbar waren:

• Wenn die E‑Mail nicht existierte: „E‑Mail nicht gefunden. Versuche dich zu registrieren.“
• Wenn die E‑Mail existierte: „Prüfe dein Postfach auf einen Reset‑Link.“

Diese Differenz reicht, um gültige Konten in großem Maßstab zu bestätigen. Selbst wenn die UI ähnlich aussieht, können kleine Unterschiede in Statuscode, Antwortkörper oder Timing noch leaken.

Die Lösung ist, die öffentliche Antwort jedes Mal identisch zu machen und das echte Ergebnis intern mit Reason‑Codes zu protokollieren.

Öffentliches Verhalten (neu): dieselbe UI‑Meldung und derselbe HTTP‑Status für alle Requests, z. B.: „Wenn ein Konto zu dieser E‑Mail existiert, haben wir Anweisungen gesendet.“

Internes Verhalten (neu): Schreibe ein strukturiertes Event, damit Analytics, Security und Support weiterhin handeln können:

{
  "event": "password_reset_requested",
  "email_hash": "sha256(...)" ,
  "result": "SENT" ,
  "reason_code": "OK",
  "ip": "203.0.113.10",
  "user_agent": "...",
  "request_id": "..."
}

Wenn die E‑Mail nicht existiert, behalte dieselbe öffentliche Antwort, logge aber result: "NOOP" mit reason_code: "ACCOUNT_NOT_FOUND". Wenn du wegen Abuse blockst, logge reason_code: "RATE_LIMIT".

Der Support kann weiterhin helfen, ohne öffentlich etwas zu bestätigen. Wenn jemand sagt „Ich habe die E‑Mail nicht bekommen“, kann Support das letzte Reset‑Event per E‑Mail‑Hash oder Request‑ID nachschlagen. Zeigen die Events wiederholt NOOP, hat der Nutzer wahrscheinlich eine falsche Adresse eingegeben. Zeigen die Events SENT aber keine Zustellung, kannst du Bounces beim E‑Mail‑Provider prüfen, ohne das Reset‑Formular anders aussehen zu lassen.

Um die Lösung zu validieren, mache einen Before/After‑Test: Versuche Reset mit einer bekannten E‑Mail und einer zufälligen E‑Mail, und vergleiche Statuscodes, Antwortkörper und Timing. Sie sollten von außen ununterscheidbar sein, während deine Logs weiterhin die echten Outcomes zeigen.

Nächste Schritte: Sicher einführen und eine zweite Meinung holen

Standardisiere Endpunkte nacheinander. Passwort‑Reset ist oft der wichtigste, weil es leicht zu prüfen ist und häufig offensichtliche Unterschiede leakt. Sobald Reset konsistent ist, gehe zu Login und dann Signup über.

Bevor du deployst, habe einen einfachen Testplan, der sowohl dein Web‑UI als auch API‑Clients (Mobile Apps, Integrationen, CLI‑Tools) abdeckt. Sei streng darin, was „gleiche Antwort“ über alle Clients hinweg bedeutet.

• Teste gültige und ungültige E‑Mails/Benutzernamen und vergleiche Statuscodes, Body‑Shape und Timing
• Teste gesperrte Konten, unverifizierte E‑Mails und MFA‑erforderliche Nutzer
• Bestätige, dass das UI echte Nutzer weiterführt, ohne zu sagen „das Konto existiert“
• Verifiziere, dass Logs und Metriken intern weiterhin das echte Ergebnis erfassen
• Prüfe die Lokalisierung, da Übersetzungen wieder unterschiedliche Meldungen einführen können

Wenn du mit KI‑generiertem Auth‑Code arbeitest, gehe davon aus, dass es versteckte Lecks gibt (extra JSON‑Felder, frühe Returns, unterschiedliche Fehlerbehandlung zwischen Clients). FixMyMess (fixmymess.ai) konzentriert sich auf das Diagnostizieren und Reparieren solcher produktionsrelevanten Probleme, inklusive dem Straffen von Auth‑Antworten bei gleichzeitiger Erhaltung interner Telemetrie für Support und Security.