cfs_zockt setzt auf mehrere Schutzschichten statt auf ein einzelnes „Security“-Label. Die Seite trennt aktive Schutzmaßnahmen, optionale Account-Funktionen und bewusst offene Infrastruktur.
Identität, Passwort, starke Anmeldung und Sessions.
Creator-Passwörter werden serverseitig mit scrypt und einem zufälligen individuellen Salt verarbeitet. Neue Hashes verwenden eine stärkere, versionierte scrypt-Konfiguration; ältere Hashes werden nach erfolgreicher Anmeldung automatisch migriert. Neue Passwörter benötigen mindestens 15 Zeichen und besonders vorhersehbare Werte werden blockiert.
Produktive Creator-Sessions verwenden das __Host--Präfix, Secure, HttpOnly und einen festen Root-Pfad. Das reduziert Cookie-Tossing- und Subdomain-Risiken.
Anmelde- und Registrierungsversuche werden begrenzt. Fehlermeldungen verraten bewusst nicht, ob eine konkrete E-Mail-Adresse als Account existiert.
Ein Passwortwechsel erfordert eine aktive Session und die erneute Eingabe des aktuellen Passworts. Nach erfolgreicher Änderung werden bestehende Login-Sitzungen widerrufen und eine neue Sitzung für den aktuellen Browser ausgegeben.
Creator können optional einen Passkey registrieren. Die Anmeldung nutzt WebAuthn und ist an die konfigurierte cfs_zockt-Domain gebunden. Der private Schlüssel bleibt im Authenticator bzw. auf dem Gerät; der Server speichert nur Credential-ID, öffentlichen Schlüssel, Signaturzähler und minimale Authenticator-Metadaten. User Verification ist für Registrierung und Anmeldung erforderlich. Passkeys bieten damit eine phishing-resistentere Anmeldestufe als TOTP.
Creator können zusätzlich zum Passwort einen zeitbasierten 6-stelligen Authenticator-Code aktivieren. Das TOTP-Secret wird serverseitig verschlüsselt gespeichert; ein bereits akzeptierter Zeitschritt wird nicht erneut angenommen. Recovery-Codes sind Einmalcodes und werden nur gehasht persistiert. TOTP bleibt eine zusätzliche Schutzschicht und wird nicht als phishing-resistent dargestellt.
Creator-Sessions laufen über serverseitig verwaltete Session-Tokens. Im Produktivbetrieb werden Session-Cookies mit HttpOnly und Secure gesetzt; SameSite begrenzt zusätzliche Cross-Site-Risiken.
Schreibzugriffe, Browsergrenzen und serverseitige Geheimnisse.
Zustandsändernde Browser-Anfragen werden über exakte Origin-/Referer-Prüfungen, Fetch Metadata und einen signierten, sessiongebundenen CSRF-Token abgesichert.
Die Website setzt unter anderem Content-Security-Policy, Frame-Schutz, MIME-Schutz, Referrer Policy, Permissions Policy und weitere Security Header ein.
TikTok-Secrets, Access-/Refresh-Tokens und andere vertrauliche Zugangsdaten werden nicht als öffentliche Konfiguration in Browser-JavaScript ausgeliefert.
Datensparsame Schutzmaßnahmen, Meldewege und Creator-Kontrolle.
Öffentliche Rezensionen besitzen Rate Limits, Duplikat-/Submitter-Schutz und Moderationsstatus. Für den Missbrauchsschutz wird keine rohe IP-Adresse als Review-Datensatz gespeichert.
Sicherheits-, Datenschutz- und Technikprobleme können über einen nicht-öffentlichen Meldeweg eingereicht werden. Der Missbrauchsschutz speichert auch dort keine rohe IP-Adresse als Meldungsdatensatz.
Creator können einzelne Sitzungen oder alle Geräte abmelden, einen bereinigten JSON-Datenexport erstellen, TikTok trennen und das Creator-Konto nach erneuter Passwortprüfung dauerhaft löschen.
Erfolgreiche Sitzungen zeigen ihre Anmeldemethode im Account. Wird zuerst das korrekte Passwort verwendet und scheitert danach TOTP, Recovery-Code oder Passkey, wird das als Sicherheitsereignis gespeichert. Zusätzlich ergänzt ein persistenter, kontoweiter Passwort-Throttle die IP-/Request-Limits über Server-Neustarts und mehrere Instanzen hinweg. Ist der Mail-Relay aktiv, werden wichtige Warnungen gebündelt versendet – ohne Standorttracking oder Browser-Fingerprinting.
Audit, Telemetrie, Fehlerbehandlung, Incident-Modus und Recovery-Unterbau.
Privilegierte Admin-Schreibaktionen benötigen zusätzlich zur angemeldeten Admin-Session eine frische Passwortbestätigung. Die Freigabe ist kurzlebig und an genau diese Session gebunden. Änderungen werden intern ohne Request-Body, rohe IP oder User-Agent als minimales Admin-Audit protokolliert. Neue Audit-Einträge werden zusätzlich HMAC-verkettet, damit nachträgliche Änderungen oder Lücken innerhalb der aufbewahrten Kette erkennbar werden.
Die erzwungene Content-Security-Policy meldet Browser-Verstöße an einen eigenen Same-Origin-Endpunkt. Gespeichert werden nur normalisierte Muster: keine rohe IP, kein User-Agent, keine Query-Strings und keine vollständigen tokenartigen Pfadsegmente. Admins können die aggregierten Muster intern prüfen.
Unbekannte Seiten und interne Fehler landen auf eigenen noindex-Fehlerseiten. API-Fehler bleiben generisch und erhalten eine serverseitig erzeugte Request-Referenz; Stacktraces oder interne Secrets werden nicht an Besucher ausgegeben.
Bei Wartung oder einem Sicherheitsvorfall können riskante Account-, Creator-, Review- und Billing-Schreibwege zentral pausiert werden, während die öffentliche Website, der knappe Systemstatus, der private Security-Support und der Admin-Zugang erreichbar bleiben. Ein Security Lockdown kann optional gleichzeitig andere Login-Sitzungen widerrufen.
Bestätigungs- und Recovery-Tokens werden kryptografisch zufällig erzeugt, nur gehasht gespeichert, zeitlich begrenzt und einmal verwendet. Links tragen den Token im URL-Fragment, damit er nicht schon beim ersten Seitenaufruf an den Server gesendet wird. Der eigentliche Mailversand bleibt deaktiviert, bis ein signierter HTTPS-Mail-Relay real konfiguriert wurde.
Eine angemeldete Session allein reicht für kritische Browseraktionen nicht aus.
Technische Schutzschichten helfen am meisten, wenn der Account selbst sauber verwaltet wird.
Aktive Sitzungen prüfen und einzeln oder vollständig widerrufen.
ACCOUNT → MFAPasskey oder TOTP aktivierenZusätzliche Anmeldeschicht einrichten und Recovery-Codes sicher aufbewahren.
SICHERHEIT → TIKTOKVerbindung trennenEine verbundene TikTok-Autorisierung kann im Account entfernt werden.
ACCOUNT → MELDUNGVerdächtiges Verhalten meldenPrivate Support-/Security-Meldung ohne Passwörter, Tokens oder Recovery-Codes.
PRIVAT MELDEN →Der standardisierte Einstieg liegt unter /.well-known/security.txt und verweist auf den privaten Support-Weg.
Was wir nicht versprechen: 100 % unangreifbar zu sein. Kein Onlinedienst kann das seriös garantieren. Deshalb setzt cfs_zockt auf mehrere Schutzschichten, kleine Berechtigungsflächen, Tests und transparente offene Punkte.
PROBLEM MELDEN