Sicherheit

CaptchaCore Sicherheits-Center

Die Einhaltung von Gesetzen und Sicherheitsstandards sind Grundpfeiler von CaptchaCore. CaptchaCore orientiert sich an deutschen und europäischen IT-Sicherheitsstandards und gewährleistet so Vertrauen, Ausfallsicherheit und Rechtssicherheit für Unternehmen.

Technische Sicherheitsmaßnahmen

Verschlüsselung

• TLS 1.2/1.3: Sämtliche Datenübertragungen zwischen Browser, Widget und CaptchaCore-API sind Ende-zu-Ende verschlüsselt.
• HSTS: Strict Transport Security mit max-age=31536000, includeSubDomains und Preload.
• SHA-256 + Argon2: Proof-of-Work-Challenges verwenden SHA-256 oder Memory-Hard Argon2id (GPU-resistent). IP-Adressen werden mit Rolling Salts als SHA-256-Hash gespeichert (Rotation alle 6 Stunden).
• EdDSA Token-Signing: Challenge-Bindings werden mit Ed25519 kryptographisch signiert. Token-Manipulation, Cross-Site-Replay und Origin-Spoofing werden erkannt und blockiert.

Nonce-Sicherheit

• Nonces werden mit random_bytes(32) (256 Bit Entropie) kryptografisch sicher generiert.
• Jede Nonce ist Single-Use — nach Verbrauch wird sie atomar aus Redis gelöscht (Lua-Script, kein Race-Condition-Fenster).
• Nonces haben eine TTL von 5 Minuten. Abgelaufene Nonces werden automatisch verworfen.
• Replay-Angriffe sind dadurch technisch unmöglich.

API-Key-Sicherheit

• Secret Keys werden niemals in der Datenbank gespeichert — nur der SHA-256-Hash.
• Secret Keys werden nur einmal bei der Erstellung angezeigt und können nicht wiederhergestellt werden.
• Key-Rotation mit konfigurierbarer Übergangszeit (Standard: 24 Stunden, alter Key bleibt gültig).
• Jede Site erhält ein eigenes Key-Paar (Public + Secret).

Under-Attack-Mode (4-stufig)

• Level 0: Normalbetrieb — Standard-PoW und Verhaltensanalyse.
• Level 1: Erhöhte Schwierigkeit (+1 PoW-Difficulty), verschärfte Heuristik. Trigger: 50%+ Block-Rate.
• Level 2: Interaction Step-Up für verdächtige Requests, härterer PoW. Trigger: 70%+ Block-Rate oder Level 1 >10 Minuten.
• Level 3: Maximale Verteidigung — Memory-Hard PoW + Interaction Step-Up für alle Requests. Trigger: 85%+ Block-Rate.
• Automatische Eskalation und De-Eskalation basierend auf Echtzeit-Bedrohungslage.
• HMAC-signiertes Access-Cookie pro Level (TTL: 60/30/15 Minuten).

Adaptive Risk Engine

• Site-Profile: 4 vordefinierte Schutzprofile (Low Friction, Balanced, Auth Hardened, High Security) mit individuellen Schwellen und Penalty-Gewichtungen.
• Form-Policies: Pro Formular-Typ (Login, Register, Checkout, Kontakt) unterschiedliche Sicherheitsstufen. Login wird strenger bewertet als ein Kontaktformular.
• Confidence Score: 0.0–1.0 Wert der angibt, wie viele Signale zur Entscheidung beigetragen haben.
• Reason Codes: Maschinenlesbare Begründungen für jede Entscheidung (pow_valid, behavior_human_like, ip_clean, etc.).

IP-Reputation & Threat Intelligence

• IP-Archiv: Umfangreiches Archiv risikoreicher IP-Adressen und CIDR-Blöcke (IPv4 + IPv6), das täglich mehrfach aus verschiedenen Quellen aktualisiert wird.
• Kampagnenerkennung: Automatische Erkennung koordinierter Angriffswellen anhand korrelierter Muster (ASN, Land, User-Agent-Cluster).
• Auto-Learning: Stündliche Analyse blockierter Requests zum Erlernen neuer Bedrohungsmuster mit automatischem Score-Decay.

Organisatorische Maßnahmen

Hosting

• Serverstandort: Deutschland (eigene Server von SpeedIT Solutions)
• Drittland-Übertragung: Sämtliche Verarbeitung der Verifikationsdaten findet in Deutschland statt; einzige Ausnahme ist der optionale globale CDN-Endpunkt für die Widget-Datei
• Zugriffskontrolle: SSH-Key-basiert, kein Passwort-Login
• Firewall: Nur notwendige Ports geöffnet (443/HTTPS, 80→301-Redirect)

Security Headers

• Content-Security-Policy — restriktive CSP-Regeln
• X-Frame-Options: SAMEORIGIN — Clickjacking-Schutz
• X-Content-Type-Options: nosniff — MIME-Sniffing-Schutz
• Strict-Transport-Security — HSTS mit Preload
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy — Geolocation, Kamera, Mikrofon deaktiviert

Rate Limiting

• Challenge-Endpoint: 30 Requests/Minute pro IP (NGINX + Laravel)
• Verify-Endpoint: 60 Requests/Minute pro IP
• Login: 10 Requests/Minute pro IP
• 2FA: Max. 5 Versuche pro Session

Verfügbarkeit

• SLA: 99,99% Verfügbarkeit im Jahresmittel (ohne geplante Wartung)
• Fail-Open-Prinzip: Bei Service-Ausfall werden Formulare nicht blockiert (konfigurierbar)
• Redundanz: Redis-basierte Nonce-Verwaltung mit Persistenz
• Monitoring: Automatische Health-Checks, Log-Rotation, Threat-Learning

Datenschutz-Compliance

• DSGVO (EU): Vollständig konform — Privacy by Design, keine Cookies, keine Drittland-Übertragung im Standard (EU-Endpunkt)
• TDDDG (DE): Technisch notwendige Cookies (nur UAM) sind von der Einwilligungspflicht ausgenommen (§ 25 Abs. 2 Nr. 2)
• AVV: Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO auf Anfrage verfügbar

Sicherheitsmeldungen

Wenn Sie eine Sicherheitslücke in CaptchaCore entdecken, melden Sie diese bitte verantwortungsvoll an security@captchacore.eu. Wir nehmen alle Meldungen ernst und antworten innerhalb von 48 Stunden.

CDN-Infrastruktur

Das CaptchaCore-Widget wird über ein europäisches Edge-Netzwerk mit 114 Points of Presence (PoPs) weltweit ausgeliefert. Der CDN-Anbieter hat seinen Sitz in der EU.

EU-only Endpoint (Standard)

src-eu.captchacore.eu — Auslieferung ausschließlich über europäische Server. Keine Datenübertragung in Drittländer.

35 Standorte in Europa: Deutschland (Primary Storage + Origin), Österreich, Schweiz, Niederlande, Belgien, Luxemburg, Frankreich, Großbritannien, Irland, Spanien, Portugal, Italien, Schweden, Norwegen, Dänemark, Finnland, Polen, Tschechien, Slowakei, Ungarn, Rumänien, Bulgarien, Griechenland, Kroatien, Serbien, Bosnien, Slowenien, Lettland, Estland, Litauen, Ukraine, Russland (Moskau), Moldawien

Globaler Endpoint (optional)

src.captchacore.eu — Alle EU-Standorte plus weltweite Edge-Server für minimale Latenz.

• Nordamerika (22 PoPs): New York, Washington, Boston, Toronto, Montreal, Vancouver, Seattle, San Francisco, Los Angeles, San Diego, Phoenix, Las Vegas, Denver, Chicago, Dallas, Houston, Austin, Miami, Atlanta, Charlotte, Columbus, Minneapolis
• Südamerika (14 PoPs): São Paulo, Rio de Janeiro, Brasília, Curitiba, Porto Alegre, Buenos Aires, Santiago, Lima, Bogotá, Quito, La Paz, Recife, Caracas, São Luís
• Asien-Pazifik (26 PoPs): Singapur, Kuala Lumpur, Bangkok, Ho Chi Minh City, Jakarta, Manila, Hongkong, Shenzhen, Guangzhou, Peking, Shanghai, Wuhan, Taipei, Seoul, Tokio, Osaka, Delhi, Mumbai, Bangalore, Chennai, Kolkata, Dhaka, Istanbul, Ankara, Jerusalem, Bahrain
• Ozeanien (6 PoPs): Sydney, Melbourne, Brisbane, Perth, Auckland, Christchurch
• Naher Osten & Afrika (11 PoPs): Dubai, Riad, Kairo, Khartum, Algier, Lagos, Nairobi, Johannesburg, Durban, Brazzaville, Antananarivo

Sicherheitsmaßnahmen CDN

• DDoS-Schutz: Edge-Shield auf allen Endpoints — automatische Erkennung und Mitigation von volumetrischen Angriffen
• TLS 1.2/1.3: Verschlüsselte Auslieferung auf allen Edge-Servern
• Checksum-Validierung: SHA-256 Prüfsumme bei jedem Deploy — manipulierte Dateien werden automatisch abgelehnt
• Origin-Fallback: Bei CDN-Ausfall wird das Widget direkt vom Origin-Server in Deutschland geladen
• Nur statische Dateien: Das CDN liefert ausschließlich JavaScript-Dateien aus — keine API-Kommunikation, keine dynamischen Daten, keine Cookies
• Cache-Control: 5 Minuten max-age mit must-revalidate — Updates werden schnell verteilt

Datenfluss im Detail: Was geht wohin?

CaptchaCore trennt strikt zwischen der Widget-Auslieferung (statische Dateien) und der API-Kommunikation (dynamische Verifikation). Nur die Widget-Auslieferung nutzt das CDN — alle sicherheitsrelevanten Daten bleiben in Deutschland.

Was über das CDN geliefert wird

Ausschließlich statische JavaScript-Dateien:

• captchacore.min.js (~16 KB gzip) — Das Widget-Script, das die Checkbox rendert, den Proof of Work im WebWorker startet und Behavioral Signals sammelt
• pow-worker.min.js (~1.3 KB gzip) — Der WebWorker, der die SHA-256 Rechenaufgabe löst

Diese Dateien sind öffentlicher, unveränderlicher Code — sie enthalten keine Konfiguration, keine API-Keys, keine nutzerspezifischen Daten. Der Inhalt ist bei jedem Abruf identisch, egal wer ihn lädt.

Was das CDN dabei technisch verarbeitet

Beim Abruf einer statischen Datei über das CDN verarbeitet der Edge-Server technisch notwendige Verbindungsdaten:

• IP-Adresse: Wird für das TCP/TLS-Handshake benötigt. Wird nicht dauerhaft gespeichert, nicht geloggt, nicht an CaptchaCore übertragen.
• User-Agent: Wird für die Content-Negotiation verwendet (z.B. Encoding). Nicht geloggt.
• Keine Cookies: Das CDN setzt keine Cookies und liest keine.
• Kein Tracking: Keine Analytics, keine Fingerprinting-Scripts, keine Pixel.

Bei Nutzung des EU-only Endpoints (src-eu.captchacore.eu) verlassen diese Verbindungsdaten zu keinem Zeitpunkt die EU.

Was NICHT über das CDN läuft

Die gesamte sicherheitsrelevante Kommunikation läuft direkt zwischen dem Browser des Nutzers und dem CaptchaCore Origin-Server in Deutschland — ohne CDN, ohne Zwischenstation:

• Challenge-Anforderung (GET /api/v2/challenge) — Der Browser holt eine PoW-Aufgabe direkt vom Origin. Dabei wird eine einmalige Nonce generiert und in Redis gespeichert.
• Token-Verifikation (POST /api/v2/verify) — Der Server des Webseitenbetreibers sendet das gelöste Token direkt an den Origin. Die Risk Engine bewertet PoW, Behavioral Signals, IP-Reputation und User-Agent.
• Behavioral Signals — Maus-Entropie, Tipp-Rhythmus, Scroll-Verhalten werden lokal im Browser aggregiert und als numerische Scores im Token an den Origin gesendet. Keine Rohdaten.
• IP-Adresse des Nutzers — Wird vom Origin anonymisiert (letztes Oktett entfernt) und als SHA-256-Hash gespeichert. Geht nie über das CDN.
• Risk Score, Verifikationsergebnis — Wird serverseitig in Deutschland berechnet und gespeichert.

Zusammenfassung Datenfluss