Schluss mit Kundenpasswörtern per E-Mail.
Fordere Passwörter, API-Keys und Logins über einen einmaligen, Ende-zu-Ende-verschlüsselten Link an. Der Server sieht nie den Klartext.
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.
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.
Sie übermitteln 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.
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 Recovery-Seeds 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.
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 ausschliesslich 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 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.
| Eigenschaft | Erseni Vault | Password Pusher | PrivateBin | Bitwarden Send |
|---|---|---|---|---|
| Zero-Knowledge (Server sieht nie Klartext) | Ja | Nein | Ja | Ja |
| Zugangsdaten von jemandem anfordern | Ja | Nein | Nein | Nein |
| Open Source | Ja | Ja | Ja | Teilweise |
| Selbst hostbar | Ja | Ja | Ja | Ja |
| Ohne Account nutzbar | Ja | Ja | Ja | Nein |
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.
Password Pusher (GitHub) Serverseitige Verschlüsselung mit serverseitigem Schlüssel; nicht zero-knowledge by design. AGPL-3.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
Für private Nutzung kostenlos. Kein Account. Kein Tracking. Keine Werbung.
Business-Tarif mit Audit-Logs, eigenem Branding und SLA folgt. Frühzugang gewünscht? Schreib an hello@erseni.com.