Niemals Passwörter in Slack teilen: Risiken & Alternativen
Von Maxim Novak
Passwörter in Slack zu teilen ist ein Sicherheitsrisiko, weil Slack Nachrichten unbegrenzt aufbewahrt, sie für Workspace-Admins durchsuchbar macht und sie gegenüber Drittanbieter-App-Integrationen offenlegt. Verwende stattdessen verschlüsselte, selbstzerstörende Links — Tools wie Vaulted verschlüsseln Zugangsdaten in deinem Browser, bevor irgendetwas gesendet wird.
Laut dem Verizon 2025 DBIR waren bei 22 % der Datenlecks kompromittierte Zugangsdaten der erste Angriffsvektor. Und laut einer Studie von Beyond Identity haben über 41 % der Mitarbeitenden schon einmal Arbeitspasswörter geteilt – häufig über unsichere Kanäle wie Chat und E-Mail.
Was wirklich mit diesem Passwort passiert
Wenn du ein Passwort in Slack einfügst, gelangt es nicht nur zur anderen Person. Es wird zu einem Datensatz, den Slack speichert, indexiert und aufbewahrt – oft noch lange, nachdem du es vergessen hast.
Slack bewahrt Nachrichten auf seinen Servern auf. In kostenpflichtigen Plänen können Workspace-Admins Aufbewahrungsrichtlinien konfigurieren, aber viele lassen die Standardeinstellung: alles für immer behalten. Mit Enterprise Grid können Organisationen den vollständigen Verlauf jeder DM und jedes Kanals exportieren und durchsuchen – einschließlich Nachrichten zwischen einzelnen Nutzern.
Slack-Nachrichten sind durchsuchbar. Jede Person mit den richtigen Berechtigungen kann Stichwörter im gesamten Workspace suchen. Eine Suche nach „password" oder „API key" in den meisten Workspaces liefert Ergebnisse, bei denen einem Sicherheitsauditor die Haare zu Berge stehen.
Drittanbieter-Apps können Nachrichten lesen. Jede Slack-App mit den richtigen OAuth-Scopes kann auf den Nachrichtenverlauf zugreifen. Dieser Produktivitäts-Bot, den dein Team letztes Jahr installiert hat? Er hat möglicherweise Lesezugriff auf Kanäle und DMs. Du vertraust nicht nur der Sicherheit von Slack, sondern auch der Sicherheit jeder Integration, die mit deinem Workspace verbunden ist.
Nachrichten überleben das Ausscheiden aus dem Unternehmen. Wenn jemand das Unternehmen verlässt, bleiben seine Slack-Nachrichten erhalten. Die DM mit dem Datenbankpasswort? Die ist immer noch da, für Admins lesbar – auch nachdem das Konto der Person deaktiviert wurde.
Laut dem State of Secrets Sprawl Report 2025 von GitGuardian enthielten 2,4 % der unternehmensinternen Slack-Kanäle durchgesickerte Geheimnisse – und der IBM Cost of a Data Breach Report 2025 stellte fest, dass die durchschnittlichen Kosten eines Datenlecks weltweit 4,44 Millionen Dollar erreichten.
Das Compliance-Problem
Wenn dein Unternehmen an SOC 2-, ISO 27001- oder HIPAA-Compliance arbeitet, ist das Teilen von Zugangsdaten in Slack ein Befund, der nur darauf wartet, aufgedeckt zu werden.
Auditoren fragen gezielt, wie dein Team interne, sensible Zugangsdaten überträgt. „Wir fügen sie in Slack ein" ist nicht die Antwort, die sie suchen – und das kann deine Zertifizierung verzögern oder blockieren.
Die SOC 2 Trust Services Criteria fordern Kontrollen darüber, wie sensible Daten übertragen werden. Selbstzerstörende Links mit Aufruflimits und Verschlüsselung erfüllen diese Anforderung. Slack-Nachrichten nicht.
Was du stattdessen tun solltest
Die Lösung ist einfach: Verschlüssele die Zugangsdaten, bevor sie dein Gerät verlassen, und teile einen Link, der sich nach dem Aufrufen selbst zerstört.
Über deinen Browser
- Gehe zu vaulted.fyi
- Füge das Passwort oder die Zugangsdaten ein
- Stelle es auf 1 Aufruf ein und lass es danach ablaufen
- Sende den Link in Slack (oder wo auch immer)
Die Zugangsdaten werden mit AES-256-GCM in deinem Browser mithilfe clientseitiger Verschlüsselung verschlüsselt. Der Verschlüsselungsschlüssel existiert nur im URL-Fragment – er erreicht niemals den Server. Sobald dein Kollege den Link öffnet, wird das Geheimnis dauerhaft gelöscht.
Wenn jemand jetzt in Slack nach „password" sucht, findet er einen toten Link statt einer aktiven Zugangsdaten.
Über das Terminal
Wenn du in der Kommandozeile zuhause bist, erledigt die Vaulted CLI dasselbe:
npx vaulted-cli "staging-db-password" --views 1 --expires 1h
Per Pipe, als Skript, als Alias. Dieselbe Ende-zu-Ende-Verschlüsselung, dieselben selbstzerstörenden Links.
In CI/CD-Workflows
Zugangsdaten zwischen GitHub Actions-Workflows teilen? Die Vaulted GitHub Action übernimmt das auch:
- uses: vaulted-fyi/share-secret@v1
with:
secret: ${{ secrets.DEPLOY_KEY }}
views: 1
expires: 1h
Schnelle Regeln für dein Team
- Füge Zugangsdaten niemals direkt in eine Chat-App ein — Slack, Teams, Discord, keinen davon
- Verwende selbstzerstörende Links — Ein Aufruf, kurze Ablaufzeit, immer
- Füge eine Passphrase für sensible Zugangsdaten hinzu — Teile sie über einen separaten Kanal (Telefon, persönlich)
- Rotiere Zugangsdaten nach dem Teilen — Behandle jede Weitergabe als potenzielle Offenlegung
- Lege eine Team-Richtlinie fest — Mache verschlüsseltes Teilen zum Standard, nicht zur Ausnahme
Das Passwort in Slack wirkt im Moment harmlos. Aber es ist durchsuchbar, dauerhaft und nur eine falsch konfigurierte Integration davon entfernt, aufgedeckt zu werden.
Teile es stattdessen sicher — es dauert genauso drei Sekunden.
Verwandt
- Passwörter sicher teilen — Schritt-für-Schritt-Anleitung
- Was ist Zero-Knowledge-Architektur? — wie Vaulted deine Daten schützt
- Passwort-Generator — starke Passwörter generieren, bevor du sie teilst