O navegador Brave é baseado no projeto Chromium e há determinados comportamentos sobre o navegador que herdamos ao usar esse código no Brave. Por exemplo, o Chromium armazena seus dados confidenciais (senhas, cookies/sessões da Web, etc.) criptografados localmente.

Como funciona

No código, o navegador usa o OSCrypt para realizar essa tarefa.

Durante o processo de criptografia, o OSCrypt vincula seus dados ao usuário do sistema operacional para garantir que eles só possam ser descriptografados com a senha do sistema operacional.

O OSCrypt tem três implementações diferentes no desktop, uma para cada plataforma suportada:

• macOS:
  • Ele cria a entrada Brave Safe Storage em seu chaveiro e adiciona uma sequência de bytes aleatórios codificados em base64 a ela, que será usada como a chave de criptografia (consulte seu chaveiro de login na seção Acesso ao chaveiro ).
• Windows:
  • Uma chave de criptografia semelhante é salva em os_crypt.encrypted_key (no arquivo Local State, localizado em %userprofile%/AppData/Local/BraveSoftware/Brave-Browser/User Data), que é criptografada com a API de proteção de dados do Windows(DPAPI/CryptProtectData()).
• Linux:
  • A chave de criptografia será adicionada a um backend de armazenamento de senhas, que, por padrão, é inferido do ambiente de desktop que você usa (por exemplo, GNOME Libsecret para GNOME, KWallet 5 para KDE 5 etc.).

As causas mais comuns de perda de dados

• Independente da plataforma:
  • Copiar perfis de navegador entre máquinas (por exemplo, por meio de uma unidade USB), Time Machine backup, rsync, etc.): como a instalação do navegador na máquina de destino criará uma chave de criptografia diferente da que está sendo usada na máquina de origem, é impossível descriptografar qualquer dado original na nova máquina - a maneira preferida de migrar dados de perfil é por meio do Sync.
• Depende da plataforma:
  • macOS:
    • Se um administrador redefinir a senha da conta do macOS do usuário, todas as tentativas subsequentes de descriptografar dados criptografados anteriormente falharão.
  • Windows:
    • O mesmo que para o macOS acima (por exemplo, via net user <username> *), mas a descriptografia também falhará sempre que a senha de um usuário for redefinida sem que você forneça a senha antiga. Portanto, mesmo que os usuários alterem suas próprias senhas por meio do lusrmgr.msc no Console de Gerenciamento da Microsoft, por exemplo, ele se comportará como se elas tivessem sido redefinidas por um administrador. O motivo disso é que, antes de a DPAPI criptografar novamente suas chaves mestras com a nova senha, ela precisaria primeiro da senha antiga para descriptografar as chaves. Em circunstâncias normais, se um usuário mudar de volta para a senha antiga, ele estará de volta ao trabalho, mas se o Chromium souber da primeira mudança de senha mais cedo (ou seja, na primeira vez que você fizer CryptUnprotectData() falhar em os_crypt.encrypted_key), ele excluirá imediatamente a chave de criptografia antiga e gerará uma nova. Nesse ponto, todos os dados que foram criptografados com a chave de criptografia antiga são irrecuperáveis, independentemente de o usuário restaurar a senha anterior da conta do Windows posteriormente.
  • Linux:
    • Mudar entre ambientes de desktop que não usam o mesmo backend de armazenamento de senhas como padrão (por exemplo, mudar do GNOME para o KDE) sem que o Chromium saiba disso (via --password-store=gnome-libsecret neste exemplo).

Causas menos comuns/mais obscuras de perda de dados

• macOS:
  • O campo Data de modificação da entrada do chaveiro do Brave Safe Storage(que deve ser tão antiga quanto o navegador) é alterado (sem que a senha do usuário seja redefinida por um administrador), o que sugere que:
    • O Chromium substituiu a chave de criptografia em algum momento por engano, ou
    • A API do keychain da Apple informou inadvertidamente que o Brave Safe Storage não estava presente (o que fará com que o Chromium substitua a chave de criptografia), ou
    • outro aplicativo (listado na lista de controle de acesso do Brave Safe Storage) fez alterações na entrada.
  • A conta Apple do usuário está em um estado defeituoso no computador.
• Windows:
  • CryptUnprotectData() retorna FALSE, falhando com um erro inesperado/não documentado GetLastError()resultando na mudança do Chromium para outra chave de criptografia no Local State.

Conclusão

A lista acima não está completa, de forma alguma. Como o Brave e o Chrome foram desenvolvidos com base no Chromium, todos os itens acima se aplicam ao Brave, assim como ao Chrome.

Como regra geral:

• Use o Brave Sync - como a chave de criptografia do Sync é derivada do código de sincronização, o Sync não será afetado se a chave de criptografia do OSCrypt for perdida/sobrescrita/corrompida/não acessível/relatada como não presente, etc. Portanto, você pode usar o Sync para copiar os tipos de dados que ativou em brave://settings/braveSync/setup (em Sync Settings) de outro dispositivo.
• Cuidado com o fato de que as coisas fora do domínio do Chromium podem tornar as coisas dentro do Brave/Chrome inutilizáveis, ou seja, é muito fácil dar um tiro no pé fazendo coisas aparentemente inocentes.

Além de rastrear os bugs específicos da plataforma que afetam o OSCrypt, esperamos que o Chromium considere a possibilidade de oferecer aos usuários uma maneira de fazer backup e restaurar as chaves de criptografia.