Der Brave-Browser basiert auf dem Chromium-Projekt und es gibt bestimmte Verhaltensweisen des Browsers, die wir durch die Verwendung des Codes in Brave erben. Chromium speichert zum Beispiel deine sensiblen Daten (Passwörter, Cookies/Websitzungen usw.) lokal verschlüsselt.

Wie es funktioniert

Im Code verwendet der Browser die OSCrypt Komponente, um diese Aufgabe zu erfüllen.

Während des Verschlüsselungsprozesses bindet OSCrypt deine Daten an den Benutzer deines Betriebssystems, um sicherzustellen, dass sie nur mit deinem Betriebssystempasswort entschlüsselt werden können.

OSCrypt hat drei verschiedene Implementierungen auf dem Desktop - eine für jede unterstützte Plattform:

• macOS:
  • Es erstellt den Eintrag für Brave Safe Storage in deinem Schlüsselbund und fügt ihm eine base64-kodierte zufällige Bytefolge hinzu, die als Verschlüsselungsschlüssel verwendet wird (siehe deinen Login-Schlüsselbund im Abschnitt Schlüsselbund-Zugang App).
• Fenster:
  • Ein ähnlicher Verschlüsselungsschlüssel wird in os_crypt.encrypted_key (in der Datei Local State, die sich unter %userprofile%/AppData/Local/BraveSoftware/Brave Browser/User Data befindet) gespeichert, der mit der Windows Data Protection API(DPAPI/CryptProtectData()).
• Linux:
  • Der Verschlüsselungsschlüssel wird zu einem Passwortspeicher hinzugefügt, der standardmäßig aus der von dir verwendeten Desktop-Umgebung abgeleitet wird (z.B. GNOME Libsecret für GNOME, KWallet 5 für KDE 5, etc.).

Die häufigsten Ursachen für Datenverlust

• Plattform-unabhängig:
  • Kopieren von Browserprofilen zwischen Rechnern (z. B. über einen USB-Stick), Time Machine Backup, rsync usw.): Da die Browser-Installation auf dem Zielcomputer einen anderen Verschlüsselungsschlüssel als der auf dem Quellcomputer verwendet wird, ist es unmöglich, die ursprünglichen Daten auf dem neuen Computer zu entschlüsseln - die bevorzugte Methode zur Migration von Profildaten ist die Synchronisierung.
• Plattformabhängig:
  • macOS:
    • Wenn ein Administrator das Kennwort des macOS-Kontos eines Benutzers zurücksetzt, schlagen alle nachfolgenden Versuche, zuvor verschlüsselte Daten zu entschlüsseln, fehl.
  • Fenster:
    • Wie bei macOS oben (z. B. über net user <username> *), aber die Entschlüsselung schlägt auch fehl, wenn das Passwort eines Benutzers zurückgesetzt wird, ohne das alte Passwort anzugeben. Selbst wenn Benutzer/innen ihre eigenen Passwörter z. B. über lusrmgr.msc in der Microsoft Management Console ändern, verhält sich das so, als ob sie von einem Administrator zurückgesetzt worden wären. Der Grund dafür ist, dass die DPAPI, bevor sie ihre Master Keys mit dem neuen Passwort verschlüsselt, zunächst das alte Passwort benötigt, um die Schlüssel zu entschlüsseln. Unter normalen Umständen, wenn ein Benutzer sein altes Passwort wieder ändert, ist er wieder im Geschäft, aber wenn Chromium früher von der ersten Passwortänderung erfährt (d.h. beim ersten Mal CryptUnprotectData() bei os_crypt.encrypted_key fehlschlägt), löscht es sofort den alten Schlüssel und erzeugt einen neuen. Zu diesem Zeitpunkt sind alle Daten, die mit dem alten Verschlüsselungscode verschlüsselt wurden, nicht mehr wiederherstellbar - egal, ob der/die Nutzer/in danach sein/ihr früheres Windows-Kontopasswort wiederherstellt.
  • Linux:
    • Wechsel zwischen Desktop-Umgebungen, die nicht standardmäßig das gleiche Passwortspeicher-Backend verwenden (z. B. Wechsel von GNOME zu KDE), ohne dass Chromium davon erfährt (in diesem Beispiel über --password-store=gnome-libsecret ).

Weniger häufige/unklarere Ursachen für Datenverluste

• macOS:
  • Das Feld Änderungsdatum des Schlüsselbundeintrags von Brave Safe Storage(das so alt sein sollte wie der Browser) ändert sich (ohne dass das Passwort des Benutzers von einem Administrator zurückgesetzt wurde), was darauf schließen lässt, dass entweder:
    • Chromium hat den Verschlüsselungsschlüssel irgendwann versehentlich überschrieben, oder
    • Apples Schlüsselbund-API hat versehentlich gemeldet, dass Brave Safe Storage nicht vorhanden ist (was dazu führt, dass Chromium den Verschlüsselungsschlüssel überschreibt), oder
    • eine andere App (die in der Zugriffskontrollliste von Brave Safe Storage aufgeführt ist) Änderungen an dem Eintrag vorgenommen hat.
  • Das Apple-Konto des Nutzers befindet sich in einem fehlerhaften Zustand auf seinem Rechner.
• Fenster:
  • CryptUnprotectData() gibt FALSE zurück und scheitert mit einem unerwarteten/undokumentierten GetLastError()zurück, was dazu führt, dass Chromium im Local State zu einem anderen Verschlüsselungsschlüssel wechselt.

Fazit

Die obige Liste ist bei weitem nicht vollständig. Da sowohl Brave als auch Chrome auf Chromium basieren, gelten alle oben genannten Punkte für Brave genauso wie für Chrome.

Als allgemeine Faustregel gilt:

• Verwende Brave Sync - da der Verschlüsselungsschlüssel von Sync vom Sync-Code abgeleitet wird, ist Sync nicht betroffen, wenn der OSCrypt-Verschlüsselungsschlüssel verloren/überschrieben/beschädigt/unzugänglich/nicht vorhanden ist usw. Daher kannst du Sync verwenden, um die Datentypen, die du in brave://settings/braveSync/setup (unter Sync-Einstellungen) aktiviert hast, von einem anderen Gerät zurück zu kopieren.
• Hüte dich vor der Tatsache, dass Dinge, die außerhalb von Chromium liegen, Dinge innerhalb von Brave/Chrome unbrauchbar machen können, d.h. es ist zu einfach, sich selbst in den Fuß zu schießen, indem man scheinbar unschuldige Dinge tut.

Wir hoffen, dass Chromium nicht nur die plattformspezifischen Fehler aufspürt, die OSCrypt betreffen, sondern den Nutzern auch eine Möglichkeit bietet, die Verschlüsselungsschlüssel zu sichern und wiederherzustellen.