Pssst.io – Teile deine Secrets

Passwörter, API Keys, Zugangsdaten, Kundendaten: Wir alle schicken sie im Alltag viel zu oft mal schnell herum, im Chat, per E Mail, im Ticketsystem oder als Screenshot. Und selbst wenn man es besser weiss, gewinnt meistens der Workflow gegen die Security. Genau aus dieser Spannung ist PSSST entstanden.

PSSST steht für «Personal Secure Secret Sharing Tool». In der Praxis ist es mein kleines, sehr zielgerichtetes Tool, um Secrets zu teilen, ohne dass sie unkontrolliert durch Drittanbieter-Ökosysteme wandern.

Warum noch ein Tool?

Wir arbeiten täglich mit sensiblen Daten wie beispielsweise Zugangsdaten zu Kunden-Instanzen (CMS / Hosting / DNS), API-Tokens (Maps / Payment / Newsletter / Monitoring), SSH-Keys sowie Testzugänge und temporäre Accounts. Und egal wie sauber man arbeitet: Sobald ein Secret einmal in einem Chatverlauf oder E-Mail-Thread landet, ist es gespeichert, indexiert, repliziert und damit praktisch nie wieder wegzubekommen.

Die konkrete Motivation dahinter: Ein Tool zu haben, das vollständig unter Kontrolle steht, damit wir garantieren können, dass sensible Daten nicht ungeschütztversendet und nicht ungewollt bei Dritten gespeichert werden. Kontrolle heisst hier nicht misstrauisch zu sein, sondern Verantwortung zu übernehmen.

Was PSSST ist

PSSST ist ein kleinfeines, fokussiertes Tool für einen einzigen Job: Secrets sicher teilen. Ein zentraler Punkt bei PSSST ist das Zero-Trust-Modell. Das bedeutet, dass auch ich als Betreiber nichts mitlesen kann. Alles, was ich sehe, sind wenige Metadaten, die für den Betrieb notwendig sind. Aber niemals dein Secret.

• Das Tool teilt Secrets, ohne sie in Chats oder E-Mails zu verewigen.
• Es ist Workflow-freundlich: schnell, seriös, kompromisslos.
• Und es ist sicher: dank starker Verschlüsselung praktisch unknackbar.

Und ganz bewusst will das Tool kein All-in-One-Passwortmanager sein, kein Ticketing-System sein und kein Kollaborationstool sein. 

Viele Teams haben technisch gute Systeme, aber menschlich realistische Prozesse: «Schick mir den Key kurz im Slack» oder «Kannst du das Passwort ins Ticket schreiben?». Das ist kein individuelles Fehlverhalten, es ist ein Systemproblem:

• Chat Systeme sind zum Chatten optimiert, nicht zum Secret Handling. 
• E Mail ist für Nachvollziehbarkeit gebaut, nicht für Vergänglichkeit.
• Tickets sind für Dokumentation da, und Secrets passen da maximal schlecht rein.

Wenn Security nur funktioniert, wenn alle immer perfekt sind, funktioniert sie nicht. PSSST soll deshalb das Gegenteil sein: sicher, weil es der einfachste Weg ist.

PSSST ist für alle gedacht – auch für dich

Für die private Nutzung, wenn man zum Beispiel einmalig ein Passwort oder eine PIN teilen muss. Für den beruflichen Einsatz, wenn man Zugangsdaten, Tokens oder andere sensible Daten mit Teammitgliedern, Kund:innen oder Partner:innen austauscht. Und überhaupt immer dann, wenn man kurzlebige Secrets teilen möchte und vermeiden will, dass sie in dauerhaften Kanälen wie Chatverläufen, E-Mails oder Tickets landen.

Wenn du dich in den Beispielen wiedererkennst, probier es auf PSSST.IO aus. Ganz besonders, wenn du aktuell noch sensible Daten über Chat, E Mail oder Tickets verschickst.

Für die ganz Neugierigen: Die Technik dahinter

Dieser Abschnitt richtet sich an Profis und alle, welche detailliertere Informationen über die Webapp suchen.

1. Zero Trust

PSSST ist so gebaut, dass der Betreiber den Inhalt eines Secrets nicht entschlüsseln kann. Das ist keine Policy, sondern eine Folge der Architektur.

• Der Browser verschlüsselt vor dem Upload
• Der Server speichert nur Ciphertext und Metadaten
• Der Schlüssel ist nur im Link Fragment enthalten und wird nicht an den Server übertragen

2. Kryptographie

Die Client-Logik nutzt WebCrypto und setzt auf AES-GCM mit einem 256-Bit-Key.

• Key-Derivation: PBKDF2 mit SHA-256 und 250000 Iterationen
• Salt: 16 Bytes, zufällig pro Secret
• IV: 12 Bytes, zufällig pro Secret
• Cipher: AES-GCM, Auth-Tag ist in WebCrypto im Ciphertext enthalten

Der verschlüsselte Payload wird als Bundle serialisiert: v1:saltB64:ivB64:ciphertextB64
Damit ist das Format eindeutig versioniert und enthält alles, was zur Entschlüsselung benötigt wird, ausser dem Schlüssel selbst.

3. Schlüsselmaterial und Link-Aufbau

Der Entschlüsselungsschlüssel ist ein zufälliger Wert, der lokal erzeugt und als Hex-String kodiert wird. Er wird an den Empfänger ausschliesslich über den URL-Hash gegeben. Der Ablauf sieht vereinfacht so aus:

• Client generiert encryptionKey als 16 zufällige Bytes und kodiert ihn als Hex.
• encryptionKey wird als Passwort in PBKDF2 verwendet.
• Das Ergebnis der Verschlüsselung wird an den Server gesendet.
• Der Empfänger-Link enthält die Retriever UUID plus den Key im Fragment.

Wichtig ist dabei der Fragment-Teil: Alles nach # wird nicht mit HTTP-Requests an den Server übertragen. Dadurch taucht der Schlüssel nicht im Server-Access-Log auf und landet nicht in üblichen Request-Traces.

4. Server-Sicht, Retrieval und Fehlermodelle

Beim Abruf passiert Folgendes:

• Der Client liest uuidRetriever aus dem Fragment und lädt den Ciphertext via API.
• Der Client liest den Key aus dem Fragment und entschlüsselt lokal.
• Bei Key-Fehlern oder Manipulation am Ciphertext schlägt AES-GCM sauber fehl und es gibt keinen Klartext.

Der Betreiber kann dabei weiterhin Metadaten sehen, je nach Logging:

• Zugriffsmuster, Objektgrösse, Status und Ablaufzeit
• IP-Adresse und User-Agent, falls bewusst geloggt

5. Status Modell und Lifecycle

Auf Serverseite gibt es ein explizites Status-Modell für ein Secret, zum Beispiel: verfügbar, abgelaufen, gelöscht durch Ersteller, gelöscht durch Admin, gelöscht nach Abruf. Der Retriever bekommt vorab Metainformation, damit er weiss, ob eine Entschlüsselung überhaupt noch Sinn macht.

6. Grenzen des Modells

Zero Trust schützt den Inhalt vor dem Betreiber, ersetzt aber keine Endpoint-Security. Ein kompromittierter Browser oder XSS im Frontend kann den Klartext vor der Verschlüsselung oder nach der Entschlüsselung abgreifen.

Wichtig: Sicherheit ist nie nur Kryptographie, sondern auch Prozess. Darum ist PSSST bewusst so gebaut, dass der sichere Weg der einfache ist.

PSSST.IO wurde gebaut von Andy Abderhalden. 

Mit Sorgfalt und einem gesunden Misstrauen gegenüber «mal schnell« schicken. Probiers aus.