Eine Uhr, kein Rätsel.
Time-to-Pass.
Kommt die Lösung einer Prüfung schneller zurück, als es plausibel ist, nimmt der Server sie nicht an. Auch dann nicht, wenn sie rechnerisch stimmt.
Stand: August 2026
Eine Uhr, kein Rätsel. Der Besucher sieht davon nichts.
- Bewertet wird
- Die Spanne zwischen Ausgabe der Prüfung und Eingang der Lösung.
- Abgelehnt wird
- Jede Lösung, die vor Ablauf der Mindestzeit eintrifft. Auch eine korrekte.
- Nicht bewertet wird
- Der Inhalt der Formularfelder. In die Rechnung gehen nur zwei Zeitpunkte ein.
- Entschieden wird
- Auf dem Server. Ein Client kann die Ablehnung nicht überstimmen.
Was ist Time-to-Pass?
Eine Mindestzeit zwischen Ausgabe und Annahme.
Der Server weiß, wann er eine Prüfung ausgegeben hat. Trifft die Lösung ein, bevor die Mindestzeit vergangen ist, lehnt er sie ab, auch wenn sie stimmt. Bewertet wird eine Zeitspanne, sonst nichts.
Wichtiger ist, was dabei nicht passiert. Time-to-Pass misst nicht, wie lange jemand an einem Formular gesessen hat, und liest keine Eingaben mit. Es geht um das Alter der Prüfung in dem Moment, in dem ihre Lösung ankommt. Zwei Zeitpunkte, eine Subtraktion.
Lösung in üblicher Zeit
Angenommen
- Mindestzeit vergangen
- Lösung gültig
- Token wird ausgegeben
Lösung sofort nach Ausgabe
Abgelehnt
- Mindestzeit nicht erreicht
- Lösung wird abgewiesen
- Kein Token
Beispielhafte Darstellung. Die Ablehnung erfolgt unabhängig davon, ob die Lösung rechnerisch stimmt.
Warum lehnt der Server eine zu frühe Lösung ab?
Weil eine Mindestzeit den Durchsatz deckelt.
Wer zehntausend gültige Tokens will, braucht zehntausend Prüfungen, und jede davon hat eine Untergrenze. Ein Besucher bemerkt sie nicht, weil die Seite in dieser Zeit ohnehin lädt und er sie liest.
Der Preis dieser Bremse gehört dazu. Warten kostet einen Angreifer Zeit, nicht Zugang. Wer parallel arbeitet, holt einen Teil davon zurück, denn die Mindestzeit gilt je Prüfung und nicht für die Summe aller Prüfungen. Genau deshalb trägt sie keine Entscheidung allein.
Ist das eine neue Idee?
Nein. Zeitfenster gegen Formular-Spam sind alt.
Das Drupal-Modul Honeypot verlangt in der Voreinstellung mindestens fünf Sekunden, bevor ein Formular angenommen wird. OWASP führt die zugehörige Angriffsart in seiner Systematik automatisierter Bedrohungen als OAT-017 Spamming.
Die Moduldokumentation formuliert es so:„Honeypot requires at least 5 seconds to pass (by default) before the form can be successfully submitted.“ OWASP beschreibt OAT-017 als „Malicious or questionable information addition to public or private content, or messages.“
Der Unterschied liegt darin, wo die Uhr steht. Klassische Zeitfenster sitzen im Formular der jeweiligen Anwendung, also dort, wo jeder Betreiber sie selbst bauen und pflegen muss. Bei einem CAPTCHA-Dienst gehört sie zur Prüfung, gilt für jedes eingebundene Formular und lässt sich an einer Stelle ändern.
Wie ist Time-to-Pass bei ByeBot eingestellt?
Je Site im Dashboard.
Die Prüfung lässt sich an- und abschalten. Im festen Modus geben Sie die Mindestzeit vor, im automatischen Modus setzt der Dienst sie. Welchen Wert er dabei wählt, veröffentlichen wir nicht.
- Zustand
- An oder aus.
- Betriebsart
- Fester Wert oder automatisch.
- Geltung
- Je Site, im Dashboard.
- Durchsetzung
- Auf dem Server, beim Einlösen der Lösung.
Echte Aufnahme des laufenden Dashboards. Gezeigt ist der feste Modus eines Testkontos mit Demo-Daten: die Millisekunden auf dem Regler hat dort jemand eingestellt, sie sind nicht der Wert, den der Dienst im automatischen Modus wählt.
Durchgesetzt wird die Mindestzeit auf dem Server. Ein Client, der sie ignoriert, bekommt kein Token, sondern eine Ablehnung. Aus demselben Grund wird der ausgelieferte Client-Code laufend neu generiert und obfuskiert: Was im Browser läuft, ist Arbeit, keine Entscheidung.
- Prüfung ausgegeben
- Besucher löst
- Lösung trifft ein
Serverprüfung
Deutschland
Angenommen
- Mindestzeit erreicht
- Lösung gültig
Abgelehnt
- Zu früh eingetroffen
Was Time-to-Pass nicht leistet.
Es entfernt keinen Angreifer. Es verlangsamt ihn.
Drei Grenzen gehören zu jeder ehrlichen Beschreibung des Verfahrens.
- Warten ist billig
- Ein Skript kann die Mindestzeit abwarten. Das kostet Durchsatz, nicht Zugang.
- Kein Beweis
- Eine früh eintreffende Lösung ist ein Indiz. Deshalb steht die Mindestzeit neben anderen Prüfungen und nicht allein.
- Keine Hilfe gegen Handarbeit
- Wer Menschen für das Lösen bezahlt, wartet die Mindestzeit einfach mit ab.
Das ist derselbe Gedanke wie beim Rechennachweis, nur in einer anderen Währung. Der eine kostet Rechenzeit, der andere Wartezeit. Beide machen ein einzelnes Absenden unauffällig teuer und zehntausend Absendungen auffällig teuer. Ein Sicherheitsforscher hat im März 2026 vorgeführt, wie schnell eine einzelne Hürde im Browser fällt, wenn sie allein steht. Genau deshalb steht hier keine allein.
Fragen zur Mindestzeit.
Kurze Antworten. Wo das Verfahren an eine Grenze stößt, steht das hier ebenfalls.
Was geht in die Zeitrechnung ein?
Zwei Zeitpunkte: die Ausgabe der Prüfung und der Eingang ihrer Lösung. Bewertet wird die Spanne dazwischen, eine Subtraktion. Wie lange jemand an einem Formular gesessen hat, geht in diese Rechnung nicht ein, und der Inhalt der Formularfelder auch nicht.
Merkt ein Besucher die Wartezeit?
Ein Besucher bemerkt sie nicht, weil die Seite in dieser Zeit ohnehin lädt und er sie liest. Auffällig wird die Untergrenze erst in der Masse: Wer zehntausend gültige Tokens will, braucht zehntausend Prüfungen, und jede davon hat eine Untergrenze.
Kann ein Bot die Mindestzeit im Browser einfach überspringen?
Überspringen nicht, denn durchgesetzt wird die Mindestzeit auf dem Server, beim Einlösen der Lösung. Ein Client, der sie ignoriert, bekommt kein Token, sondern eine Ablehnung. Abwarten kann ein Skript sie dagegen sehr wohl, und das kostet es Durchsatz, nicht Zugang.
Hilft eine Mindestzeit gegen bezahlte CAPTCHA-Löser?
Nein. Wer Menschen für das Lösen bezahlt, wartet die Mindestzeit einfach mit ab. Sie entfernt keinen Angreifer, sie verlangsamt ihn. Deshalb ist eine früh eintreffende Lösung ein Indiz und kein Beweis, und deshalb steht die Mindestzeit neben anderen Prüfungen und nicht allein.
Kann ich ein Zeitfenster nicht selbst in mein Formular bauen?
Klassische Zeitfenster sitzen genau dort. Das Drupal-Modul Honeypot verlangt in der Voreinstellung mindestens fünf Sekunden, bevor ein Formular angenommen wird. Der Unterschied liegt darin, wo die Uhr steht: im Formular baut und pflegt sie jeder Betreiber selbst, bei einem CAPTCHA-Dienst gehört sie zur Prüfung und gilt für jedes eingebundene Formular.
Was unterscheidet Time-to-Pass vom Rechennachweis?
Die Währung. Der eine kostet Rechenzeit, der andere Wartezeit. Der Gedanke dahinter ist derselbe: Beide machen ein einzelnes Absenden unauffällig teuer und zehntausend Absendungen auffällig teuer. Ein Sicherheitsforscher hat im März 2026 vorgeführt, wie schnell eine einzelne Hürde im Browser fällt, wenn sie allein steht.
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.