Token prüfen, dann Passwort prüfen.
Login-Schutz.
Am Login zahlen Sie jeden Versuch mit, auch den, der scheitert. Deshalb gehört die Prüfung davor und nicht danach.
Stand: August 2026
Wie sehen automatisierte Anmeldeversuche aus?
Wie normale Anmeldungen, nur sehr viele.
Die Versuche gehen direkt an die Adresse, an die Ihr Formular sendet. Sie kommen aus vielen Adressen, oft eine Anfrage je Adresse, und sie hören nicht auf, wenn sie scheitern. Auffällig ist nie der einzelne Versuch, auffällig ist die Summe über den Tag.
- Echter Nutzer
- Zugangsdatenliste
- Passwortraten
- Massenanfragen
ByeBot-Prüfung
vor dem Passwort
Bestanden
- Ihr Server prüft das Passwort
- Danach zweiter Faktor
Nicht bestanden
- Kein gültiges Token
- Passwort wird nicht geprüft
- Kein Fehlversuch am Konto
Vereinfachte Darstellung. Welche Prüfungen laufen, stellen Sie je Seite ein.
- Verteilt
- Die Versuche kommen aus vielen Adressen gleichzeitig, oft eine Anfrage je Adresse. Eine Sperrliste greift dann kaum.
- Unauffällig
- Jede einzelne Anfrage sieht aus wie eine normale Anmeldung. Auffällig ist erst die Summe.
- Ausdauernd
- Der Verkehr hört nicht auf, wenn er scheitert. Er läuft weiter, solange er billig ist.
- Zielgenau
- Angesprochen wird die Adresse, an die Ihr Formular sendet, nicht die Anmeldeseite.
Was kosten Anmeldeversuche, die ohnehin scheitern?
Rechenzeit bei Ihnen und Sperren bei Ihren Nutzern.
Ein Fehlversuch ist nicht folgenlos. Er löst eine Passwortprüfung aus, die absichtlich langsam rechnet, er erhöht einen Fehlerzähler und er kann am Ende ein Konto sperren, das dem Angreifer gar nicht gehört.
Das ist der Grund, warum Begrenzung allein unangenehm ist. NIST beschreibt in SP 800-63B-4 in Abschnitt 3.2.2 eine Obergrenze für aufeinanderfolgende Fehlversuche:„the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator“. Im selben Abschnitt steht unter den ergänzenden Maßnahmen, mit denen sich das Risiko einer Sperre für echte Nutzer senken lässt:„Requiring the claimant to complete a bot detection and mitigation challenge before attempting authentication“. Genau diese Reihenfolge beschreibt diese Seite.
- Rechenzeit
- Jeder Versuch löst bei Ihnen eine Passwortprüfung aus. Ein sicher gewähltes Passwortverfahren ist absichtlich langsam, und genau das bezahlen Sie pro Versuch.
- Kontosperren
- Wer Fehlversuche je Konto begrenzt, sperrt bei fremdem Verkehr die eigenen Nutzer aus.
- Support
- Jede unverschuldete Sperre wird ein Anruf oder ein Ticket.
- Protokolle
- Fehlversuche in dieser Größenordnung machen die eigenen Sicherheitsprotokolle unlesbar.
- Zahlen
- In Ihrer Auswertung stehen bestandene und abgewiesene Prüfungen je Tag. Zu den Statistiken Mehr dazu ›
In welcher Reihenfolge prüft der Server?
Token, dann Passwort.
Wer das Passwort zuerst prüft, hat die teure Arbeit schon geleistet, bevor die billige Prüfung greift. Steht die Tokenprüfung davor, kostet ein Versuch ohne gültiges Token bei Ihnen fast nichts und erhöht auch keinen Fehlerzähler am fremden Konto.
- Schritt 1Token bei ByeBot prüfen. Antwort 400 heißt: abbrechen, ohne das Passwort anzusehen.
- Schritt 2Erst danach Benutzer und Passwort prüfen.
- Schritt 3Fehlversuche je Konto zählen und begrenzen.
- Schritt 4Zweiten Faktor abfragen, wenn Sie einen anbieten.
- Schritt 5Sitzung ausstellen.
Die Prüfung im Browser entscheidet nichts. Entschieden wird auf Ihrem Server, in dieser Reihenfolge.
- Widget-Modusunsichtbar
- Rechenaufgabean
- Time-to-Pass1 s
- Ratelimit je Besucher10 / 5 min
- Sperrlisteaktiv
Beispielhafte Werte. Jede Seite hat ihren eigenen Sitekey und ihre eigenen Werte.
Echte Aufnahme des laufenden Dashboards. Die Einträge sind Demo-Daten: die drei Bereiche sind für Dokumentation reserviert und gehören niemandem.
- Unsichtbar
- Ein Login ist ein täglicher Vorgang. Jede zusätzliche Handlung wird täglich bezahlt, von Menschen, die nichts falsch gemacht haben.
- Rechenaufgabe
- Sie verschiebt einen Teil der Kosten auf die Gegenseite. Ein Nutzer löst eine Aufgabe pro Anmeldung, eine Liste mit hunderttausend Zugangsdaten braucht hunderttausend.
- Time-to-Pass
- Eine Mindestzeit zwischen der Ausgabe einer Prüfung und der Annahme ihrer Lösung. Im unsichtbaren Modus beginnt sie beim Laden der Anmeldeseite, deshalb reicht am Login ein kurzer Wert.
- Ratelimit
- Greift vor der Prüfung. Wer darüber liegt, bekommt keine Aufgabe und zählt nicht gegen Ihr Kontingent.
- Regeln je Seite
- Zur Zugriffskontrolle
Wie binden Sie die Prüfung in ein Login-Formular ein?
Div ins Formular, Tokenprüfung an den Anfang der Anmelderoutine.
Der Sitekey steht öffentlich im Quelltext, der API-Key bleibt auf dem Server. Prüfen Sie das Token niemals im Browser: Alles, was im Browser entschieden wird, entscheidet am Ende der, dem der Browser gehört.
<script src="https://challenge.byebot.de/ray/widget.js" defer></script>
<form method="post" action="/login">
<input name="benutzer" autocomplete="username" required />
<input name="passwort" type="password" autocomplete="current-password" required />
<div class="captcha-widget" data-sitekey="IHR_SITEKEY"></div>
<button type="submit">Anmelden</button>
</form>Im unsichtbaren Modus bleibt das Div leer und trägt nur den Sitekey.
POST https://challenge.byebot.de/validate_token
Content-Type: application/json
{
"api_key": "IHR_API_KEY",
"token": "Wert des Feldes byebot-token"
}Antwort 200 heißt weiter, Antwort 400 heißt abbrechen.
- Eigene Seite
- Legen Sie für das Login-Formular eine eigene Seite im Dashboard an. So gelten Modus, Time-to-Pass und Ratelimit nur dort und nicht auch im Kontaktformular.
- Div ins Formular
- Im unsichtbaren Modus bleibt das Div leer und trägt nur den Sitekey.
- Token zuerst
- Rufen Sie /validate_token auf, bevor Sie Benutzer und Passwort ansehen. Antwort 200 heißt weiter, 400 heißt abbrechen.
- Antwort gleich halten
- Geben Sie bei fehlendem Token dieselbe allgemeine Fehlermeldung aus wie bei einem falschen Passwort. Sonst verrät die Antwort, welche Hürde gerade gegriffen hat.
- Dokumentation
- Vollständige Anleitung
Eine Grenze gehört dazu: Eine Prüfung vor dem Passwort verteuert automatisierte Anmeldeversuche, sie beendet sie nicht. Sie ersetzt auch keinen zweiten Faktor und keine Regel für Fehlversuche je Konto. Sie sorgt dafür, dass diese beiden seltener gebraucht werden. Wie die einzelnen Prüfungen arbeiten, steht unter Bot-Erkennung. Der Fall mit erbeuteten Zugangsdaten ist unter Credential Stuffing beschrieben, das reine Raten unter Brute-Force.
Fragen zum Schutz von Anmeldeformularen.
Kurze Antworten zu Reihenfolge, Zählweise und Grenzen. Wo die Prüfung nichts leistet, steht das hier ebenfalls.
Erhöht ein Versuch ohne gültiges Token den Fehlerzähler am Konto?
Nein, wenn die Tokenprüfung vor der Passwortprüfung steht. Eine Anfrage ohne gültiges Token wird abgebrochen, bevor Benutzer und Passwort angesehen werden. Der Zähler für Fehlversuche je Konto läuft auf Ihrem Server und wird erst von einem Versuch berührt, der bis zur Passwortprüfung kommt.
Sehen Ihre Nutzer beim Anmelden ein CAPTCHA?
Im unsichtbaren Modus nicht. Das Div im Formular bleibt leer und trägt nur den Sitekey. Ein Login ist ein täglicher Vorgang, und jede zusätzliche Handlung wird täglich bezahlt, von Menschen, die nichts falsch gemacht haben. Für das Login-Formular schlägt diese Seite den unsichtbaren Modus vor.
Was schreibt NIST zu Fehlversuchen bei der Anmeldung?
NIST SP 800-63B-4 nennt in Abschnitt 3.2.2 eine Obergrenze von 100 aufeinanderfolgenden Fehlversuchen je Authentifikator und Konto, danach wird der Authentifikator deaktiviert. Im selben Abschnitt steht unter den ergänzenden Maßnahmen, mit denen sich das Risiko einer Sperre für echte Nutzer senken lässt, eine Bot-Erkennung vor dem Anmeldeversuch.
Zählen vorab abgewiesene Anfragen gegen mein Kontingent?
Vorab abgewiesene nicht. Berechnet wird jede Prüfung, die bis zur Verifikation kommt, bestanden wie nicht bestanden. Wer über dem Ratelimit je Besucher liegt, bekommt keine Aufgabe und zählt nicht mit; Abweisungen durch Sperrliste, Länderfilter oder Ratenbegrenzung werden nicht berechnet. In Ihrer Auswertung stehen bestandene und abgewiesene Prüfungen je Tag.
Ersetzt eine Prüfung vor dem Passwort den zweiten Faktor?
Nein. Eine Prüfung vor dem Passwort verteuert automatisierte Anmeldeversuche, sie beendet sie nicht. Sie ersetzt auch keinen zweiten Faktor und keine Regel für Fehlversuche je Konto. Sie sorgt dafür, dass diese beiden seltener gebraucht werden. Auf dem Server steht der zweite Faktor als eigener Schritt nach der Passwortprüfung.
Kann das Token im Browser geprüft werden?
Nein. Prüfen Sie das Token auf Ihrem Server. Alles, was im Browser entschieden wird, entscheidet am Ende der, dem der Browser gehört. Der Sitekey steht öffentlich im Quelltext, der API-Key bleibt auf dem Server. Der Aufruf von /validate_token gehört an den Anfang der Anmelderoutine: Antwort 200 heißt weiter, Antwort 400 heißt abbrechen.
Sieben Tage testen, dann entscheiden.
Ein Zahlungsmittel wird zu Beginn hinterlegt. In der Testphase liegt die Grenze bei 10.000 Prüfungen. Danach ab 19 € im Monat.