Login
Kostenlos testen

Wie Sie den Missbrauch von Kennwortrücksetzungen auf Ihrer Website verhindern können (2026)

Illustration zur Verhinderung des Missbrauchs beim Zurücksetzen von Passwörtern, wobei Bedrohungen wie automatisierte Angriffe, Benutzeraufzählung, E-Mail-Flooding und Credential Stuffing neben Schutzmaßnahmen wie Ratenbegrenzung, CAPTCHA-Überprüfung, Schutz der Existenz von Konten und Überwachungswarnungen dargestellt werden.
ist captcha.eu

Die meisten Teams schützen ihre Anmeldeseite sorgfältig und lassen den Fluss zum Zurücksetzen des Passworts nahezu offen. Angreifer wissen das. Sie nutzen den Rücksetzvorgang, um gültige Konten aufzuzählen, Posteingänge mit automatisierten E-Mails zu überschwemmen, Token durch die Generierung schwacher Links zu stehlen und die Anmeldeschutzmaßnahmen zu umgehen, die Sie mit viel Zeitaufwand gehärtet haben. In diesem Leitfaden werden alle Missbrauchsmuster für das Zurücksetzen von Konten und die praktischen Schritte erläutert, mit denen jedes einzelne Muster verhindert werden kann.

Geschätzte Lesezeit: 13 Minuten

CAPTCHA.eu kostenlos testen - keine Kreditkarte
Alle Integrationen anzeigen

Auf einen Blick

Warum Rücksetzbewegungen missbraucht werden

Der Rücksetzvorgang umgeht Ihre Anmeldeseite vollständig. Wenn er schwächer ist als Ihr Login, nutzen Angreifer ihn als einfacheren Weg zum Kontozugang

Vier Missbrauchsmuster, die man kennen sollte

Enumeration von Konten, Reset Flooding, Token-Diebstahl und schwaches Recovery-Design. Jedes dieser Probleme erfordert einen anderen Schutz, und keines davon lässt sich allein durch einen Anmeldeschutz lösen

Die schnellste Einzelbehebung

Geben Sie die gleiche Antwort zurück, egal ob ein Konto existiert oder nicht. Mit dieser einzigen Änderung entfällt die Aufzählung der Konten ohne technische Kosten

Was dieser Leitfaden behandelt

Warum das Zurücksetzen von Passwörtern zur Zielscheibe wird

Der Ablauf der Kennwortrücksetzung ist die Hintertür zu Ihrem Authentifizierungssystem. Seine Aufgabe ist es, Benutzer ohne ihr Kennwort wieder einzulassen, was bedeutet, dass er die normale Überprüfung der Anmeldedaten umgehen muss. Das macht ihn strukturell schwächer als die Anmeldung, und Angreifer nutzen diese Lücke direkt aus.

Drei Dinge machen Reset-Flows zu attraktiven Zielen. Erstens fügen die meisten Teams der Anmeldung einen starken Bot-Schutz hinzu, vernachlässigen aber den Reset-Endpunkt völlig. Zweitens verraten Reset-Flows Angreifern nützliche Informationen: ob ein Konto existiert, welche E-Mail-Adressen registriert sind und wie schnell Reset-Tokens ablaufen. Drittens sind Rücksetzformulare öffentlich zugänglich und leicht zu automatisieren: Ein Bot kann Tausende von Rücksetzanfragen pro Stunde für ein Formular ohne Ratenbegrenzung oder CAPTCHA auslösen.

Das Ergebnis ist, dass selbst Teams, die die Anmeldung gehärtet, MFA hinzugefügt und Ratenbegrenzungen implementiert haben, das Zurücksetzen von Passwörtern oft als ungeschützten Nebeneingang belassen. Das Forgot Password Cheat Sheet von OWASP listet Schwachstellen beim Zurücksetzen von Passwörtern als eine der am häufigsten ausgenutzten Schwachstellen bei der Authentifizierung in Produktionsanwendungen auf. Der schwächste Punkt in Ihrem Authentifizierungssystem ist der einzige, der für einen entschlossenen Angreifer von Bedeutung ist, und wenn dieser Punkt Ihr Rücksetzungsformular ist, zählt der gesamte Schutz auf Ihrer Anmeldeseite nichts.

Die vier Missbrauchsmuster des Passwort-Rücksetzungsmissbrauchs

Der Missbrauch beim Zurücksetzen von Passwörtern ist kein einzelner Angriffstyp. Es handelt sich um eine Kategorie mit vier verschiedenen Mustern, die jeweils unterschiedliche Ziele verfolgen und unterschiedliche Abwehrmaßnahmen erfordern.

MISSBRAUCHSVERHÄLTNIS
WAS ANGREIFER TUN
WAS SIE GEWINNEN
Konto-Aufzählung
Senden Sie Rücksetzungsanfragen für viele E-Mail-Adressen und beobachten Sie, ob sich die Antworten für bestehende und nicht bestehende Konten unterscheiden.
Eine geprüfte Liste echter Konto-E-Mail-Adressen zur Verwendung bei Phishing, Credential Stuffing oder gezielten Angriffen
Flutung zurücksetzen
Automatische Auslösung einer großen Anzahl von Rücksetzungs-E-Mails an ein oder mehrere Konten
Überlastung des Posteingangs mit Phishing-E-Mails, Belästigung von Nutzern oder Beeinträchtigung des Rufs der E-Mail-Infrastruktur
Token-Diebstahl und rohe Gewalt
Abfangen von zurückgesetzten Links über Referrer-Header, archivierte URLs oder den Browserverlauf; oder Brute-Force von kurzen/vorhersehbaren Token
Gültiges Reset-Token, das es ihnen ermöglicht, ein neues Passwort zu setzen und das Konto zu übernehmen, ohne das ursprüngliche zu kennen
Schwaches Verwertungskonzept
Ausnutzung unsicherer Wiederherstellungsmethoden: wiederverwendbare Token, nicht ablaufende Links, Sicherheitsfragen mit erratbaren Antworten oder SIM-Austausch zum Abfangen von SMS-Codes
Kontozugriff über den Wiederherstellungspfad, ohne dass der Anmeldefluss unterbrochen werden muss

Diese vier Muster treten oft zusammen in einer einzigen Angriffskampagne auf. Ein Angreifer kann mit Enumeration beginnen, um echte Konten zu identifizieren, und dann Reset Flooding verwenden, um Verwirrung zu stiften, während er einen Token-Diebstahl oder SIM-Swap gegen ein bestimmtes hochwertiges Ziel durchführt. Um sich gegen alle vier Angriffe zu schützen, sind mehrschichtige Kontrollen erforderlich, nicht nur eine einzige Lösung.

Sieben Abwehrmaßnahmen, die funktionieren

  • Konsistente Antworten für bestehende und nicht bestehende Konten liefern

    Dies ist die wichtigste Änderung, die Sie vornehmen können, und sie kostet fast nichts. Wenn ein Benutzer eine Anfrage zum Zurücksetzen einer E-Mail-Adresse stellt, geben Sie genau dieselbe Nachricht, denselben HTTP-Statuscode und dieselbe Antwortzeit zurück, egal ob das Konto existiert oder nicht. Eine Meldung wie “Wenn ein Konto mit dieser Adresse existiert, erhalten Sie eine E-Mail zum Zurücksetzen” schließt die Aufzählung der Konten vollständig aus. Der häufigste Fehler ist die Rückmeldung “Wir haben Ihnen eine E-Mail zum Zurücksetzen gesendet” für echte Konten und “Kein Konto gefunden” für nicht existierende Konten. OWASP's Forgot Password Cheat Sheet weist speziell auf dieses Muster als eine der häufigsten Schwachstellen bei der Aufzählung von Konten in Produktionsanwendungen hin. Korrigieren Sie den Antworttext, aber überprüfen Sie auch Ihr Antwort-Timing: Wenn Ihre Anwendung die Datenbank abfragt, bevor sie eine Antwort zurückgibt, kann der Zeitunterschied zwischen einem echten Kontotreffer und einem Fehlschlag selbst Informationen preisgeben. Verwenden Sie asynchrone Verarbeitung oder künstliche Verzögerung, um das Timing konsistent zu machen.

  • CAPTCHA zum Formular für die Rücksetzanfrage hinzufügen

    CAPTCHA auf dem Rücksetzungsformular stoppt zwei Missbrauchsmuster auf einmal: Rücksetzungsflut und Kontoaufzählung in großem Umfang. Ein Angreifer, der Tausende von E-Mail-Adressen auf gültige Konten überprüft, muss diese Anfragen automatisieren. Ein Proof-of-Work-CAPTCHA erzwingt eine kryptografische Berechnung für jede Übermittlung, was eine groß angelegte Automatisierung wirtschaftlich unpraktisch macht, ohne legitime Benutzer zu beeinträchtigen, die eine Anfrage nach der anderen stellen. Für europäische Websites ist die Wahl des CAPTCHA hier wichtiger als fast überall sonst. Das Rücksetzungsformular ist eine sicherheitskritische Seite, auf der sich die Benutzer bereits in einem gefährdeten Zustand befinden: Sie haben den Zugang zu ihrem Konto verloren. Die Hinzufügung eines auf Cookies basierenden Verhaltens-CAPTCHAs führt genau zum falschen Zeitpunkt zu Fragen der ePrivacy-Einwilligung. Ein cookieloses Proof-of-Work-CAPTCHA lässt sich integrieren, ohne dass zusätzliche Einwilligungserklärungen auf Wiederherstellungsseiten erforderlich sind. Eine ausführliche Erklärung, wie das funktioniert, finden Sie in unserem Leitfaden zu unsichtbaren CAPTCHAs.

Schützen Sie Ihren Passwort-Rücksetzungsfluss ohne Cookies oder Zustimmung über Kopf

CAPTCHA.eu stoppt Reset Flooding und Enumeration in großem Umfang mit unsichtbarer Proof-of-Work-Verifikation. Keine Cookies, in Österreich gehostet, WCAG 2.2 AA zertifiziert durch TÜV Austria.

Kostenlose Testversion starten
Alle Integrationen anzeigen

    • Ratenbegrenzung pro Konto und pro IP anwenden

      Die Ratenbegrenzung am Reset-Endpunkt begrenzt den Umfang des Missbrauchs, auch wenn CAPTCHA bereits vorhanden ist. Wenden Sie Begrenzungen auf zwei Ebenen an: pro IP-Adresse und pro Konto. Die Begrenzung auf IP-Ebene verlangsamt einen Angreifer, der eine kleine Anzahl von Adressen verwendet. Die Begrenzung auf Kontoebene stellt sicher, dass selbst ein verteilter Angriff nicht wiederholt einen einzigen Posteingang überfluten kann. Eine vernünftige Anfangsschwelle liegt bei drei bis fünf Rücksetzungsanfragen pro Konto und Stunde. Nach dieser Grenze lehnen Sie neue Anfragen stillschweigend ab: Senden Sie die gleiche konsistente Antwort zurück, ohne eine neue E-Mail zu senden. Sagen Sie dem Benutzer nicht, dass er ein Ratenlimit erreicht hat, da dies Informationen über Ihre Ratenbegrenzungslogik verrät. Begrenzen Sie auch den Endpunkt für die Token-Validierung: Ein Angreifer, der versucht, einen Reset-Token mit rohen Mitteln zu erzwingen, muss viele Token-Versuche übermitteln, und die Ratenbegrenzung dieses Endpunkts beseitigt die Angriffsfläche für kurze Token vollständig.

    • Verwendung kryptografisch starker, kurzlebiger Token für den einmaligen Gebrauch

      Reset-Tokens sind die Schlüssel zu den Konten Ihrer Nutzer. Generieren Sie sie mit einem kryptografisch sicheren Zufallszahlengenerator, nicht mit einem Zeitstempel, nicht mit einer sequenziellen ID, nicht mit einem Hash aus vorhersehbaren Eingaben. NIST SP 800-63B empfiehlt eine Entropie von mindestens 20 Byte für Rücksetzgeheimnisse, was einem Token von mindestens 40 Hex-Zeichen oder einer entsprechenden Base64-Kodierung entspricht. Legen Sie eine kurze Gültigkeitsdauer fest: eine Stunde ist für die meisten Anwendungen großzügig bemessen; 15 bis 30 Minuten sind für Kontexte mit höherer Sicherheit angemessen. Lassen Sie das Token sofort nach seiner Verwendung ablaufen: Ein Token, das nach dem Zurücksetzen des Passworts gültig bleibt, ist eine dauerhafte Hintertür. Lassen Sie auch alle anderen aktiven Token für dieses Konto verfallen, wenn eine neue Rücksetzung angefordert wird: Wenn ein Angreifer eine neue Rücksetzung auslöst, nachdem der Benutzer bereits eine erhalten hat, sollte das alte Token nicht mehr funktionieren.

    • Verhindern von Token-Lecks durch Referrer-Header und Caching

      Rücksetzungs-Tokens, die in URLs übermittelt werden, sind mit einem besonderen Risiko behaftet: Das Token kann über den HTTP-Referrer-Header durchsickern, wenn die Rücksetzungsseite externe Ressourcen enthält (Analyseskripte, Schriftarten, CDN-Assets oder Bilder von Drittanbietern). Wenn ein Benutzer auf einen Link auf Ihrer Reset-Seite klickt, kann der Browser die vollständige URL (einschließlich des Tokens) als Referrer an externe Server senden. Verhindern Sie dies, indem Sie die Referrer-Policy: no-referrer auf Ihrer Bestätigungsseite für das Zurücksetzen einstellen. Setzen Sie außerdem entsprechende Cache-Control-Header, um zu verhindern, dass zurückgesetzte URLs im Browserverlauf oder in Proxy-Caches gespeichert werden. Weisen Sie die Anwendung an, zurückgesetzte Token-Werte nicht in Zugriffsprotokollen oder Fehlerverfolgungssystemen zu protokollieren, da diese in Produktionsumgebungen eine häufige Quelle für die unbeabsichtigte Offenlegung von Token sind.

    • Ersetzen Sie Sicherheitsfragen durch verifizierte Sekundärkanäle

      Sicherheitsfragen sind keine sichere Wiederherstellungsmethode. Die Antworten auf gängige Sicherheitsfragen (Mädchenname der Mutter, Haustier aus der Kindheit, erste Schule) sind häufig über soziale Medien, Datenmakler oder gezielte Recherchen öffentlich zugänglich. Sie erwecken den Anschein einer Verifizierung, ohne dass dies der Fall ist. Ersetzen Sie Sicherheitsfragen durch verifizierte Sekundärkanäle: E-Mail an eine bei der Registrierung bestätigte Adresse oder App-basierte TOTP-Codes. Wenn eine SMS-basierte Wiederherstellung unvermeidlich ist, sollten Sie sich darüber im Klaren sein, dass der SIM-Tausch für hochwertige Konten anfällig ist. Für Konten, bei denen viel auf dem Spiel steht (Administratorenzugang, Zahlungsdaten, Gesundheitsdaten), sollten Sie einen zweiten verifizierten Kanal und nicht nur einen einzigen Wiederherstellungspfad vorsehen.

    • Benutzer benachrichtigen und auf anomale Rücksetzmuster überwachen

      Senden Sie den Nutzern eine Benachrichtigung, wenn eine Rücksetzung angefordert wird, nicht nur, wenn sie abgeschlossen ist. Eine Nachricht wie “Ein Passwort-Reset wurde für Ihr Konto angefordert. Wenn Sie das nicht waren, können Sie diese E-Mail ignorieren - Ihr Passwort hat sich nicht geändert” gibt den Benutzern die Möglichkeit zu reagieren, bevor ein Angreifer ein gestohlenes Token verwendet. Auf der Überwachungsseite ist ein plötzlicher Anstieg der Rücksetzanfragen ein frühes Signal für eine Enumeration- oder Flooding-Kampagne. Setzen Sie Alarme für ungewöhnliche Rücksetzungsvolumen pro IP, pro Konto oder für die gesamte Anwendung. Korrelieren Sie Rücksetzungsspitzen mit Fehlermustern bei der Anmeldung: Angreifer testen oft aufgezählte Konten auf der Anmeldeseite, bevor sie zum Rücksetzungsfluss wechseln, wenn sie dort auf Ratenbegrenzungen oder CAPTCHA stoßen.

    Das Minimum an praktikablen Sicherheitsmaßnahmen für das Zurücksetzen

    Wenn Sie nur drei Dinge implementieren: konsistente Antworten (Verteidigung 1), CAPTCHA auf dem Rücksetzungsformular (Verteidigung 2) und kurzlebige Einmal-Tokens (Verteidigung 4), schließen Sie die am häufigsten ausgenutzten Rücksetzungsschwachstellen. Fügen Sie die anderen nach und nach hinzu, je nachdem, wie sensibel die Konten sind, die Sie schützen.

    Wo CAPTCHA in den Passwort-Rücksetzschutz passt

    CAPTCHA auf dem Formular zum Zurücksetzen von Passwörtern erfüllt eine spezifische und begrenzte Aufgabe: Es verhindert den automatischen Missbrauch des Endpunkts zum Zurücksetzen. Es hindert Bots daran, Tausende von E-Mail-Adressen auf gültige Konten zu prüfen, und es verhindert eine automatische Rücksetzungsflut gegen bestimmte Nutzer. Es behebt nicht die schwache Token-Generierung, verhindert nicht das Durchsickern von Token durch Referrer-Header und ersetzt nicht das einheitliche Antwortdesign.

    Diese Positionierung ist wichtig, weil einige Teams sich entweder zu sehr auf CAPTCHA verlassen (indem sie es als einzige Kontrolle verwenden) oder es zu wenig nutzen (indem sie es auslassen, weil “Benutzer kein Rätsel lösen müssen, um ihr Passwort zurückzusetzen”). Beides geht am Thema vorbei. Ein unsichtbares Proof-of-Work-CAPTCHA verursacht keine sichtbaren Reibungsverluste für legitime Nutzer, die eine Anfrage zum Zurücksetzen des Passworts stellen. Es erhöht nur die Kosten für Bots, die Tausende von Anfragen einreichen. Das ist genau der Punkt, an dem CAPTCHA in die Verteidigungsstrategie gehört.

    Speziell für den WordPress-Reset-Flow ist unser WordPress CAPTCHA Anleitung deckt die Integration auf der Ebene der wp-login.php ab. Für Keycloak erfordert der Fluss zum Zurücksetzen der Anmeldedaten ein separates FTL-Snippet von den Login- und Registrierungsflüssen: unser Leitfaden zur Keycloak-Integration deckt alle drei Abläufe mit spezifischen Konfigurationsschritten ab.

    Missbrauch der Passwortrücksetzung und DSGVO-Verpflichtungen

    Ein erfolgreicher Angriff zum Zurücksetzen des Passworts, der zu einem unbefugten Zugriff auf das Konto führt, stellt eine Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO dar. Wenn das kompromittierte Konto personenbezogene Daten enthielt (was bei fast allen Nutzerkonten der Fall ist), gelten für Sie die Bewertungs- und Meldepflichten gemäß Artikel 33.

    Auch das Rücksetzungsformular selbst hat einen speziellen DSGVO-Blickwinkel. Herkömmliche CAPTCHA-Dienste, die Cookies auf Wiederherstellungsseiten setzen, führen zu einer ePrivacy-Zustimmungspflicht in einem ungünstigen Moment: Ein Nutzer, der den Zugang zu seinem Konto verloren hat, muss nun durch ein Cookie-Zustimmungsbanner navigieren, bevor er es wiederherstellen kann. Ein cookieloses Proof-of-Work-CAPTCHA beseitigt dieses Problem strukturell. Für die CAPTCHA-Schicht selbst ist kein Zustimmungsmechanismus erforderlich, was für die behördlichen Datenschutzbeauftragten, die den Dokumentationsaufwand für die Authentifizierungsabläufe verwalten, eine erhebliche Vereinfachung darstellt.

    Der Blickwinkel von Artikel 32

    Artikel 32 der Datenschutzgrundverordnung verlangt angemessene technische Sicherheitsmaßnahmen. Für jede Website, die personenbezogene Daten hinter Benutzerkonten speichert, wird es immer schwieriger, sich bei einer Überprüfung durch eine Aufsichtsbehörde zu verteidigen, wenn der Rücksetzvorgang nicht geschützt wird. Reset Flooding, Enumeration und Token-Diebstahl sind gut dokumentierte Angriffsmuster mit bekannten Gegenmaßnahmen. Die Umsetzung dieser Maßnahmen ist Teil einer vernünftigen Artikel-32-Strategie.

    Checkliste für die Umsetzung

    Verwenden Sie diese Checkliste, um Ihren aktuellen Rückstellungsablauf zu überprüfen. Die Punkte sind nach der Auswirkung pro Implementierungsaufwand geordnet: Die wichtigsten Punkte bieten den größten Schutz für den geringsten Aufwand.

    • Konsistente Antworten: Vergewissern Sie sich, dass Ihr Rücksetzungsformular für bestehende und nicht bestehende Konten die gleiche Meldung, den gleichen Statuscode und die gleiche Antwortzeit liefert.
    • CAPTCHA auf dem Rücksetzungsformular: Fügen Sie ein unsichtbares Arbeitsnachweis-CAPTCHA zum Formular für die Zurücksetzungsanfrage hinzu. Für WordPress: siehe den WordPress-Leitfaden. Für Keycloak: siehe den Keycloak-Leitfaden.
    • Ratenbegrenzung pro Konto und pro IP: Grenzwerte auf beiden Ebenen anwenden. Stille Ablehnung nach dem Schwellenwert: Das Vorhandensein des Grenzwerts wird nicht angezeigt.
    • Kryptographisch starke Token: Stellen Sie sicher, dass Ihr Token-Generator einen CSPRNG mit einer Entropie von mindestens 20 Byte verwendet. Verwerfen Sie sequenzielle IDs, Zeitstempel und Hash-of-E-Mail-Muster.
    • Ablauf des Tokens: Token verfallen innerhalb einer Stunde nach der Ausgabe. Token verfallen sofort nach Gebrauch. Neue Rücksetzungsanfragen machen alle vorherigen Token für dieses Konto ungültig.
    • Referrer-Policy-Kopfzeile: Satz Referrer-Policy: no-referrer auf Seiten zur Rücksetzbestätigung. Überprüfen Sie alle externen Ressourcen, die auf diesen Seiten geladen werden.
    • Keine Sicherheitsfragen: Ersetzen Sie sie durch eine E-Mail- oder TOTP-basierte Verifizierung. Prüfen Sie alle alten Sicherheitsfragen, die noch in Ihrer Anwendung aktiv sind.
    • Benachrichtigungen über Anfragen zurücksetzen: Senden Sie Benutzern eine E-Mail, wenn eine Rücksetzung ausgelöst wird, und nicht nur, wenn sie abgeschlossen ist.
    • Überwachung und Alarmierung: Legen Sie Warnungen für zurückgesetzte Volumenspitzen pro IP und pro Konto fest. Korrelieren Sie mit Fehlermustern bei der Anmeldung.
    • HTTPS überall bei zurückgesetzten Datenströmen: Stellen Sie sicher, dass alle Rücksetzseiten und Token-Übertragungsendpunkte HTTPS mit aktuellem TLS verwenden. Zurückgesetzte Token, die über HTTP übermittelt wurden, werden zurückgewiesen.

    Häufig gestellte Fragen

    Was ist Missbrauch beim Zurücksetzen von Passwörtern?

    Passwortrücksetzungsmissbrauch ist der Missbrauch eines Kontowiederherstellungsflusses, um sich unbefugten Zugang zu verschaffen, gültige Konten aufzuzählen, Posteingänge zu überfluten oder Wiederherstellungs-Tokens zu stehlen. Er unterscheidet sich vom Passwort-Reset-Poisoning, einer spezifischen technischen Schwachstelle, bei der ein Angreifer manipuliert, wie der Reset-Link generiert wird. Reset-Missbrauch ist die umfassendere Kategorie, die vier verschiedene Angriffsmuster umfasst: Enumeration, Flooding, Token-Diebstahl und schwaches Recovery-Design.

    Was ist der Unterschied zwischen dem Missbrauch des Zurücksetzens von Passwörtern und der Vergiftung durch das Zurücksetzen von Passwörtern?

    Passwort-Reset-Poisoning ist eine spezielle Technik innerhalb der breiteren Kategorie des Reset-Missbrauchs. Poisoning liegt vor, wenn ein Angreifer den HTTP-Host-Header manipuliert, um einen Reset-Link auf eine vom Angreifer kontrollierte Domain umzuleiten. Rücksetzungsmissbrauch umfasst eine breitere Palette von Mustern: Kontenaufzählung durch Antwortunterschiede, Rücksetzungsflut, um Posteingänge zu überschwemmen, Token-Brute-Forcing und Ausnutzung schwacher Wiederherstellungsmethoden wie Sicherheitsfragen oder SMS-Abfangen.

    Verhindert CAPTCHA den Missbrauch beim Zurücksetzen von Passwörtern?

    CAPTCHA stoppt die automatisierten Missbrauchsmuster: Reset Flooding und groß angelegte Kontoaufzählung. Es behebt nicht die schwache Token-Generierung, verhindert nicht die Weitergabe von Token durch Referrer-Header und ersetzt nicht ein konsistentes Antwortdesign. Verwenden Sie CAPTCHA als eine Schicht in einem breiteren Reset-Sicherheitsstapel, nicht als einzige Kontrolle.

    Wie können Angreifer Konten über das Rücksetzungsformular aufzählen?

    Wenn Ihr Rücksetzungsformular unterschiedliche Antworten für vorhandene und nicht vorhandene Konten zurückgibt (unterschiedliche Nachrichtentexte, unterschiedliche HTTP-Statuscodes oder messbar unterschiedliche Antwortzeiten), kann ein Angreifer Rücksetzungsanfragen für eine Liste von E-Mail-Adressen übermitteln und beobachten, welche davon die Antwort “Konto gefunden” zurückgeben. Auf diese Weise lässt sich der Bestand an registrierten Benutzern aufdecken, ohne dass ein Passwort geknackt werden muss. Die Lösung besteht darin, immer die gleiche Antwort zu geben, unabhängig davon, ob das Konto existiert.

    Wie lange sollte ein Reset-Token gültig sein?

    Eine Stunde ist für die meisten Anwendungen eine angemessene Höchstdauer. Für sicherere Kontexte (Finanzkonten, Gesundheitswesen, administrativer Zugang) sind 15 bis 30 Minuten angemessener. Das Token sollte unmittelbar nach der Verwendung ablaufen, und alle früheren Token für ein Konto sollten ungültig gemacht werden, wenn eine neue Rücksetzung angefordert wird. Token, die nach der Verwendung gültig bleiben, stellen eine dauerhafte Hintertür dar.

    Ist das Zurücksetzen von Passwörtern ein DSGVO-Problem?

    Ja, in zweierlei Hinsicht. Erstens ist ein erfolgreicher Angriff, der zu einem unbefugten Zugriff auf das Konto führt, eine Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO, die eine Bewertung nach Artikel 33 und potenzielle Meldepflichten auslöst. Zweitens führen Cookie-basierte CAPTCHA auf Wiederherstellungsseiten dazu, dass sich die Nutzer in einem schwierigen Moment die Frage nach ihrer Einwilligung in den Datenschutz stellen. Mit einem CAPTCHA ohne Cookies entfällt diese Zustimmungspflicht im Wiederherstellungsprozess vollständig.

    Verwandte Lektüre

    Primäre Quellen

    OWASP Spickzettel für vergessene PasswörterKonsistente Antworten, sicheres Token-Design und Empfehlungen zur Ratenbegrenzung
    OWASP-Authentifizierungs-SpickzettelRe-Authentifizierung und sichere Authentifizierungsverfahren
    PortSwigger Web-Sicherheitsakademie: Passwort-Reset-Vergiftung: technische Details zur Ausnutzung des Host-Headers in zurückgesetzten Strömen
    NIST SP 800-63BAnleitung zu gespeicherten geheimen Authentifikatoren und Anforderungen an die Rücksetzung der geheimen Entropie
    OWASP-Testleitfaden: Schwache Passwort-Reset-Funktionalitäten
    CAPTCHA.eu: Was ist Password Reset Poisoning?Definition und Unterscheidung zwischen Vergiftung und Rücksetzungsmissbrauch im weiteren Sinne
    CAPTCHA.eu: Wie man Kontoübernahme-Angriffe verhindert: breiterer Kontext der Autorensicherheit, einschließlich Rücksetzungsströme

    kürzliche Posts

    de_DEGerman
    en_USEnglish fr_FRFrench es_ESSpanish nl_NLDutch it_ITItalian de_DEGerman