Браузер Brave основан на проекте Chromium, и при использовании этого кода в Brave мы наследуем определенные поведения браузера. Например, Chromium хранит ваши конфиденциальные данные (пароли, cookies/веб-сессии и т.д.) локально в зашифрованном виде.

Как это работает

В коде браузер использует компонент OSCrypt для выполнения этой задачи.

Во время процесса шифрования OSCrypt привязывает ваши данные к пользователю операционной системы, чтобы они могли быть расшифрованы только с помощью пароля ОС.

OSCrypt имеет три различных реализации на настольных компьютерах — по одной для каждой поддерживаемой платформы:

• macOS:
  • Он создает запись Brave Safe Storage в вашей связке ключей и добавляет к ней последовательность случайных байтов, закодированных в base64, которую будет использовать в качестве ключа шифрования (смотрите свою связку ключей login в приложении Keychain Access).
• Windows:
  • Подобный ключ шифрования сохраняется в os_crypt.encrypted_key (в файле Local State, расположенном по пути %userprofile%/AppData/Local/BraveSoftware/Brave-Browser/User Data), который зашифрован с помощью Data Protection API Windows (DPAPI/CryptProtectData()).
• Linux:
  • Ключ шифрования будет добавлен в хранилище паролей, которое по умолчанию определяется средой рабочего стола, которую вы используете (например, GNOME Libsecret для GNOME, KWallet 5 для KDE 5 и т.д.).

Наиболее частые причины потери данных

• Независимые от платформы:
  • Копирование профилей браузера между устройствами (например, через USB-накопитель, резервную копию Time Machine, rsync и т.д.): поскольку установка браузера на целевом устройстве создаст другой ключ шифрования, чем на исходном устройстве, невозможно расшифровать любые исходные данные на новом устройстве — предпочтительный способ переноса данных профиля — через Sync.
• Зависимые от платформы:
  • macOS:
    • Если администратор сбрасывает пароль учетной записи пользователя macOS, любые последующие попытки расшифровать ранее зашифрованные данные потерпят неудачу.
  • Windows:
    • Как в случае с macOS выше (например, через net user <username> *), но дешифрование также потерпит неудачу, когда пароль пользователя сбрасывается без предоставления старого пароля. Таким образом, даже если пользователи изменят свои пароли через lusrmgr.msc в Microsoft Management Console, это будет вести себя так, как будто они были сброшены администратором. Причина этого в том, что перед тем как DPAPI повторно зашифрует свои Master Keys новым паролем, ему сначала потребуется старый для расшифровки ключей. При нормальных обстоятельствах, если пользователь вернется к своему старому паролю, он вернется к работе, но если Chromium узнает о первом изменении пароля раньше (т.е. первый раз, когда CryptUnprotectData() не удается на os_crypt.encrypted_key), он немедленно удалит старый ключ шифрования и создаст новый. В этот момент любые данные, зашифрованные старым ключом шифрования, не подлежат восстановлению — независимо от того, восстанавливает ли пользователь свой предыдущий пароль учетной записи Windows впоследствии.
  • Linux:
    • Переключение между средами рабочего стола, которые по умолчанию не используют одну и ту же базу хранения паролей (например, переход с GNOME на KDE), без уведомления об этом Chromium (через --password-store=gnome-libsecret в этом примере).

Менее распространенные и более редкие причины потери данных

• macOS:
  • Поле Date Modified в записи цепочки ключей Brave Safe Storage (которое должно быть таким же старым, как браузер) изменяется (без сброса пароля пользователя администратором), что указывает на одно из следующих:
    • Chromium по ошибке перезаписал ключ шифрования в какой-то момент, или
    • API Apple по использованию цепочки ключей случайно сообщило, что Brave Safe Storage отсутствует (что в конечном итоге приведет к перезаписи ключа шифрования Chromium), или
    • другое приложение (указанное в списке управления доступом Brave Safe Storage) внесло изменения в запись.
  • Учетная запись Apple пользователя находится в неисправном состоянии на его машине.
• Windows:
  • CryptUnprotectData() возвращает FALSE, завершаясь неожиданной/недокументированной ошибкой GetLastError(), в результате чего Chromium переключается на другой ключ шифрования в Local State.

Заключение

Приведенный выше список ни в коем случае не является полным. Поскольку и Brave, и Chrome построены на Chromium, все вышеперечисленное применимо к Brave так же, как и к Chrome.

В качестве основных правил:

• Используйте Brave Sync используется ключ шифрования Sync, Sync Code, Sync не будет затронут если ключ шифрования OSCrypt утерян/перезаписан/поврежден/недоступен/сообщено, что он отсутствует, и т.д. поэтому вы можете использовать Sync для копирования тех типов данных, которые включены вами в brave://settings/braveSync/setup (в разделе Sync Settings) с другого устройства.
• Имейте в виду, что вещи, находящиеся вне области Chromium, могут сделать вещи внутри Brave/Chrome непригодными для использования. то есть, слишком легко испортить все, делая, казалось бы, безобидные вещи.

В дополнение к отслеживанию платформо-зависимых багов, влияющих на OSCrypt, мы надеемся, что Chromium рассмотрит возможность предоставления пользователям способа резервного копирования и восстановления ключей шифрования.