Passwörter und Zugangsdaten sicher anfordern und teilen
Fordere Passwörter, API-Keys und Logins über einen einmaligen, Ende-zu-Ende-verschlüsselten Link an. Der Server sieht nie den Klartext.
Lokal in deinem Browser verschlüsselt Nur einmal lesbar Ohne Konto nutzbar Open Source
Schluss mit Passwörtern per E-Mail von Kunden anfordern.
Drei Wege, wie Vault unsichere Übergaben aus deinem Wochenalltag ersetzt.
Zugangsdaten sicher anfordern
Erzeuge einen einmaligen Anfrage-Link. Die andere Seite verschlüsselt das Geheimnis gegen ein Schlüsselpaar, das nur in deinem Browser lebt. Du bekommst Chiffretext, niemals ein Passwort per E-Mail.
Geheimnisse mit einmaligem Link teilen
Im Browser verschlüsseln, einen selbstzerstörenden Link teilen. Der erste Abruf löscht das Geheimnis serverseitig hart. Keine Kopie in Postfächern oder Chat-Verläufen.
Code und Deployment selbst nachprüfen
Jede Crypto-Zeile liegt AGPL-3.0-lizenziert auf einem öffentlichen Mirror. Die Status-Seite zeigt den deployten Commit-SHA und die SHA-256 des im Browser ausgelieferten Bundles - du kannst sie selbst nachrechnen.
Secrets für KI-Agenten: vault-ask
Dein Coding-Agent braucht einen API-Key oder ein Datenbank-Passwort? Mit vault-ask gibst du den Wert im Browser ein, und er geht nur an den einen Befehl, den du gesehen hast. Per CLI oder MCP-Server, an seinen Zweck gebunden und in der Ausgabe maskiert, damit er nie im Chat oder im Sitzungsprotokoll steht.
Ver- und Entschlüsselung passieren in deinem Browser über die native WebCrypto-API. Der Schlüssel steht im URL-Fragment und erreicht uns nie.
Strukturell gibt es bei uns keinen Klartext, der leaken, beschlagnahmt werden oder verloren gehen könnte.
AES-256 Authentifizierte GCM-Verschlüsselung
X25519 Schlüsselaustausch pro Anfrage
0 Klartext-Bytes auf dem Server
Geheimnis anfordern, ohne es je im Klartext zu sehen
Der Anfrage-Flow macht Vault einzigartig. Schluss damit, Kunden um Passwörter per E-Mail oder Slack zu bitten.
Anfrage erstellen
Dein Browser generiert lokal ein X25519-Schlüsselpaar. Der private Schlüssel verlässt nie dein Gerät.
Anfrage-Link teilen
Schick den Link an die Person mit den Zugangsdaten. E-Mail, Chat, oder Papier - der Server sieht den Schlüssel nie.
Die Person übermittelt das Geheimnis
Ihr Browser verschlüsselt das Geheimnis gegen deinen öffentlichen Schlüssel und lädt nur Chiffretext hoch.
Du holst es verschlüsselt ab
Öffne deinen Retrieval-Link. Dein Browser entschlüsselt lokal. Server-side Klartext-Exposure: null.
Die ganze Anfrage in zwanzig Sekunden
Anfrage-Link erstellen, die andere Person reicht ein, du rufst einmalig ab. In einem Zug auf vault.erseni.com aufgenommen.
So sieht es aus
Drei Schritte. Kein Account. Kein Klartext auf dem Server.
Gebaut für echte Credential-Übergaben
Der gleiche Flow, der ein einmaliges Passwort schützt, schützt jede wiederkehrende Übergabe in deinem Alltag.
Agenturen sammeln Kunden-Logins
Ein Anfrage-Link statt drei E-Mail-Threads. Nichts landet im Klartext im Postfach.
Entwickler teilen API-Keys
Stripe-Key, GitHub-PAT, AWS-Credential - übergeben ohne Kopie in Slack oder Git-History.
Support empfängt sensitive Daten
Kunden senden 2FA-Backup-Codes, Ausweisfotos oder Lizenzschlüssel per Einmal-Link statt im Ticket.
Freelancer beim Client-Onboarding
Sammle Logins für Legacy-Systeme, die der Kunde nicht in SSO einbinden kann. Verschlüsselt bei ihm, entschlüsselt bei dir.
DevOps temporäre Zugangsdaten
Gib einer Kollegin im Incident eine kurzlebige Produktions-Credential. Link läuft ab, kein Cleanup vergessen.
Interne Teams teilen Secrets
Schluss mit Passwörtern in geteilten Docs. Einmal-Link, nach dem ersten Lesen hart gelöscht, Audit-freundlich.
Der erste erfolgreiche Abruf löscht den Datensatz serverseitig hart, bevor die Antwort die Maschine verlässt. In Postfächern und Chat-Verläufen bleibt keine Kopie zurück, und in den Server-Backups liegt höchstens unlesbarer Chiffretext, bis sie nach 7 Tagen überschrieben werden.
Öffne denselben Link erneut und du bekommst nur noch „abgelaufen".
Offen gebaut, end-to-end nachprüfbar
Sechs Eigenschaften, an denen wir uns messen lassen. Jede einzelne ist im öffentlichen Quellcode nachvollziehbar.
Zero-Knowledge by Design
Der Server speichert dein Geheimnis ausschliesslich als Chiffretext. Der Entschlüsselungs-Schlüssel liegt im URL-Fragment und erreicht uns nie.
Verschlüsselung im Browser
AES-GCM-256 und X25519 laufen über die browser-native WebCrypto-API. Keine Dritt-Crypto-Library, kein Klartext über die Leitung.
Schlüssel im URL-Fragment
Browser senden den Teil nach # nie in HTTP-Requests. Wir legen den Schlüssel absichtlich dort ab, der Server kann ihn strukturell nicht sehen.
Open Source, Public Mirror
Jede Code-Zeile die mit deinem Geheimnis arbeitet ist AGPL-3.0-lizenziert und auf einem öffentlichen GitLab-Mirror einsehbar. Lies, forke, hoste selbst.
Deployment-Verifikation
Die Status-Seite zeigt Application-Commit, Component-Commit, Mirror-Commit und SHA-256 des Bundles, das dein Browser empfängt.
Dokumentierte Einschränkungen
Wir listen wogegen dieses Design nicht schützt, inklusive JS-Delivery-Risiko und Metadaten-Leakage. Keine absoluten Sicherheitsversprechen.
Warum nicht einfach OneTimeSecret, Password Pusher, PrivateBin oder Bitwarden Send?
Basierend auf öffentlicher Dokumentation und Quellcode zum Zeitpunkt der Veröffentlichung. Verschiedene Tools optimieren für unterschiedliche Threat Models. Dieser Vergleich fokussiert auf browserbasierten, einmaligen Credential-Handoff.
Eine Grenze benennen wir selbst: eine optionale Notiz, die du im Dashboard an ein Geheimnis hängst, speichern wir im Klartext. Das Geheimnis selbst können wir nie lesen.
Quellen
Jede Angabe ist gegen die verlinkte Konkurrenzquelle prüfbar. Falls ein Wert veraltet ist, eröffne ein Issue im öffentlichen Mirror, wir korrigieren die Tabelle.
OneTimeSecret (GitHub) Serverseitige Verschlüsselung mit serverseitigem Schlüssel; die optionale Passphrase ist nicht der Standardweg. Incoming Secrets (Version 0.26.0 vom 19.07.2026) ist eine Ablageseite auf einer per DNS verifizierten eigenen Domain, also kein gezieltes Anfordern bei einer bestimmten Person, und setzt beim Einsammelnden ein Konto voraus; Senden geht ohne Konto. Quelloffen und selbst hostbar. Bei der serverseitigen Verschlüsselung folgen wir der Beschreibung des Projekts, wir haben sie nicht im Quellcode nachgemessen.
Password Pusher (GitHub) Serverseitige Verschlüsselung mit serverseitigem Schlüssel; nicht zero-knowledge by design. Bietet eine Inbound-Requests-Funktion, aber Uploads werden mit serverseitigem Schlüssel verschlüsselt, der Request-Flow ist also nicht zero-knowledge. Apache-2.0, selbst hostbar, kein Account.
PrivateBin (GitHub) AES-GCM-Verschlüsselung im Browser mit Schlüssel im URL-Fragment, Server speichert nur Chiffretext. Zlib-Lizenz, selbst hostbar, kein Account.
Bitwarden Send FAQ Serverseitig verschlüsselt mit account-abgeleitetem Schlüssel; Empfänger nutzen einen Einmal-Link. Send setzt einen Sender-Account voraus. Server ist AGPL-3.0; der offizielle UI-Client/die Apps stehen unter eigener Lizenz mit proprietären Anteilen - daher der "teilweise"-Marker beim Open-Source-Vergleich.
Code überprüfen
Vertrauen entsteht durch Nachprüfbarkeit. Backend und Browser-Krypto stehen unter AGPL-3.0-Lizenz.
Quellcode: gitlab.erseni.net/open-source/secrets-component
Bedrohungsmodell: docs/architecture.md
Aktueller Build: Status-Seite zeigt den deployten Commit-SHA. Vergleiche ihn mit dem öffentlichen Mirror.
Preis
Kostenlos nutzbar, ohne Mengenbegrenzung. Kein Account. Kein Tracking. Keine Werbung.
Business ist ab sofort buchbar, du kannst Team-Mitglieder einladen. Fragen? Schreib an hello@erseni.com.
Teile dein nächstes Secret auf die sichere Art
Kein Account, kein Klartext, keine Spur. Ende-zu-Ende im Browser verschlüsselt und beim ersten Lesen vernichtet.