Sicherheit — Account & Plattform

Modernster Faktor: Touch-ID / Face-ID / Windows Hello / YubiKey. Phishing-resistent, keine Codes zum eintippen. Der Passkey wird über WebAuthn bei der Relying Party xictraq.com registriert (Algorithmen ES256 und RS256, Attestation „none“). Der Login mit Passkey ist einstufig: ein registrierter Passkey meldet Sie direkt an, ein vorheriges Passwort ist dafür nicht nötig — die kryptografische Signatur ersetzt beide Faktoren in einem Schritt.

Jede Anmeldung prüft Challenge, RP-ID-Hash und Origin serverseitig — nur https://xictraq.com bzw. https://www.xictraq.com werden akzeptiert, eine Phishing-Domain erhält keine gültige Assertion. Zusätzlich überwacht XICTRAQ den Sign-Count des Authenticators: steigt der Zähler nicht monoton an, wertet die Plattform das als Hinweis auf einen geklonten Authenticator, weist die Anmeldung ab und protokolliert das Ereignis im Audit-Log.

Alternative wenn keine Passkeys verfügbar sind: QR-Code mit Authenticator-App scannen (Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator) → 6-stelliger Code beim Login. Die Implementierung folgt RFC 6238 (HMAC-SHA1, 30-Sekunden-Fenster, 160-Bit-Secret) und akzeptiert beim Prüfen eine Toleranz von einem Slot in jede Richtung (±30 Sekunden), damit ein knapp abgelaufener Code nicht sofort fehlschlägt. Backup-Codes generieren wir bei Aktivierung — bewahren Sie 8 davon sicher auf für den Fall, dass das Handy weg ist.

Wir empfehlen Passkeys bei sensiblen Konten (Agency-Plan, Konten mit vielen Websites), erzwingen aber keinen zweiten Faktor — auch normale E-Mail-Logins bleiben uneingeschränkt nutzbar. TOTP-Setup läuft zweistufig: zuerst erzeugt /auth/totp/setup ein Pending-Secret samt QR-Code, erst der erste korrekt eingegebene Code über /auth/totp/enable schaltet 2FA scharf. Das Deaktivieren erfordert Passwort plus gültigen Code (oder Backup-Code), damit ein gestohlenes Login-Cookie den zweiten Faktor nicht abschalten kann.

Ist TOTP aktiv, gibt der Login kein direktes Token zurück, sondern einen kurzlebigen Challenge-Token mit 10 Minuten Gültigkeit. In diesem Fenster sind höchstens 5 Fehlversuche erlaubt; danach wird die Challenge verworfen (Antwort 429) und ein erneuter Login wird nötig — so lässt sich ein 6-stelliger Code nicht im offenen Zeitfenster durchprobieren. Jeder Fehlversuch landet als auth.login.2fa_failed im Audit-Log.

Mindestens 10 Zeichen — bei Registrierung, Wechsel und Reset gleichermaßen geprüft. Passwörter werden mit bcrypt (cost-factor 12) und Per-User-Salt gehasht; der Klartext wird nie gespeichert. Beim Wechsel über /auth/password muss zunächst das aktuelle Passwort bestätigt werden, danach werden alle anderen Sessions widerrufen — die aktuelle Session bleibt aktiv.

Der Reset-Link wird pro E-Mail-Adresse auf maximal 3 Anforderungen pro Stunde gedrosselt, und die Antwort ist immer generisch (kein Hinweis, ob die Adresse existiert — Schutz vor Account-Enumeration). Das versendete Token ist 60 Minuten gültig und wird selbst nur als SHA-256-Hash gespeichert. Ein erfolgreicher Reset entwertet sämtliche bestehenden Sessions; ist auf dem Konto 2FA aktiv, loggt der Reset NICHT direkt ein, sondern verlangt zusätzlich den zweiten Faktor — so umgeht ein Angreifer mit reinem Inbox-Zugriff die 2FA nicht.

Beim Passwort-Wechsel werden alle Sanctum-Tokens des Accounts widerrufen — alle anderen Browser, Geräte und Apps werden ausgeloggt. Die aktuelle Session bleibt aktiv. Personal Access Tokens (PATs für API-Zugriff) sind davon ausgenommen — die müssen separat in /app/settings/api-keys widerrufen werden, damit Skripte nicht versehentlich abreißen.

Sie können mit demselben Konto gleichzeitig auf mehreren Geräten angemeldet sein. Unter /app/settings/security listet XICTRAQ Ihre aktiven Sessions auf (bis zu 20, sortiert nach letzter Nutzung) — jeweils mit Geräte-Label, Erstell- und letztem Nutzungszeitpunkt; die aktuelle Session ist als solche markiert. Jede fremde Session lässt sich einzeln widerrufen, oder Sie melden mit „Alle anderen abmelden“ jedes Gerät außer dem aktuellen ab. Die aktuell genutzte Session können Sie aus Sicherheitsgründen nicht selbst entfernen — dafür den globalen Logout oder einen Passwort-Wechsel nutzen. Test- und Admin-Impersonations-Token werden in dieser Liste bewusst ausgeblendet: Support-Zugriffe per Impersonation laufen als gesonderte Admin-Sitzung, erscheinen nur im Admin-Bereich und tauchen nie in Ihrer Geräteübersicht auf.

In /app/settings/security sehen Sie alle registrierten Passkeys mit Name, Erstelldatum und letzter Nutzung. Mehrere Passkeys gleichzeitig möglich (z. B. Phone + Hardware-Token); ein zweiter Faktor auf demselben Gerät trägt automatisch einen durchnummerierten Standardnamen, den Sie überschreiben können. Einzeln umbenennbar oder löschbar — verlorenes Gerät einfach hier entfernen, der Rest bleibt nutzbar.

Die Erkennung ist opt-in pro Website (Watch-Toggle, ab Starter-Plan) und lernt in den ersten 3 Läufen Ihren Soll-Zustand (Baseline). Ein Verdacht löst ein Event mit der Severity „kritisch“ über Ihre Alert-Kanäle aus; sinkt der Score wieder, schließt das Event automatisch. Vollständige Beschreibung der drei Schichten, der Score-Logik und des Baseline-Lernens im Screenshots-Modul.

Während die Defacement-Erkennung Ihre Seite als Ganzes überwacht, betrachtet die Skript-Integrität gezielt den Inhalt jedes eingebundenen Dritt-Skripts. Das ergänzt zwei verwandte Härtungsmaßnahmen: Subresource Integrity (SRI) verhindert das Laden veränderter Dateien im Browser, CSP-Reports melden Policy-Verstöße aus echten Besucher-Browsern — die Skript-Integrität erkennt serverseitig die unbemerkte Hash-Änderung selbst.

Standardmäßig wird das Fazit aus festen Regeln erzeugt (kein Token-Verbrauch): Es nennt den Score samt Schulnote, zählt wie viele der 6 Header gesetzt sind und listet die fehlenden zur Nachrüstung auf. Eine formulierungsreichere KI-Narration ist plattformseitig vorbereitet, derzeit aber nicht eingeschaltet und nicht je Konto wählbar; liefe sie, griffe bei einem Fehlschlag automatisch der Regel-Fallback. So oder so werden ausschließlich aggregierte Werte verarbeitet — Score und Header-Status, niemals Domain, Host oder Einzelfunde (datenschutzfreundlich).

• Zutrittskontrolle: Hosting in zertifizierten Rechenzentren innerhalb der EU; die zugesicherten physischen Schutzmaßnahmen ergeben sich aus dem TOM-Datenblatt des Rechenzentrumsbetreibers (in der Datenschutzerklärung benannt). • Zugangskontrolle: Server-Administration über zeitgemäße authentifizierungs- und autorisierungs­mechanismen mit Schutz gegen unberechtigten Zugriff. • Zugriffskontrolle: Rollen- und Rechtemodell (User → Team → Admin); strikte Mandantentrennung auf Datenbank-Ebene; keine systembedingten Standard-Freigaben zwischen Konten. • Trennungskontrolle: Logische Trennung der Datenbestände nach Funktionsbereichen sowie zwischen Test- und Produktivsystemen. • Pseudonymisierung: Cookielose Besucher-Erfassung über eine Tageskennung aus IP-Adresse und einem täglich neu erzeugten Zufallswert (Salt), der nach Ablauf des Tages gelöscht wird, sodass danach keine Zuordnung zur IP-Adresse mehr möglich ist; die IP-Adresse selbst wird nicht gespeichert; Speicherung von Passwörtern ausschließlich als Hash mit etabliertem Verfahren; API-Tokens werden nur als Hash-Wert persistiert.

• Übertragungskontrolle: Transportverschlüsselung nach Stand der Technik (HTTPS/TLS) für alle Schnittstellen; HSTS aktiviert. • Eingabekontrolle: Sicherheitsrelevante administrative Aktionen werden protokolliert; Aufbewahrung erfolgt nach Erforderlichkeit und Speicherbegrenzungs-Grundsatz (Art. 5 Abs. 1 lit. e DSGVO). • Skript-Integrität: Versionierter Tracker mit Subresource-Integrity-Hash (SHA-384) zur Erkennung unautorisierter Veränderungen auf Kunden-Websites.

• Backups: Regelmäßige automatisierte Backups; Aufbewahrung und Wiederherstellungsfähigkeit werden im Rahmen unseres Hosting-Setups sichergestellt. • Hochverfügbarkeit: Verteiltes Monitoring-Setup an mehreren EU-Standorten, sodass der Ausfall eines Standorts die Plattform nicht insgesamt beeinträchtigt. • Schutz vor Überlastung: DDoS-Schutz auf Netzwerk-Ebene durch den Rechenzentrumsbetreiber; Rate-Limiting auf Applikationsebene zum Schutz vor Brute-Force und Missbrauch. • Eigenüberwachung: Live-Status der Plattform-Komponenten unter xictraq.com/status.

• Anlassbezogene Überprüfung dieser Maßnahmen vor wesentlichen Architektur- oder Subprocessor-Änderungen sowie nach Sicherheitsvorfällen. • Laufendes Monitoring der eingesetzten Open-Source-Komponenten auf bekannte Schwachstellen über die Paketmanager unserer Umgebung (npm/composer). • Information des Kunden bei Datenschutzvorfällen innerhalb von 72 Stunden gemäß § 9a Ziffer 7 dieser AGB.