The Brave browser is based on the Chromium project and there are certain behaviors about the browser that we inherit by using that code in Brave. For example, Chromium stores your sensitive data (passwords, cookies/web sessions, etc.) locally encrypted.

How it works

In the code, the browser uses the OSCrypt component to accomplish this task.

During the encryption process, OSCrypt ties your data to your operating system user to ensure that it's only decryptable with your OS password.

OSCrypt has three different implementations on desktop — one for each supported platform:

• macOS:
  • It creates the Brave Safe Storage entry in your keychain and adds a base64-encoded random byte sequence to it, which it will use as the encryption key (see your login keychain in the Keychain Access app).
• Windows:
  • A similar encryption key is saved to os_crypt.encrypted_key (in the Local State file, located in %userprofile%/AppData/Local/BraveSoftware/Brave-Browser/User Data), which is encrypted with Windows' Data Protection API (DPAPI/CryptProtectData()).
• Linux:
  • The encryption key will be added to a password store backend, which by default is inferred from the desktop environment you use (e.g. GNOME Libsecret for GNOME, KWallet 5 for KDE 5, etc.).

The most common causes for data loss

• Platform-independent:
  • Copying browser profiles between machines (e.g. via a USB stick, Time Machine backup, rsync, etc.): since the browser installation on the target machine will create a different encryption key than the one being used on the source machine, it's impossible to decrypt any of the original data on the new machine — the preferred way to migrate profile data is via Sync.
• Platform-dependent:
  • macOS:
    • If an administrator resets the user's macOS account password, any subsequent attempts to decrypt previously encrypted data will fail.
  • Windows:
    • Same as for macOS above (e.g. via net user <username> *), but the decryption will also fail whenever a user's password is reset without providing the old password. So even if users change their own passwords via lusrmgr.msc in the Microsoft Management Console for example, it will behave just as if they had been reset by an administrator. The reason behind this is that before the DPAPI re-encrypts its Master Keys with the new password, it would first need the old one to decrypt the keys. Under normal circumstances, if a user changes back to their old password, they're back in business, but if Chromium learns about the first password change sooner (i.e. the first time CryptUnprotectData() fails on os_crypt.encrypted_key), it will immediately delete the old encryption key and generate a new one. At that point, any data that was encrypted with the old encryption key is unrecoverable — no matter if the user restores their previous Windows account password afterwards.
  • Linux:
    • Changing between desktop environments that don't default to the same password store backend (e.g. switching from GNOME to KDE) without letting Chromium know about it (via --password-store=gnome-libsecret in this example).

Less common/more obscure causes for losing data

• macOS:
  • The Date Modified field of Brave Safe Storage's keychain entry (which should be as old as the browser) changes (without the user's password being reset by an admin), which suggests that either:
    • Chromium overwrote the encryption key at some point by mistake, or
    • Apple's keychain API inadvertently reported Brave Safe Storage not to be present (which will eventually result in Chromium overwriting the encryption key), or
    • another app (listed in Brave Safe Storage's access control list) made changes to the entry.
  • The user's Apple Account is in a faulty state on their machine.
• Windows:
  • CryptUnprotectData() returns FALSE, failing with an unexpected/undocumented GetLastError(), resulting in Chromium switching to another encryption key in Local State.

Conclusion

The above list is not complete by any means. Since both Brave and Chrome are built on Chromium, all of the above apply to Brave, just as much as they apply to Chrome.

As general rules of thumb:

• Use Brave Sync — since Sync's encryption key is derived from the Sync Code, Sync won't be affected if OSCrypt's encryption key is lost/overwritten/corrupted/not accessible/reported not to be present, etc., therefore you can use Sync to copy the data types that you enabled in brave://settings/braveSync/setup (under Sync Settings) back from another device.
• Beware of the fact that things outside Chromium's realm may render things inside Brave/Chrome unusable, i.e. it's too easy to shoot yourself in the foot by doing seemingly innocent things.

In addition to tracking down the platform-specific bugs affecting OSCrypt, we are hoping that Chromium will consider giving users a way to backup and restore the encryption keys.