Klar dokumentierte Sicherheitsgrenzen
Wie Vaultigen Ihre Geheimnisse schützt.
Was verschlüsselt ist, wo die Schlüssel liegen, wer ein Passwort anzeigen darf, was ein Angreifer sehen würde und wie Wiederherstellung funktioniert. Einschließlich der Grenzen des Designs.
Die Antwort in 60 Sekunden
- 01
Geheime Werte werden vor dem Speichern verschlüsselt. Datenbank und Dateispeicher erhalten Chiffretext, keine nutzbaren Passwörter.
- 02
Jeder Tresor hat einen eigenen Schlüssel. Tresorschlüssel sind mit einem Installationsschlüssel verschlossen, der außerhalb der Datenbank liegt.
- 03
Bei jeder sensiblen Anfrage wird der Zugriff geprüft. Anzeigen, Downloads, Freigaben, Verschiebungen und Löschungen werden auf dem Server autorisiert.
- 04
Der Host bleibt vertrauenswürdig. Das ist serverseitige Verschlüsselung, keine Zero-Knowledge-Verschlüsselung. Diese Grenze ist bewusst gewählt und dokumentiert.
Entworfen zum Schutz vor
- Einem gestohlenen Datenbank-Dump oder Backup ohne Installationsschlüssel
- Gestohlenem Anhangspeicher ohne dessen Schlüssel
- Versehentlicher Offenlegung über Datenbankwerkzeuge und Replikate
- Benutzern, die auf nicht freigegebene Tresore zugreifen wollen
- Unbemerkter Veränderung verschlüsselter Werte
- Versehentlichem Überschreiben oder Löschen
Nicht entworfen zum Schutz vor
- Einem kompromittierten Betriebssystem oder PHP-Prozess
- Einem Betreiber, der veränderten Code einspielen kann
- Dem Diebstahl von Daten und Schlüsseln
- Schadsoftware oder bösartigen Browser-Erweiterungen auf dem Gerät
- Einem Passwort, das jemand bereits gesehen oder kopiert hat
Das ist keine Zero-Knowledge-Verschlüsselung, und wir behaupten das auch nicht.
Der Vaultigen-Server kann ein Geheimnis für eine berechtigte Person entschlüsseln. So werden kontrolliertes Teilen, Protokollierung und Notfallzugriff möglich, wenn jemand krank, nicht erreichbar oder nicht mehr im Unternehmen ist. Das ist keine Bequemlichkeit statt Verschlüsselung: Geheime Werte werden vor dem Speichern verschlüsselt, und jedes Anzeigen wird autorisiert und protokolliert. Die verbleibende Vertrauensgrenze legen wir offen: Wer die laufende Anwendung oder den Host kontrolliert, kann auf Geheimnisse zugreifen.
Diese Unterscheidung ist wichtig. In einer 2026 veröffentlichten Analyse fanden Forschende der ETH Zürich und der Università della Svizzera italiana 31 Angriffe auf vier große Cloud-Passwortmanager in einem Bedrohungsmodell mit vollständig bösartigem Server – obwohl diese Produkte mit Zero-Knowledge-Verschlüsselung warben. Die Studie zeigt nicht, dass Vaultigen vor einem solchen Server schützt. Sie zeigt, dass ein Zero-Knowledge-Versprechen kein Ersatz für ein dokumentiertes Bedrohungsmodell, die Prüfung der Implementierung und betriebliche Schutzmaßnahmen ist. Für Organisationen, die nachvollziehbare Wiederherstellung benötigen, halten wir ein offen gelegtes serverseitiges Modell mit kontrolliertem, protokolliertem Notfallzugriff für praktikabler als ein absolutes Versprechen.
Zur Studie (ePrint 2026/058)Die Schutzebenen
Envelope-Verschlüsselung
Einträge werden mit XChaCha20-Poly1305 unter einem Schlüssel pro Tresor versiegelt. Tresorschlüssel sind mit einem Installationsschlüssel außerhalb der Datenbank verpackt. Dateien erhalten einen eigenen Schlüssel und werden als authentifizierter Stream verschlüsselt.
Frische Autorisierung
Benutzer erhalten nie Schlüssel. Jedes Anzeigen prüft Konto, Teams, Berechtigungen und Ablauf neu, schreibt zuerst das Audit-Ereignis und liefert genau ein Feld mit no-store aus.
Starke Anmeldung
Konten nur auf Einladung, MFA ist Pflicht (Authenticator-App oder E-Mail-Code), 15 Minuten Inaktivitäts-Timeout, erneute Authentifizierung für riskante Aktionen. Passkeys sind geplant.
Manipulationserkennendes Audit
Eine SHA-256-Hashkette mit HMAC-Prüfpunkten, deren Schlüssel außerhalb der Datenbank liegt. Geheimnisse, Codes und Schlüssel werden nie protokolliert.
Kein stiller Admin-Zugriff
Plattformrollen geben keinen dauerhaften Zugriff auf Geheimnisse. Der Notfallzugriff ist ein separater Ablauf: ein Tresor, nur lesend, 30 Minuten, mit Begründung, frischer MFA und Benachrichtigungen.
Eigener Backup-Schlüssel
Vollständige Backups werden mit einem Schlüssel verschlüsselt, der unabhängig von der Live-Installation ist, und vor der Erfolgsmeldung verifiziert.
Was in der Datenbank lesbar bleibt
Die Suche braucht einen kleinen Index. Alles, was ein Zugangsdatum sein kann, ist verschlüsselt.
| Lesbar gespeichert | Verschlüsselt gespeichert |
|---|---|
| Eintragstitel | Benutzername und Passwort |
| Bereinigter Host, etwa example.com | Vollständige URL, Query-String und Fragment |
| Namen von Tresoren, Ordnern und Tags | Notizen und jeder Wert eigener Felder |
| Besitzer und Zeitstempel | Dateiname und Inhalt von Anhängen |
| Audit-Aktion, Person, IP und Browser | Geheime Werte, Schlüssel und Request-Bodies |
Was passiert, wenn etwas schiefgeht
Die Datenbank wird gestohlen
Ein Benutzerkonto wird gestohlen
Jemand verlässt das Unternehmen
Ein Super-Admin ist neugierig
Der Server wird kompromittiert
Der Installationsschlüssel geht verloren
Audit-Status
Vaultigen hat noch kein unabhängiges Sicherheitsaudit abgeschlossen. Vor der stabilen Version ist ein unabhängiges Security-Review mit Penetrationstest ohne offene kritische oder hohe Befunde Voraussetzung, zusammen mit automatisierten Tests der Sicherheitsgrenzen auf jeder unterstützten Datenbank, Abhängigkeits- und Secret-Scans und einer Wiederherstellungsübung auf einer frischen Installation. Das Ergebnis veröffentlichen wir hier.
- Quellcode für Ihre eigene Prüfung einsehbar
- Sicherheitsgrenzen durch automatisierte Tests abgedeckt
- Abhängigkeitsprüfung und Secret-Scans in der CI
- Software-Stückliste (SBOM) für jeden Build
Kein Kontakt zum Hersteller
Vaultigen kontaktiert uns nie: keine Telemetrie, keine Aktivierung, keine Update-Prüfung, kein Lizenzserver. Lizenzen werden offline geprüft. Die einzige optionale ausgehende Anfrage ist die Funktion Website-Icons, die das Icon eines Logins direkt von dessen Website lädt und sich abschalten lässt.
Verantwortungsvolle Offenlegung
Sie haben eine Sicherheitslücke gefunden? Bitte melden Sie sie vertraulich, nicht als öffentliches Issue. Wir bestätigen den Eingang, halten Sie auf dem Laufenden und nennen Sie, wenn Sie das möchten.