Sicherheit & Vertrauen

• Dein Browser verschlüsselt lokal.
• Unser Server speichert nur 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. Datenbank-WAL-Aufbewahrung bis zur Rotation gilt weiterhin. 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. Die Web-Oberfläche bietet 1-Stunden-, 24-Stunden- und 7-Tage-Voreinstellungen; API-Clients dürfen jeden Wert in diesem Bereich 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, 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. Aktuell gibt es keinen Subresource-Integrity-Hash für das Hauptbundle.
• 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.
• 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 kein Subresource-Integrity-Attribut (SRI) am Script-Tag? SRI würde den Browser ein manipuliertes Bundle automatisch ablehnen lassen, erfordert aber bei jeder Änderung neue Hashes im HTML und ist inkompatibel mit A/B-Varianten. Der Manifest-Hash bietet nicht denselben automatischen Browser-Schutz wie SRI. Er gibt Reviewern und Self-Hostern einen konkreten SHA-256-Wert, den sie gegen das ausgelieferte Browser-Bundle vergleichen können.