So schützt Passbox Ihre Daten

• Ihre Daten werden auf Ihrem Gerät verschlüsselt, bevor sie es verlassen. Der Server speichert nur verschlüsselte Daten.
• Zwei Geheimnisse schützen Ihr Konto: Ihr Master-Passwort und Ihr Geheimschlüssel.
• Die Anmeldung funktioniert, ohne Ihr Master-Passwort zu senden.
• Freigaben werden mit Post-Quanten-Kryptografie versiegelt, Mitglieder mit Sicherheitscodes geprüft.
• Niemand bei Passbox kann Ihren Tresor lesen, und niemand kann Ihr Master-Passwort zurücksetzen.
• Passbox ist vollständig Open Source unter der MIT-Lizenz.

Sie müssen uns nichts davon einfach glauben:

• Das vollständige Design ist öffentlich und im Repository dokumentiert, direkt neben dem Code.
• Jede Änderung wird automatisch gebaut und getestet, einschließlich einer Prüfung aller Rust-Abhängigkeiten auf bekannte Schwachstellen.
• Passbox ist vollständig Open Source unter der MIT-Lizenz; jeder kann es lesen und bauen.
• Schwachstellen können vertraulich gemeldet werden, siehe unten.

Der Schlüssel zu Ihrem Tresor entsteht aus zwei Dingen: Ihrem Master-Passwort, das nur Sie kennen, und Ihrem Geheimschlüssel, einem langen Zufallscode, der auf Ihrem ersten Gerät erzeugt wird. Der Geheimschlüssel wird nie an uns gesendet. Er steht in Ihrem Notfall-Kit, und Sie geben ihn auf jedem neuen Gerät einmal ein oder übertragen ihn mit einem Gerätecode.

Warum zwei? Wer eine Kopie einer Server-Datenbank stiehlt, könnte Milliarden Passwörter pro Sekunde dagegen ausprobieren. Ohne den Geheimschlüssel funktioniert das nicht, egal wie einfach Ihr Master-Passwort ist.

Die meisten Dienste prüfen Ihr Passwort, indem sie es empfangen, oder eine verschlüsselte Form davon. Passbox nutzt stattdessen ein Verfahren namens OPAQUE: Ihr Gerät beweist, dass es das Passwort kennt, ohne es zu senden.

Selbst unser Server, oder jemand, der ihn übernommen hat, erfährt Ihr Master-Passwort deshalb nie.

Jeder Eintrag wird auf Ihrem Gerät verschlüsselt, auch Titel, Benutzername und Website, nicht nur das Passwort. Nur Ihre Geräte können ihn entschlüsseln.

Jeder Eintrag ist zudem an seinen Platz gebunden: Der Server kann ihn nicht unbemerkt in einen anderen Tresor verschieben, mit einem anderen Eintrag vertauschen oder eine alte Version als neuere ausgeben.

Wenn Sie einen Tresor teilen, versiegelt Ihr Gerät seinen Schlüssel für den öffentlichen Schlüssel jedes Mitglieds. Diese Schlüsselpaare kombinieren heutige Elliptische-Kurven-Kryptografie mit ML-KEM, einem Verfahren, das Quantencomputern standhalten soll (X-Wing). Was Sie heute teilen, bleibt privat, auch wenn jemand es jetzt mitschneidet und später entschlüsseln will.

Öffentliche Schlüssel landen in einem Schlüsselverzeichnis, das nur wachsen kann, und jede Freigabe ist von der Person signiert, die sie erteilt hat. Administratoren bestätigen neue Mitglieder, indem sie einen Sicherheitscode vergleichen. Ein Server, der einen eigenen Schlüssel unterschieben will, fällt auf; genau diesen Angriff haben Forschende 2026 gegen andere Passwortmanager eingesetzt.

Wird ein Mitglied entfernt, werden die Tresorschlüssel ersetzt. Details stehen in docs/architecture/sharing.md.

Niemand kann Ihr Master-Passwort zurücksetzen. Stattdessen gibt es unabhängige Wege zurück zu Ihrem Kontoschlüssel: einen Wiederherstellungscode im Notfall-Kit, die Wiederherstellung über Ihre Familie oder Ihr Team (standardmäßig an, Administratoren können den Zugang also wiederherstellen) und Notfallzugang für eine Vertrauensperson nach einer Wartezeit, die Sie abbrechen können.

Jeder dieser Wege wird auf Ihrem Gerät für Schlüssel versiegelt, die der Server nicht hat. Eine Wiederherstellung setzt ein neues Master-Passwort und einen neuen Geheimschlüssel, meldet alle Geräte ab und schickt Ihnen eine E-Mail.

Das Bedrohungsmodell, auch was ein freigebender Administrator sehen kann, steht in docs/architecture/recovery.md.

Zusätzlich zu den zwei Geheimnissen können Sie Ihr Konto mit einer Authenticator-App, Sicherheitsschlüsseln oder Passkeys und zehn einmaligen Wiederherstellungscodes schützen. Jeder Code funktioniert einmal, und Fehlversuche sind begrenzt.

Passbox ist Zero-Knowledge: Der Server kann Ihre Einträge und Schlüssel nicht lesen. Für seine Arbeit speichert er aber einiges:

• Ihre E-Mail-Adresse und Ihre öffentlichen Schlüssel
• Ihre verschlüsselten Einträge mit Größe, IDs, Versionsnummern und Zeitstempeln
• zu welchen Organisationen, Gruppen und geteilten Tresoren Sie gehören, und Ihre Rolle
• Ihre angemeldeten Geräte mit Namen und IP-Adressen
• das Aktivitätsprotokoll Ihres Kontos: An- und Abmeldungen, Passwort- und Zwei-Faktor-Änderungen, Wiederherstellungen

Er erhält nie Ihr Master-Passwort, Ihren Geheimschlüssel oder einen Schlüssel, mit dem sich Ihre Daten entschlüsseln ließen.

In der Datenbank: PostgreSQL enthält nur, was oben steht, Ihre Einträge also auch dort nur verschlüsselt. Row-Level Security ist eine zweite Verteidigungslinie: Die API verbindet sich mit einer eigenen Rolle, die nur die Zeilen des angemeldeten Kontos und seiner Organisationen sieht; Migrationen und Hintergrundaufgaben nutzen getrennte Rollen. Das begrenzt den Schaden eines Fehlers im Server, ersetzt aber nicht die Verschlüsselung.

Passbox ist vollständig öffentlich unter der MIT-Lizenz: der Server, jede App und der Verschlüsselungskern. Jede Person kann es lesen, prüfen und bauen.

Die gesamte Kryptografie steckt in einer Rust-Bibliothek, die jede App nutzt. Browser-Erweiterung, Desktop-App und Handy-Apps schützen Ihre Daten deshalb auf genau dieselbe Weise. Quellcode auf GitHub.

• Gehosteter Dienst: läuft in Rechenzentren in Deutschland.
• Selbst gehostet: auf Ihrem eigenen Server, in Ihrem eigenen Netz und nach Ihren eigenen Regeln. Kostenlos, mit allen Funktionen. Siehe die Anleitung zum Selbst-Hosten.
• In beiden Fällen speichert der Server nur verschlüsselte Daten.

Bitte eröffnen Sie für Sicherheitsprobleme kein öffentliches Issue. Melden Sie sie vertraulich über GitHub Security Advisories und geben Sie an:

• eine Beschreibung des Problems und seiner Auswirkungen
• Schritte zum Nachstellen oder einen Proof of Concept
• die betroffene Version oder den Commit

Wir bestätigen jede Meldung innerhalb von drei Werktagen und halten Sie auf dem Laufenden, bis das Problem behoben ist. Gern nennen wir Sie im Advisory. Besonders willkommen sind Befunde, bei denen ein bösartiger oder kompromittierter Server Tresordaten lesen, ändern, vertauschen oder zurücksetzen kann.

Für Sicherheitsfachleute: die Kernpunkte des Designs. Die vollständige Spezifikation steht in docs/architecture/cryptography.md.

Schlüsselableitung

Der Account Unlock Key (AUK) und die OPAQUE-Passworteingabe werden aus beiden Geheimnissen abgeleitet. Der Geheimschlüssel hat 128 Zufallsbits.

k_password  = Argon2id(master_password, salt, params)k_secret    = HKDF-SHA256(secret_key, salt = account_id)master      = k_password XOR k_secretAUK         = HKDF-SHA256(master, "passbox/v1/auk")auth_secret = HKDF-SHA256(master, "passbox/v1/opaque-password")

Clients verlangen für Argon2id mindestens 64 MiB Speicher und 3 Durchläufe und lehnen schwächere Parameter ab, egal was ein Server sendet. Neue Konten nutzen 128 MiB, 3 Durchläufe und Parallelität 4.

OPAQUE-Anmeldung

• OPAQUE (RFC 9807) mit ristretto255, 3DH und SHA-512, gebunden an passbox/v1/login.
• Ein gestohlener OPAQUE-Datensatz hilft ohne den Geheimschlüssel nicht beim Erraten von Passwörtern.
• Sitzungstokens sind zufällige 256-Bit-Werte; der Server speichert nur ihren SHA-256-Hash.
• Unbekannte E-Mail-Adressen erhalten eine gleichbleibende Scheinantwort, die Anmeldung verrät also nicht, welche Konten existieren.
• Online-Rateversuche sind begrenzt. Geräte, die sich schon angemeldet haben, legen ein Geräte-Token vor, damit Fehlversuche von anderswo den Inhaber nicht aussperren.

Schlüsselhierarchie

Alle symmetrischen Schlüssel sind 256-Bit-Schlüssel für XChaCha20-Poly1305, die der Client erzeugt. Jeder Chiffretext ist über zugehörige Daten (Associated Data) an seinen Kontext gebunden:

AUK ──wraps──▶ account key ──wraps──▶ vault key (personal) ──encrypts──▶ vault metadata, items                    ├──wraps──▶ account key pairs (X-Wing, Ed25519)                    └──wraps──▶ own copies of shared vault keys (per key epoch)account X-Wing key ──opens──▶ sealed vault, group and organization keys

Schlüsselpaare, Teilen und Schlüsselverzeichnis

• Jedes Konto hat ein X-Wing-Schlüsselpaar (X25519 + ML-KEM-768) zum Verschlüsseln und ein Ed25519-Schlüsselpaar zum Signieren, erzeugt im Kern und mit dem Kontoschlüssel verschlüsselt gespeichert.
• Schlüssel werden mit X-Wing + HKDF-SHA256 + XChaCha20-Poly1305 versiegelt, gebunden an Zweck, Kontext und Empfängerschlüssel.
• Öffentliche Bündel sind kanonisch kodiert, selbst signiert und werden an ein hash-verkettetes, vom Server signiertes Schlüsselprotokoll angehängt.
• Tresorfreigaben signiert die gewährende Person; Einträge in geteilten Tresoren nutzen zugehörige Daten der Version 2 mit der Schlüsselepoche.

Verschlüsselungsformat

Jede symmetrische Verschlüsselung nutzt XChaCha20-Poly1305 mit einer zufälligen 192-Bit-Nonce. Die Header-Bytes werden zusammen mit den zugehörigen Daten authentifiziert. Unbekannte Versionen oder Algorithmen werden abgelehnt, das verhindert Downgrades.

version (1) | algorithm (1) | nonce (24) | ciphertext + tag (16)

Wir nennen, was noch nicht gelöst ist, damit Sie das Design selbst beurteilen können.

• Ein Server kann Änderungen noch zurückhalten oder einen kompletten älteren Stand eines Eintrags erneut ausliefern. Eine signierte Revisionskette pro Tresor wird das schließen.
• Tresor-Metadaten sind noch nicht an eine Revision gebunden.
• Das Schlüsselverzeichnis ist eine Hash-Kette; effiziente Nachweise, Abgleich zwischen Clients und externe Zeugen kommen als Nächstes. Bis dahin vertrauen neue Kontakte dem ersten gesehenen Schlüssel, sofern Sie keine Sicherheitscodes vergleichen.
• Die Wartezeit beim Notfallzugang erzwingt der Server.
• Server-Geheimnisse (OPAQUE-Serverschlüssel, Prelogin-Schlüssel, Zwei-Faktor-Schlüssel, Signaturschlüssel des Schlüsselprotokolls) liegen unverschlüsselt in der Datenbank. Sie schützen nicht die Vertraulichkeit der Tresore.

Das Whitepaper ist die Dokumentation im Repository (auf Englisch). Sie wird zusammen mit dem Code aktualisiert.

• Kryptografie
• Schlüsselpaare und Teilen
• Wiederherstellung und Notfallzugang
• Sicherheitsrichtlinie