Anwendungsfall Brute-Force.
Brute-Force.
Durchprobieren funktioniert, solange ein Versuch nichts kostet. Der Hebel liegt deshalb nicht beim einzelnen Versuch, sondern bei seinem Preis.
Stand: August 2026
Was wird bei Brute-Force durchprobiert?
Alles, was kurz ist und ein Ja oder Nein zurückgibt.
Passwörter sind der bekannte Fall, aber nicht der einzige. Rücksetzlinks, Einmalcodes, Einladungslinks und Gutscheincodes sind ebenfalls kurz und geben eine eindeutige Antwort. Wo eine Antwort eindeutig ist und ein Versuch nichts kostet, wird durchprobiert.
- Passwortliste
- Codes nach Muster
- Rücksetzlinks
- Tippfehler eines Nutzers
Ratelimit und Prüfung
je Versuch
Bestanden
- Ihr Server prüft den Wert
- Ein Fehlversuch bleibt ein Fehlversuch
Abgewiesen
- Über der Obergrenze
- Kein Rätsel wird ausgeliefert
- Zählt nicht gegen Ihr Kontingent
Vereinfachte Darstellung. Obergrenze und Zeitfenster stellen Sie je Seite ein.
- Passwörter
- Ein Konto, viele Kandidaten. Meist keine Zufallszeichen, sondern eine Liste aus früheren Datenabflüssen.
- Zugangscodes
- Einmalcodes, Rücksetzlinks und Einladungslinks sind kurz genug, dass sich Durchprobieren lohnt.
- Gutscheincodes
- Kurze Codes nach festem Muster lassen sich erzeugen und der Reihe nach ausprobieren.
- Benutzernamen
- Manchmal wird gar kein Passwort gesucht, sondern nur die Antwort auf die Frage, welche Konten es gibt.
- Erkennbar
- An der Gleichförmigkeit: gleiches Formular, gleicher Takt, wechselnder Wert in genau einem Feld.
Warum wirkt ein Preis je Versuch?
Weil sich der Preis mit der Zahl der Versuche multipliziert.
Ein Mensch tippt sein Passwort zwei- oder dreimal falsch. Ein Skript arbeitet eine Liste ab. Beide zahlen denselben Preis je Versuch, und genau daraus entsteht der Unterschied. Für den einen ist es ein Wimpernschlag, für den anderen eine Rechnung.
Beispielhafte Größenordnungen zur Veranschaulichung, keine Messung. Der Preis je Versuch bleibt gleich, die Summe nicht.
Für die Passwortseite dieses Falls gibt es eine Obergrenze aus einer öffentlichen Quelle. NIST schreibt in SP 800-63B-4, Abschnitt 3.2.2, vor, aufeinanderfolgende Fehlversuche eines Authentifikators an einem Konto auf höchstens 100 zu begrenzen. Diese Grenze gilt je Konto. Sie hilft gegen das Durchprobieren an einem Konto und nichts gegen verteilte Versuche an vielen Konten. Der Fall steht unter Erbeutete Zugangsdaten.
- Preis je Versuch
- Eine Rechenaufgabe kostet pro Versuch dasselbe. Bei drei Versuchen fällt das nicht auf, bei hunderttausend schon.
- Vor Ihrer Last
- Wer das Ratelimit reißt, bekommt keine Aufgabe und löst bei Ihnen keine Passwortprüfung aus.
- Ihre Rechnung
- Abweisungen durch Ratelimit, Sperrliste oder Länderblock erscheinen in der Statistik als blockiert und zählen nicht gegen Ihr Kontingent.
- Ihre Nutzer
- Wer sein Passwort einmal falsch tippt, merkt von alldem nichts.
Welche Einstellungen passen zu einem Formular unter Beschuss?
Ratelimit eng, Rechenaufgabe an, Kästchen sichtbar.
Das Ratelimit greift vor der Prüfung und ist deshalb das billigste Instrument. Die Rechenaufgabe legt auf jeden Versuch, der durchkommt, einen festen Preis. Das sichtbare Kästchen ist an dieser Stelle vertretbar, weil ein Formular unter Beschuss ohnehin schon Aufmerksamkeit kostet.
- Widget-ModusKästchen zum Anklicken
- Rechenaufgabean
- Time-to-Pass2 s
- Ratelimit je Besucher5 / 10 min
- Sperrlisteaktiv
Beispielhafte Werte. Jede Seite hat ihren eigenen Sitekey und ihre eigenen Werte.
Echte Aufnahme des laufenden Dashboards. Die Werte stammen aus einem Testkonto mit Demo-Daten.
- Ratelimit zuerst
- Die direkteste Antwort auf Wiederholung. Es greift vor der Prüfung, kostet Sie nichts und ist je Seite einstellbar.
- Rechenaufgabe
- Sie legt auf jeden Versuch einen festen Preis. Lösen ist teuer, Prüfen ist billig, und diese Schieflage ist das ganze Verfahren.
- Sichtbares Kästchen
- Am Login mit erhöhtem Risiko ist ein Klick vertretbar. Wer keine Reibung will, nimmt den unsichtbaren Modus und behält Ratelimit und Rechenaufgabe.
- Sperrliste
- Gegen Wiederholungstäter aus einem festen Adressbereich. Gegen ständig wechselnde Adressen richtet sie wenig aus.
- Rechenaufwand im Detail
- Zu Proof of Work
Wie binden Sie das ein?
Ratelimit im Dashboard, Tokenprüfung vor der teuren Prüfung.
Der Sitekey steht im Quelltext, der API-Key bleibt auf dem Server. Antwort 200 heißt weiter, Antwort 400 heißt abbrechen, und zwar bevor Ihr Server anfängt, ein Passwort nachzurechnen.
<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>Für den unsichtbaren Modus bleibt dasselbe Div leer. Ratelimit und Rechenaufgabe wirken in beiden Fällen.
- Eigene Seite
- Für das betroffene Formular eine eigene Seite im Dashboard anlegen, damit strengere Werte nur dort gelten.
- Ratelimit setzen
- Obergrenze und Zeitfenster je Besucher eintragen. Beginnen Sie großzügig und ziehen Sie an, wenn die Statistik es hergibt.
- Token zuerst
- Die Tokenprüfung an den Anfang der Routine setzen, vor die teure Prüfung des Passworts oder des Codes.
- Gleiche Antwort
- Bei fehlendem Token dieselbe allgemeine Fehlermeldung ausgeben wie bei einem falschen Wert. Unterschiedliche Antworten sind selbst eine Auskunft.
- Dokumentation
- Vollständige Anleitung
Die Grenze des Verfahrens gehört dazu. Wer die Rechenaufgabe immer schwerer macht, trifft damit auch alte Telefone und schwache Geräte, nicht allein schnelle Rechner. Dieses Rennen lässt sich nicht gewinnen, sondern nur vernünftig einstellen. Ein Preis je Versuch verteuert das Durchprobieren, er beendet es nicht, und er ersetzt weder gute Passwortregeln noch einen zweiten Faktor. Die ausführliche Fassung steht unter Proof of Work.
Fragen zu Brute-Force.
Kurze Antworten mit Quelle. Wo das Verfahren an seine Grenze kommt, steht das hier ebenfalls.
Hilft die NIST-Grenze auch gegen verteilte Versuche?
Nein, sie gilt je Konto. NIST SP 800-63B-4, Abschnitt 3.2.2, verlangt, aufeinanderfolgende Fehlversuche eines Authentifikators an einem Konto auf höchstens 100 zu begrenzen. Das hilft gegen das Durchprobieren an einem Konto und nichts gegen verteilte Versuche an vielen Konten. Dieser Fall steht auf einer eigenen Seite unter Erbeutete Zugangsdaten.
Zählen abgewiesene Anfragen gegen mein Kontingent?
Nein. Abweisungen durch Ratelimit, Sperrliste oder Länderblock erscheinen in der Statistik als blockiert und zählen nicht gegen Ihr Kontingent. Berechnet wird eine Prüfung, die bis zur Verifikation kommt, bestanden oder nicht bestanden. Wer das Ratelimit reißt, bekommt keine Aufgabe und löst bei Ihnen auch keine Passwortprüfung aus.
Hilft eine Sperrliste gegen ständig wechselnde Adressen?
Nur begrenzt. Die Sperrliste wirkt gegen Wiederholungstäter aus einem festen Adressbereich. Gegen ständig wechselnde Adressen richtet sie wenig aus. Das Ratelimit greift dagegen vor der Prüfung, kostet Sie nichts und ist je Seite einstellbar. Die Rechenaufgabe legt auf jeden Versuch, der durchkommt, einen festen Preis.
Geht das auch ohne sichtbares Kästchen?
Ja. Wer keine Reibung will, nimmt den unsichtbaren Modus und behält Ratelimit und Rechenaufgabe. Im HTML bleibt dasselbe Div dann leer, Ratelimit und Rechenaufgabe wirken in beiden Fällen. Am Login mit erhöhtem Risiko ist ein Klick vertretbar, weil ein Formular unter Beschuss ohnehin schon Aufmerksamkeit kostet.
Warum dieselbe Fehlermeldung bei fehlendem Token?
Weil unterschiedliche Antworten selbst eine Auskunft sind. Bei fehlendem Token gibt die Routine dieselbe allgemeine Fehlermeldung aus wie bei einem falschen Wert. Manchmal wird gar kein Passwort gesucht, sondern nur die Antwort auf die Frage, welche Konten es gibt.
Beendet ein Preis je Versuch das Durchprobieren?
Nein. Ein Preis je Versuch verteuert das Durchprobieren, er beendet es nicht, und er ersetzt weder gute Passwortregeln noch einen zweiten Faktor. Wer die Rechenaufgabe immer schwerer macht, trifft damit auch alte Telefone und schwache Geräte. Dieses Rennen lässt sich nicht gewinnen, sondern nur vernünftig einstellen.
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.