Sicherheit / Bedrohungsmodell
Ein Passwort-Manager, der behauptet, jeden Angriff zu stoppen, lügt Sie an. Diese Seite ist die öffentliche Zusammenfassung des Desktop-Bedrohungsmodells: die Angriffe, gegen die das Design sich verteidigt, diejenigen, gegen die es sich nur teilweise verteidigt, und diejenigen, gegen die es sich bewusst nicht verteidigt.
Das Modell deckt die Desktop-Anwendung als lokalen Tresor ab: Einrichtung des Masterpassworts, Entsperren, Sperren und Zurücksetzen; Persistenz im wa-sqlite-Backend und in älteren OPFS/JSON-Speichern, die auf eine abgesicherte Migration warten; verschlüsselte Sicherungen; Verschlüsselung von Anhängen; biometrisches Komfort-Entsperren; sowie Verhalten von Zwischenablage und offengelegten Feldern, während die App entsperrt ist.
Zu den geschützten Werten gehören das Masterpasswort, jedes Geheimnis der Tresoreinträge — Passwörter, Karten, API-Schlüssel, Passkey-Einträge, Identitäten, Notizen, TOTP-Seeds und Besitzverhältnisse offenlegende Metadaten —, Anhangsinhalte, verschlüsselte Sicherungsdateien und die biometrisch umhüllte Entsperr-Nutzlast.
Vertrauensgrenzen sind ausdrücklich definiert. Browserähnliche Storage-APIs gelten als Persistenz, nicht als Geheimspeicher. OPFS- und localStorage-Rückfallebenen gelten im gespeicherten Zustand als für Angreifer lesbar, sofern die App sie nicht verschlüsselt hat. Importierte CSV/JSON-Daten und von Ihnen ausgewählte Sicherungsdateien sind nicht vertrauenswürdige Eingaben, bis sie geparst und validiert wurden.
Eine kopierte verschlüsselte .ks-Sicherung ohne ihr Passwort. Lesen der gespeicherten Datenbank-Nutzlast im gesperrten Zustand. Manipulation von AES-GCM-Sicherungs- oder Anhangsnutzlasten. Fehlerhafte Importdateien. Kurzer physischer Zugriff, nachdem die App gesperrt wurde.
Ein Prozess mit Ihrem Betriebssystembenutzerkonto, der Anwendungsspeicher liest: Eintragsnutzlasten und Anhänge sind verschlüsselt, aber Profileinstellungen und einige Metadaten können lesbar bleiben. Eine gültige entsperrte Sitzung: Auto-Sperre und das Zurücksetzen offengelegter Felder verringern die Exposition, doch ein entsperrter Zustand gilt weiterhin als vertrauenswürdig.
Schadsoftware, die als Ihr Betriebssystembenutzer läuft, während der Tresor entsperrt ist. Ein kompromittiertes Betriebssystem, WebView oder Laufzeitsystem. Speicherinspektion, Keylogging, privilegierte Bildschirmaufnahmen und Zugriff auf die Zwischenablage durch feindliche lokale Software. Verlust des Masterpassworts ohne gültige Sicherung. Cloud-Synchronisation, Konfliktlösung über mehrere Geräte und Unternehmensrichtlinien sind keine ausgelieferten Funktionen und liegen außerhalb des Modells.
Die nativeMessaging-Brücke bindet sich nur an lokales Loopback-TCP (127.0.0.1, Portbereich 49155–49165), authentifiziert sich mit einem 256-Bit-Kopplungstoken aus einem CSPRNG, das in einer betriebssystemgeschützten Datei liegt, und verschlüsselt danach jeden Frame mit XChaCha20-Poly1305 unter einem mit HKDF-SHA256 abgeleiteten Sitzungsschlüssel. Zwischengespeicherte Anmeldedaten tragen eine Lease von fünf Minuten und werden bei Ablauf nullgesetzt; breite Abfragen geben bereinigte Metadaten zurück, damit eine einzelne Nachricht den Tresor nicht im Ganzen exfiltrieren kann. Schadsoftware mit Ihren Betriebssystemrechten kann die Tokendatei dennoch lesen — dieses Restrisiko ist dokumentiert, nicht geleugnet.
Der Tresorsitzungszustand ist ein nullgesetztes Uint8Array im Prozessspeicher. Sicherer als sessionStorage, aber keine geheime Enklave des Betriebssystems — Eingaben bei Einrichtung und Entsperren überschreiten weiterhin die Grenze zur Benutzeroberfläche.
Windows-Builds fordern WDA_EXCLUDEFROMCAPTURE an, Android setzt FLAG_SECURE. Das verringert gewöhnliche Screenshots und Taskwechsel-Vorschauen; privilegierte Aufnahmesoftware hält es nicht auf.
Jeder Frame der Erweiterungsbrücke trägt eine frische 24-Byte-Nonce; nicht authentifizierte Frames oder solche mit abweichender Version beenden die Verbindung sofort.
Nein. Die Tresordatei und Sicherungen sind Chiffretext auf der Festplatte, und das Masterpasswort berührt nie den sessionStorage. Schadsoftware, die in Ihrer eigenen Sitzung läuft, während der Tresor entsperrt ist, ist eine andere Frage — sie liegt ausdrücklich außerhalb des Geltungsbereichs.
Weil keine lokale Anwendung sie gewinnen kann. Schutz vor Keyloggern oder einem kompromittierten Betriebssystem zu behaupten wäre falscher Trost. Die Grenze schriftlich festzuhalten ermöglicht Ihnen zu entscheiden, wofür KalderaShield verantwortlich sein kann und wofür nicht.
Ja. Es wird bei jeder Veröffentlichung geprüft, und ein Restrisikoregister erfasst jede bekannte Lücke, ihren Status und die geplante Gegenmaßnahme — einschließlich eines akzeptierten, dokumentierten Kompromisses im Autofill-Pfad der Erweiterung.
Kaldera