Sicherheit & Vertrauen

• Dein Browser verschlüsselt lokal.
• Dein Geheimnis speichert unser Server nur als Chiffretext.
• Der private Schlüssel bleibt in deinem Link.
• Nach dem ersten erfolgreichen Lesen wird der Datensatz gelöscht.
• Der Code ist öffentlich prüfbar.
• Einschränkungen dokumentieren wir offen.

• AES-GCM-256 über die browsereigene WebCrypto-API; keine Dritt-Crypto-Library im Auslieferungspfad. secrets.js:211-217
• X25519-Schlüsselaustausch kombiniert mit HKDF-SHA256-Ableitung, vollständig im Browser über WebCrypto. secrets.js:256-269, secrets.js:425-453
• 12 Byte zufällige Nonce pro Chiffretext (96-Bit GCM-IV), 22 Zeichen URL-sichere Tokens (128 Bit Entropie). SecretService.php:24, SecretService.php:36-38
• Optionaler Passwortschutz: PBKDF2-SHA256 mit 1.200.000 Iterationen gemäß OWASP-2024-Empfehlung; Salt + Iterationszahl reisen im URL-Fragment, ältere Links bleiben gültig. SecretService.php:52, secrets.js:271-293

• Hartes Löschen beim ersten erfolgreichen Lesen, atomares DELETE...RETURNING. Keine Soft-Delete-Tabelle, kein Anwendungs-Backup von Chiffretext-Zeilen. Die Transaktionsprotokolle der Datenbank (WAL) werden fortlaufend überschrieben und nicht archiviert; tägliche Server-Sicherungen werden nach 7 Tagen überschrieben, das Chiffrat darin bleibt unlesbar. SecretService.php:55-79
• Pro-IP-Rate-Limit von 10 Erstellungen und 20 Abrufen pro Minute, plus globale Obergrenze von 200 Schreib- und 500 Leseoperationen pro Minute zum Schutz der Verfügbarkeit. Create.php:82 , Retrieve.php:42
• TTL serverseitig erzwungen zwischen 1 Minute und 7 Tagen, in den Tarifen Pro und Business bis zu 30 Tagen. Die Web-Oberfläche bietet 1-Stunden-, 24-Stunden- und 7-Tage-Voreinstellungen; API-Clients dürfen jeden Wert im Bereich ihres Tarifs wählen. SecretsValidators.php:43-52
• Maximal 1 MB Chiffretext, im Validator und im Service-Layer durchgesetzt. SecretService.php:28, SecretService.php:300-306

• Live-Statusseite zeigt den deployten Commit-SHA und die Umgebung, sodass du den laufenden Build pinnen kannst. /status
• RFC-9116-konforme security.txt mit Kontakt, PGP-Schlüssel, Policy und Acknowledgements. /.well-known/security.txt
• Backend-Service und Browser-Krypto sind unter AGPL-3.0-Lizenz auf einem öffentlichen Mirror veröffentlicht. LICENSE

• Wie bei jedem webbasierten Krypto-Tool gilt der Schutz nur, solange das ausgelieferte JavaScript das ist, das wir ausliefern wollen. Eine Server-Kompromittierung (oder ein erfolgreicher TLS-Man-in-the-Middle mit vertrauenswürdigem Zertifikat) könnte ein bösartiges Bundle einschleusen, das Klartext vor der Verschlüsselung exfiltriert. Das Hauptbundle wird inzwischen mit einem erzwungenen Subresource-Integrity-Hash ausgeliefert; der stoppt ein ausgetauschtes Asset, aber nicht einen Server, der zum manipulierten Bundle den passenden Hash mitliefert. Die Skripte der Web Components, die Fremdbibliotheken und die Stylesheets tragen gar keinen Hash.
• Es wurde noch kein Drittpartei-Krypto-Audit veröffentlicht. Solange das fehlt, ruht „Vertrauen" auf dem Open-Source-Mirror plus deiner eigenen Prüfung.

Der Klartext bleibt im Browser, aber der Server beobachtet schon allein durch den Betrieb des Services einige Dinge.

• Optionale Labels reisen base64-kodiert im URL-Fragment, damit der Sender sie sehen kann. Behandle sie als URL-Metadaten, nicht als verschlüsselten Inhalt; lege keine geheimen Informationen in das Label-Feld.
• Dashboard-Notizen liegen im Klartext neben dem Besitzeintrag und sind für uns und für alle Mitglieder deiner Organisation lesbar. Halte dort fest, wofür ein Geheimnis war, nie die geheime Information selbst.
• Die Chiffretext-Länge wird unverändert gespeichert; die Byte-Größe eines Geheimnisses ist für jeden mit Datenbankzugriff sichtbar.
• Application-Logs schreiben Request-IP-Hashes (sha256, abgeschnitten - nicht roh) und Route-Patterns. Token-Segmente werden vor dem Loggen vom SecretLogger-Redaction-Filter ersetzt.
• Ein Netzwerkbeobachter zwischen dir und unserem Server sieht Request-Größe und Timing-Muster. Padding auf feste Chiffretext-Länge steht auf der Roadmap; heute ist die Größe das, was du eingibst, plus ein 16-Byte-GCM-Tag.

• Wähle die kürzeste TTL, mit der du leben kannst. Default eine Stunde für Ad-hoc-Geheimnisse; sieben Tage nur wenn der Empfänger offline ist.
• Füge ein Passwort hinzu. Der Empfänger braucht beides - Link und Passwort - ein geleakter Link allein ist nutzlos. Das Passwort leitet einen zusätzlichen Schlüssel via PBKDF2-SHA256 mit 1,2M Iterationen ab.
• Lass das Label leer, wenn der Kontext selbst sensitiv ist. Labels reisen im URL-Fragment für die Absender-Vorschau, sind aber kein verschlüsselter Inhalt.
• Sende den Link über einen Kanal, das Passwort über einen anderen. Eine Single-Channel-Kompromittierung leakt dann keine Hälfte.
• Bevor du etwas einfügst: prüfe die URL-Leiste auf exakt vault.erseni.com (oder deine selbst gehostete Domain). Eine Look-alike-Domain mit bösartigem Bundle ist der stärkste praktische Angriff gegen dieses Design.

Wenn du Journalist, Aktivist oder anderweitig einem gut ausgestatteten Gegner ausgesetzt bist: Browser-ausgelieferte Krypto ist nicht das stärkste Werkzeug. Behandle Vault als Komfort-Layer mit dokumentiertem Threat-Model, nicht als Ersatz für die folgenden Praktiken.

• Hoste eine eigene Instanz unter deiner eigenen Domain. Du vertraust dann deinem JavaScript-Build, nicht unserem.
• Für langlebige Geheimnisse: nimm ein Offline-Tool wie age, GPG oder einen Hardware-Token. Die sind ohne laufenden Server auditierbar.
• Lies den secrets.js-Quellcode bevor du dich auf vault.erseni.com verlässt. Das Bundle passt auf einen Bildschirm.
• Für Seed-Phrases, Schlüsselmaterial oder alles, was ein Konto finanziert oder Zugriffe widerruft: bevorzuge Ende-zu-Ende-verschlüsselte E-Mail mit PGP oder eine persönliche Übergabe.

Quell-Mirror: gitlab.erseni.net/open-source/secrets-component

Deployter Build: Status-Seite

security.txt: /.well-known/security.txt

Du musst uns nicht glauben welches JavaScript du gerade ausführst. Hier ist die konkrete Kette, die du selbst nachgehen kannst.

1. Öffne das Build-Manifest. Es listet Application-Commit, Component-Commit, Mirror-Commit und SHA-256 jedes vom Browser geladenen Assets. /build-manifest.json
2. Klick auf den Mirror-Commit. Das öffnet den exakten Quellstand auf dem Public-Mirror, der mit diesem Deploy veröffentlicht wurde.
3. DevTools öffnen, secrets-Script-URL kopieren, abrufen und hashen. Das Ergebnis muss zum browserJs.sha256 im Manifest passen. curl -s '<script src from DevTools>' | sha256sum
4. Lies die Datei auf dem Mirror. Die Browser-Krypto passt auf einen Bildschirm und nutzt ausschliesslich natives WebCrypto.

Warum von Hand vergleichen, wenn das Script-Tag bereits ein Subresource-Integrity-Attribut (SRI) trägt? SRI lässt den Browser ein Bundle ablehnen, das nicht zum Hash im HTML passt, aber beide stammen aus demselben Deploy: ein kompromittierter Server liefert einfach ein neues Paar. Der Manifest-Hash kommt vom selben Server und teilt diese Grenze. Unabhängig wird die Prüfung erst durch den öffentlichen Mirror: ein getrenntes System mit öffentlich einsehbarer Historie, gleiche die Werte des Manifests also gegen den Mirror-Commit ab und lies den Quellcode dort. Die Skripte der Web Components, die Fremdbibliotheken und die Stylesheets tragen heute keinen SRI-Hash.