Przeglądarka Brave oparta jest na projekcie Chromium i posiada pewne cechy przeglądarki, które dziedziczymy przez używanie tego kodu w Brave. Przykładowo, Chromium przechowuje twoje wrażliwe dane (hasła, ciasteczka/sesje sieciowe, itp.) lokalnie zaszyfrowane.

Jak to działa

W kodzie przeglądarka używa komponentu OSCrypt do wykonania tego zadania.

Podczas procesu szyfrowania, OSCrypt powiązuje twoje dane z użytkownikiem systemu operacyjnego, aby upewnić się, że są one możliwe do odszyfrowania tylko z hasłem OS.

OSCrypt ma trzy różne implementacje na komputerach stacjonarnych — jedną dla każdej obsługiwanej platformy:

• macOS:
  • Tworzy wpis Brave Safe Storage w twoim pęku kluczy i dodaje do niego sekwencję losowych bajtów zakodowaną base64, której użyje jako klucza szyfrowania (patrz sekcja login w aplikacji Keychain Access).
• Windows:
  • Podobny klucz szyfrowania jest zapisywany w os_crypt.encrypted_key (w pliku Local State, znajdującym się w %userprofile%/AppData/Local/BraveSoftware/Brave-Browser/User Data), który jest zaszyfrowany za pomocą Data Protection API (DPAPI/CryptProtectData()).
• Linux:
  • Klucz szyfrowania zostanie dodany do magazynu haseł, który jest domyślnie ustalany na podstawie używanego środowiska graficznego (np. GNOME Libsecret dla GNOME, KWallet 5 dla KDE 5, itp.).

Najczęstsze przyczyny utraty danych

• Niezależne od platformy:
  • Kopiowanie profili przeglądarki między maszynami (np. przez pamięć USB, kopię zapasową Time Machine, rsync, itp.): ponieważ instalacja przeglądarki na docelowej maszynie stworzy inny klucz szyfrowania niż ten używany na maszynie źródłowej, niemożliwe jest odszyfrowanie żadnych oryginalnych danych na nowej maszynie — preferowany sposób przenoszenia danych profili to poprzez Sync.
• Zależne od platformy:
  • macOS:
    • Jeżeli administrator zresetuje hasło konta użytkownika w macOS, wszelkie próby odszyfrowania wcześniej zaszyfrowanych danych nie powiodą się.
  • Windows:
    • Podobnie jak w przypadku macOS powyżej (np. za pomocą net user <username> *), ale odszyfrowanie również nie powiedzie się, gdy hasło użytkownika zostanie zresetowane bez podania starego hasła. Tak więc nawet jeśli użytkownicy zmienią swoje hasła za pomocą lusrmgr.msc w Microsoft Management Console, będzie to działać tak, jak gdyby były resetowane przez administratora. Powodem tego jest, że zanim DPAPI ponownie zaszyfruje Główne Klucze (Master Keys) nowym hasłem, najpierw potrzebuje starego hasła do ich odszyfrowania. W normalnych okolicznościach, jeśli użytkownik zmieni z powrotem na swoje stare hasło, wszystko wraca do normy, ale jeśli Chromium dowie się o pierwszej zmianie hasła wcześniej (tzn. przy pierwszej nieudanej próbie CryptUnprotectData() na os_crypt.encrypted_key), natychmiast usunie stary klucz szyfrowania i wygeneruje nowy. W tym momencie wszelkie dane zaszyfrowane za pomocą starego klucza szyfrowania są nieodzyskiwalne — niezależnie od tego, czy użytkownik przywróci swoje poprzednie hasło do konta w Windows.
  • Linux:
    • Przełączanie się między środowiskami graficznymi, które nie domyślnie używają tego samego zaplecza magazynowania haseł (np. przełączanie z GNOME na KDE) bez informowania Chromium o tym (przez --password-store=gnome-libsecret w tym przykładzie).

Mniej popularne / bardziej niejasne przyczyny utraty danych

• macOS:
  • Pole Date Modified wpisu Brave Safe Storage w pęku kluczy (które powinno być tak stare jak przeglądarka) zmienia się (bez resetu hasła przez administratora), co sugeruje, że albo:
    • Chromium przypadkowo nadpisał klucz szyfrowania, lub
    • API pęku kluczy Apple błędnie zgłosił, że Brave Safe Storage nie jest obecne (co ostatecznie spowoduje, że Chromium nadpisze klucz szyfrowania), lub
    • inna aplikacja (wymieniona na liście kontroli dostępu Brave Safe Storage) wprowadziła zmiany do wpisu.
  • Konto Apple użytkownika jest w błędnym stanie na jego komputerze.
• Windows:
  • CryptUnprotectData() zwraca FALSE, kończąc się niespodziewanym/nieudokumentowanym GetLastError(), co skutkuje przełączeniem Chromium na inny klucz szyfrowania w pliku Local State.

Wniosek

Powyższa lista nie jest w żaden sposób kompletna. Ponieważ zarówno Brave, jak i Chrome są oparte na Chromium, wszystko, co powyżej dotyczy Brave tak samo, jak dotyczy Chrome.

Ogólne zasady:

• Używaj Brave Sync — ponieważ klucz szyfrowania Sync jest pochodny od Sync Code, Sync nie będzie dotknięte, jeśli klucz szyfrowania OSCrypt zostanie zgubiony/nadpisany/uszkodzony/nieosiągalny/zgłoszony jako nieobecny, itd., dlatego można użyć Sync, aby skopiować typy danych, które włączyłeś w brave://settings/braveSync/setup (w Sync Settings) z powrotem z innego urządzenia.
• Miej świadomość, że rzeczy poza sferą Chromium mogą powodować, że rzeczy wewnątrz Brave/Chrome staną się bezużyteczne, tzn. zbyt łatwo jest "strzelić sobie w stopę" robiąc pozornie niewinne rzeczy.

Oprócz wyśledzenia specyficznych dla platformy błędów wpływających na OSCrypt, mamy nadzieję, że Chromium rozważy zapewnienie użytkownikom sposobu na tworzenie kopii zapasowych i przywracanie kluczy szyfrowania.