Bedrohungsmodell & OWASP ASVS L1 Self-Attestation

Dieses Modell umfasst den Produktions-Deployment von vaulted.fyi einschließlich seines Web-Frontends, API-Routen und Upstash Redis-Speicherung. Es umfasst auch das veröffentlichte CLI und den MCP-Server, soweit sie mit derselben API interagieren.

Außerhalb des Umfangs:

• Das Endgerät des Nutzers (Browser, OS, Erweiterungen, Zwischenablage, Bildschirm).
• Der Kommunikationskanal, über den der Freigabe-Link zugestellt wird (E-Mail, Slack, SMS usw.).
• Der anschließende Umgang des Empfängers mit dem Klartext.
• Schwachstellen in Vercel oder Upstash unterhalb der API-Oberfläche, die wir nutzen.

Primäres Asset: das Geheimnis im Klartext. Es darf den Server nie erreichen, außerhalb der Browser von Absender und Empfänger nie persistieren und allein aus dem serverseitigen Zustand nie wiederherstellbar sein.

Sekundäre Assets: Geheimtext, IVs, Aufrufzähler, Ablauf-Zeitstempel sowie die Integrität und Verfügbarkeit des Dienstes.

Vertrauensgrenzen (in absteigender Vertrauensreihenfolge):

1. Browser des Absenders — vertrauenswürdig mit Klartext und Schlüssel.
2. Browser des Empfängers — nach dem Öffnen des Links vertrauenswürdig mit Klartext und Schlüssel.
3. Netzwerk zwischen Client und Server — nicht vertrauenswürdig; gemildert durch TLS 1.3 und die Design-Entscheidung, dass nur Geheimtext ihn überquert.
4. Vaulted-Server (wir) — bedingt vertrauenswürdig. Wird als passiver Geheimtext-Speicher behandelt. Das Bedrohungsmodell geht davon aus, dass Vaulted selbst kompromittiert werden könnte, ohne Klartext preiszugeben.
5. Upstash Redis — gleiche Vertrauensstufe wie der Server. Nur verschlüsselte Blobs.

Passiver Netzwerkbeobachter. ISP, On-Path-Akteur mit Zugriff auf TLS-Metadaten. Wird durch TLS und das Fehlen von Klartext oder Schlüssel im Übertragungsweg abgewehrt.

Aktiver Netzwerkangreifer. Kann einen MitM-Angriff versuchen. Wird durch TLS, HSTS Preload und Zertifikatsvalidierung abgewehrt. Eine erfolgreiche TLS-Kompromittierung liefert trotzdem nur Geheimtext.

Kompromittierter Server / feindlicher Betreiber. Schließt uns ein. Kann gespeicherte Geheimnisse nicht lesen, weil der Schlüssel nie ankommt. Kann den Dienst verweigern oder das ausgelieferte JS-Bundle modifizieren — in den Restrisiken weiter unten behandelt.

Nicht authentifizierter Angreifer mit einem gültigen Freigabe-Link. Per Design kann jeder mit dem vollständigen Link entschlüsseln. Aufruflimits, Ablauf und optionale Passphrase reduzieren das Zeitfenster. Das ist eine bewusste Eigenschaft, kein Bug.

Gezielter Angreifer gegen einen bestimmten Absender oder Empfänger. Kann das Endgerät, den Zustellkanal oder den Umgang des Empfängers nach der Entschlüsselung ausnutzen. Außerhalb von Vaulteds Kontrolle; aus Transparenzgründen dokumentiert.

• Clientseitige AES-256-GCM-Verschlüsselung mit zufälligen 96-Bit-IVs aus crypto.getRandomValues.
• 256-Bit-Schlüssel pro Geheimnis generiert via crypto.subtle.generateKey; im URL-Fragment platziert, nie übertragen.
• Optionales Passphrase-Wrapping mit PBKDF2 (hohe Iterationszahl) und AES-GCM Key Wrapping.
• Atomare Aufrufzähler-Durchsetzung via Redis HINCRBY mit Löschung in derselben Transaktion beim Erreichen des Limits.
• TTL-basierter automatischer Ablauf, auf 30 Tage begrenzt; keine Verlängerung nach der Erstellung.
• Pro-IP Sliding-Window Rate Limiting auf Create- und View-Endpunkten.
• noindex auf /s/[id]-Ansichtsseiten, damit Geheimnis-URLs nicht über Suchanfragen durchsickern.
• TLS 1.3 mit HSTS Preload, sichere Security-Header, kein IP-Logging über Rate-Limit-Fenster hinaus.

Das sind bewusste Grenzenentscheidungen, dokumentiert damit Nutzer entscheiden können, ob Vaulted zu ihrem Bedrohungsmodell passt.

• Kompromittierung des Endgeräts. Ein Keylogger, infizierter Browser oder eine feindliche Erweiterung kann Klartext nach der Entschlüsselung lesen.
• Leck im Zustellkanal. Wird der Freigabe-Link weitergeleitet, archiviert oder in einem antwortenden E-Mail-Thread zitiert, wird dieser Kanal zur Angriffsfläche.
• Gezielter Bundle-Swap. Ein kompromittiertes CDN oder ein Vercel-Edge könnte einem bestimmten Nutzer ein anderes JS ausliefern. Subresource Integrity und reproduzierbare Builds sind partielle Gegenmaßnahmen und stehen auf der Roadmap.
• Verhalten des Empfängers. Nach der Entschlüsselung kann der Empfänger kopieren, einen Screenshot machen oder weiterleiten.
• Schwache Passphrase. Wird eine schwache Passphrase verwendet, ist sie durch jeden mit dem gekapselten Schlüssel per Brute-Force angreifbar.
• Nötigung / Zwang. Außerhalb des Umfangs jeder technischen Kontrolle.

Die folgende Matrix bildet Vaulteds Implementierung auf ausgewählte OWASP ASVS Level 1-Anforderungen ab. Kategorien, die nicht zutreffen (Sessions, Authentifizierung, Datei-Upload), sind mit N/A und einer kurzen Begründung markiert statt weggelassen — damit das Fehlen eines Eintrags nicht als Ausweichen interpretiert wird.

Die Nummerierung folgt der ASVS-4.0-Struktur. Die Liste ist ausgewählt, nicht erschöpfend — das Ziel ist Ehrlichkeit über die Kontrollen, die für einen zustandslosen, kontofreien verschlüsselten Geheimtext-Speicher sinnvoll zutreffen.

Jede Änderung, die einen Punkt in diesem Dokument betrifft — neuer Endpunkt, kryptografische Änderung, Dependency-betreffendes Refactoring, Infrastruktur-Änderung — muss eine Überprüfung dieser Seite im selben PR auslösen. Version und Veröffentlichungsdatum oben werden inkrementiert, wenn das Dokument aktualisiert wird; die Vorversion bleibt im öffentlichen Git-Verlauf zugänglich.