Im Vergleich
CAPTCHA oder Honeypot für die Registrierung
Ein Honeypot erkennt Skripte, die ein Köderfeld ausfüllen, ohne Besuchern eine Aufgabe zu stellen. Ein CAPTCHA prüft eine zusätzliche Aufgabe oder Interaktion. Beides belegt weder Postfachkontrolle noch, dass ein Konto einer einzigartigen Person gehört.
| Was Sie wissen wollen | CAPTCHA | Honeypot |
|---|---|---|
| Zweck | Antwort auf eine Aufgabe oder Interaktion auf Automatisierungsmerkmale prüfen. | Sendungen erkennen, die ein Köderfeld ausfüllen. |
| Belege | Ein validiertes Aufgabenergebnis oder ein Interaktionswert, je nach System. | Ob der gesendete Köderwert die Formularregel verletzt. |
| Aufwand für Besucher | Interaktive Varianten stellen eine Aufgabe. Varianten mit Bewertungswert können ohne Aufgabe laufen. | Besucher sollen das Köderfeld ohne zusätzliche Aufgabe unberührt lassen. |
| Serverprüfung | Die Antwort auf dem Server prüfen, bevor die geschützte Aktion angenommen wird. | Das Köderfeld auf dem Server prüfen; eine reine Browserregel lässt sich umgehen. |
| Was unentdeckt bleibt | Eine erfolgreiche Prüfung belegt keine Postfachkontrolle und verhindert nicht jede missbräuchliche Registrierung. | Skripte können bestehen, wenn sie das Köderfeld erkennen und leer lassen. |
| Berechtigte Besucher | Interaktive Aufgaben können Zugangsbarrieren schaffen. Prüfen Sie den tatsächlichen Weg bis zum Abschluss. | Prüfen Sie, ob Autovervollständigung und Hilfstechniken das Köderfeld unberührt lassen. |
| Unvollständige Prüfung | Ungültige Antwort, Ablauf, Netzwerkfehler und Dienstfehler getrennt behandeln. | Ein fehlendes oder fehlerhaftes Köderfeld ist ein eigener Eingabefall, kein unauffälliges Ergebnis. |
CAPTCHA umfasst verschiedene Ansätze. Die Dokumentation zu Googles reCAPTCHA v3 beschreibt etwa einen Bewertungswert ohne interaktive Aufgabe. Dieser Wert und die erwartete Aktion müssen weiterhin serverseitig geprüft werden.
Was die beiden Prüfungen feststellen
Ein Honeypot im Formular ist ein Köderfeld, das bei einer gewöhnlichen Sendung leer bleiben soll. Der Server prüft die Regel beim Eingang. Sie kann Skripte erkennen, die jedes Feld füllen; ein Angreifer kann das Feld aber erkennen und auslassen. Die Drupal-Honeypot-Dokumentation beschreibt diese Grenze und eine optionale Mindestzeit. Eine Zeitgrenze ist eine eigene Regel, keine Eigenschaft jedes Honeypots.
Ein interaktives CAPTCHA verlangt eine Aufgabe vom Besucher. Die W3C Group Draft Note zur CAPTCHA-Barrierefreiheit beschreibt mögliche Hürden für Menschen mit Behinderungen. Prüfen Sie bei einer Aufgabe im Registrierungsablauf den Tastaturzugang, Hilfstechniken, Fehlerbehebung und einen alternativen Weg. Eine nicht interaktive Bewertung hat andere Vor- und Nachteile und muss ebenfalls geprüft werden.
Eine bestandene Prüfung liefert Belege zu dieser Interaktion. Sie belegt nicht, dass das Konto einer einzigartigen Person gehört. Ein leerer Honeypot beweist nicht, dass ein Mensch das Formular gesendet hat.
Eine Kombination für Ihre Registrierung wählen
Die folgenden Kombinationen decken verschiedene Prüfungen im Ablauf ab. Entscheiden Sie anhand der benötigten Belege und der Kosten einer Fehlentscheidung:
- Honeypot und E-Mail-Bestätigung. Nutzen Sie das Köderfeld als ersten Filter für Skripte, die es füllen. Verlangen Sie einen Bestätigungslink vor der Freigabe von Rechten, die Postfachkontrolle voraussetzen. Skripte können das Köderfeld weiterhin auslassen. Wer viele Postfächer kontrolliert, kann weiterhin viele Konten anlegen.
- CAPTCHA und E-Mail-Bestätigung. Nutzen Sie eine validierte Aufgabe oder Interaktionsbewertung, wenn Sie diese zusätzliche Prüfung benötigen. Behalten Sie die Bestätigung für den Postfachzugriff. Legen Sie fest, wie berechtigte Besucher bei einer nicht lösbaren Aufgabe fortfahren können. Messen Sie erfolgreiche Registrierungen und Abbrüche.
- Besuchssignale und E-Mail-Bestätigung. Entscheiden Sie anhand von Besuch und Formularsendung, wann eine Bestätigung nötig ist. So lässt sich eine zusätzliche Lösungsaufgabe vermeiden. Eine gleichwertige Schutzwirkung wie bei Ihrem gewählten CAPTCHA ist damit nicht belegt. Prüfen Sie die Wirkung an Ihrem Registrierungstraffic.
Die Bestätigung belegt Zugang zum Postfach, an das der Link ging. E-Mail-Verifizierung prüft hingegen die Adresse und das Mailsystem, ohne diese Nachricht zu senden. Der Vergleich von Verifizierung und Bestätigung erklärt, wann Sie welchen Schritt benötigen.
Unvollständige Prüfungen getrennt behandeln
Unterscheiden Sie serverseitig eine verletzte Regel, eine abgelaufene Antwort und eine nicht verfügbare Prüfung. Die Cloudflare-Dokumentation zur Turnstile-Validierung trennt etwa abgelaufene oder doppelte Tokens von internen Fehlern und verlangt Servervalidierung. Das Widget allein schützt keine Form. Halten Sie sich an die Prüf- und Wiederholungsregeln der tatsächlich verwendeten Komponente.
Legen Sie für nicht verfügbare Prüfungen eine Ausfallregel fest: neue Aufgabe anfordern, Registrierung zurückhalten oder Rechte bis zum Abschluss einer anderen Prüfung einschränken. Die Wahl hängt von den Kontorechten und Ihren Anwendungsregeln ab. Begrenzen Sie Wiederholungen, erhalten Sie eingegebene Werte soweit sinnvoll und erklären Sie den nächsten Schritt. Ein Timeout beweist nicht, dass der Besucher einen Menschentest nicht bestanden hat.
Definieren Sie beim Honeypot das Serververhalten für ein fehlendes oder fehlerhaftes Feld ebenso wie für ein gefülltes. Prüfen Sie die korrekte Übermittlung durch gewöhnliche Browser, Autovervollständigung und Hilfstechniken, bevor Sie Konten aufgrund dieser Regel ablehnen.
Die Rolle von Emvero
Signup Protection kombiniert E-Mail- und Besuchsbelege oder prüft Besuchssignale getrennt. Ihr Server sendet den Besuchstoken und verfügbare Anfragedaten. Emvero gibt eine empfohlene action zurück, die Ihre Anwendung umsetzt. Emvero stellt weder Honeypot noch CAPTCHA bereit, sendet Ihre Bestätigung nicht und vergibt keine Kontorechte.
Besuchssignale können ein sonst erlaubtes E-Mail-Ergebnis auf allow_with_email_confirmation erhöhen. Für sich allein empfehlen sie kein reject; eine kombinierte Antwort kann wegen des E-Mail-Ergebnisses ablehnen. Netzwerkbefunde wie VPN-Nutzung sind standardmäßig informativ. Ein Signalergebnis unavailable belegt keinen sicheren Besuch.
Trennen Sie die äußere Signup-Aktion, das eingebettete E-Mail-Ergebnis und den Signalstatus. Ratenlimits, Bestätigungszustand und Zugangsregeln bleiben Ihre Aufgabe. Der Installationsleitfaden zum Schutz der Registrierung führt durch Formular, Token, Serveranfrage und Aktion.
Verwandte Begriffe
Besuchs-Token
Ein undurchsichtiger Wert, der die Token-Anfrage des Browsers mit einer späteren Registrierungsprüfung verbindet. Er ist keine dauerhafte Besucherkennung.
Registrierungssignal
Ein Beleg zum Besuch und zur eingereichten Anfrage, getrennt vom E-Mail-Ergebnis und der abschließenden Registrierungsempfehlung.
Besuchsbelege für die Registrierung nutzen
Nutzen Sie Signup Protection, wenn Sie E-Mail- und Besuchsbelege im selben Registrierungsablauf benötigen. Bestätigung und Kontozugang bleiben unter Kontrolle Ihrer Anwendung.