Ihr Bot-Token erlaubt es, die Nachrichten Ihrer Nutzer zu lesen und im Namen Ihres Bots zu sprechen. Diese Seite beschreibt genau, wie wir ihn schützen — und was wir noch nicht gebaut haben.
Ihr Telegram-Bot-Token ist ein vollwertiges Credential für Ihren Bot. Er wird daher mit AES-256-GCM versiegelt, bevor er die Datenbank oder ein Backup erreicht, nur zum Aufruf von Telegram entschlüsselt, nie geloggt und überall im Produkt maskiert angezeigt.
HTTPS mit TLS 1.2+ für jede Verbindung, durchgesetzt mit HSTS. Bot-Tokens und Zwei-Faktor-Secrets werden im Ruhezustand mit einem Schlüssel verschlüsselt, der nur Ihrem Deployment bekannt ist.
Passwörter mit scrypt gehasht, optionale TOTP-Zwei-Faktor-Authentifizierung mit Wiederherstellungscodes, httpOnly-Session-Cookies mit CSRF-Schutz, Rate-Limiting bei Anmeldung und Passwort-Reset sowie automatische Sperrung nach wiederholten Fehlversuchen.
Fünf Workspace-Rollen vom Owner bis zum Viewer, serverseitig bei jeder Anfrage durchgesetzt — nicht nur in der Oberfläche versteckt. Mitarbeiterzugriff auf einen Kunden-Workspace ist nur über Impersonation möglich, die stets protokolliert wird.
Anmeldungen, Bot-Änderungen, Veröffentlichungen, Abrechnungsereignisse, Team-Änderungen und Mitarbeiter-Impersonation werden in ein unveränderliches Audit-Log geschrieben, das Sie in Ihrer Konsole einsehen können.
Nächtliche verschlüsselte Datenbank-Backups mit konfigurierbarer Aufbewahrung und einem dokumentierten, getesteten Wiederherstellungsverfahren. Bot-Verbindungen werden alle paar Minuten geprüft und bei einem Abbruch durch Telegram automatisch wiederhergestellt.
Wir betreiben unsere Infrastruktur bei OVH und Hetzner, Hosting-Anbietern, die nach anerkannten Sicherheits- und Compliance-Standards für Rechenzentren geprüft sind. Darüber hinaus führen wir eigene Sicherheitstests auf Serverebene durch und beauftragen Penetrationstests durch Dritte sowie eine unabhängige Überprüfung des Gesamtsystems.
Viele Anbieter lassen diesen Abschnitt weg. Wir möchten lieber, dass Sie damit planen können.
| Bereich | Kontrolle |
|---|---|
| Verschlüsselung bei Übertragung | TLS 1.2+ überall, HSTS aktiviert |
| Secrets im Ruhezustand | AES-256-GCM für Bot-Tokens und 2FA-Secrets |
| Passwörter | scrypt (N=32768), zeitkonstante Verifikation |
| Sitzungen | Opake 256-Bit-Tokens, httpOnly-Cookies, gehasht gespeichert, rollierender 30-Tage-Ablauf |
| Browser-Härtung | Content-Security-Policy, X-Frame-Options, nosniff, strenge Referrer-Policy |
| Missbrauchsprävention | Rate-Limiting bei Authentifizierung, Passwort-Reset und öffentlichen Formularen |
| Autorisierung | Rollenprüfungen serverseitig bei jeder Anfrage durchgesetzt |
| Audit-Trail | Unveränderliches Protokoll von Konto-, Bot-, Abrechnungs- und Mitarbeiteraktionen |
| Backups | Nächtliche verschlüsselte Dumps, konfigurierbare Aufbewahrung, dokumentierter Restore-Test |
| Abhängigkeiten | Fixierte Abhängigkeitsversionen, ausschließlich aus der öffentlichen npm-Registry installiert |
| Infrastruktur | Rechenzentren von OVH und Hetzner, unabhängig geprüft |
| Penetrationstests | Beauftragte Tests durch Dritte sowie laufende unabhängige Überprüfung |
Wenn Sie glauben, eine Sicherheitslücke in Meshwire gefunden zu haben, melden Sie diese bitte vertraulich, damit wir sie untersuchen und beheben können, bevor sie öffentlich bekannt wird. Wir bestätigen Meldungen innerhalb von 24 Stunden und streben an, kritische Probleme innerhalb von 7 Tagen zu beheben. Gegen gutgläubige Forscher, die diese Richtlinie befolgen, gehen wir nicht rechtlich vor.