Le navigateur Brave est basé sur le projet Chromium et il y a certains comportements spécifiques au navigateur que nous héritons en utilisant ce code dans Brave. Par exemple, Chromium stocke vos données sensibles (mots de passe, cookies/sessions web, etc.) localement de manière chiffrée.

Comment ça fonctionne

Dans le code, le navigateur utilise le composant OSCrypt pour accomplir cette tâche.

Pendant le processus de chiffrement, OSCrypt lie vos données à votre utilisateur du système d’exploitation pour garantir qu’elles ne soient déchiffrables qu’avec votre mot de passe de l’OS.

OSCrypt a trois implémentations différentes sur ordinateur portable ; une pour chaque plateforme supportée :

• macOS :
  • Il crée l’entrée Brave Safe Storage dans votre trousseau de clés et y ajoute une séquence d’octets aléatoires encodés en base64, qui sera utilisée comme clé de chiffrement (voir votre trousseau de clés login dans l’application Accès au trousseau).
• Windows :
  • Une clé de chiffrement similaire est enregistrée dans os_crypt.encrypted_key (dans le fichier Local State, situé à %userprofile%/AppData/Local/BraveSoftware/Brave-Browser/User Data), protégée par l’API de Protection des Données de Windows (DPAPI/CryptProtectData()).
• Linux :
  • La clé de chiffrement sera ajoutée à un backend de stockage de mots de passe, qui par défaut est déduit de l’environnement de bureau que vous utilisez (par exemple, GNOME Libsecret pour GNOME, KWallet 5 pour KDE 5, etc.).

Les causes les plus courantes de perte de données

• Indépendantes de la plateforme :
  • Copier les profils de navigateur entre les machines (par exemple via une clé USB, une sauvegarde Time Machine, rsync, etc.) : puisque l’installation du navigateur sur la machine cible créera une clé de chiffrement différente de celle utilisée sur la machine source, il est impossible de déchiffrer les données originales sur la nouvelle machine ; la façon préférée de migrer les données du profil est via la synchronisation.
• Dépendantes de la plateforme :
  • macOS :
    • Si un administrateur réinitialise le mot de passe du compte macOS de l’utilisateur, toutes les tentatives futures pour déchiffrer les données précédemment chiffrées échoueront.
  • Windows :
    • Idem pour macOS ci-dessus (par exemple via net user <nom d’utilisateur> *), mais le déchiffrement échouera également à chaque fois que le mot de passe de l’utilisateur est réinitialisé sans fournir l’ancien mot de passe. Ainsi, même si les utilisateurs changent eux-mêmes leurs mots de passe via lusrmgr.msc dans la console de gestion Microsoft par exemple, cela se comportera exactement comme s’ils avaient été réinitialisés par un administrateur. La raison derrière cela est que, avant que le DPAPI ne re-chiffre ses Clés Maîtresses avec le nouveau mot de passe, il aurait d’abord besoin de l’ancien pour déchiffrer les clés. Dans des circonstances normales, si un utilisateur revient à son ancien mot de passe, il peut réutiliser ses données sans problème, mais si Chromium apprend le premier changement de mot de passe plus tôt (c’est-à-dire la première fois que CryptUnprotectData() échoue sur os_crypt.encrypted_key), il supprimera immédiatement l’ancienne clé de chiffrement et en générera une nouvelle. À ce moment-là, toutes les données qui ont été chiffrées avec l’ancienne clé de chiffrement sont irrécupérables ; peu importe si l’utilisateur restaure ensuite son ancien mot de passe de compte Windows.
  • Linux :
    • Changer d’environnements de bureau qui n’ont pas le même backend de stockage de mots de passe par défaut (par exemple, passer de GNOME à KDE) sans en informer Chromium (via --password-store=gnome-libsecret dans cet exemple).

Causes moins courantes/plus obscures de perte de données

• macOS :
  • Le champ Dernière modification de l’entrée de la trousseau Brave Safe Storage (qui devrait être aussi ancien que le navigateur) change (sans que le mot de passe de l’utilisateur n’ait été réinitialisé par un administrateur), ce qui suggère que soit :
    • Chromium a écrasé la clé de chiffrement à un moment donné par erreur, ou
    • L’API de la trousseau Apple a involontairement signalé que Brave Safe Storage n’était pas présent (ce qui finira par entraîner la substitution de la clé de chiffrement par Chromium), ou
    • une autre application (énumérée dans la liste de contrôle d’accès de Brave Safe Storage) a apporté des modifications à l’entrée.
  • Le compte Apple de l’utilisateur est dans un état défectueux sur leur machine.
• Windows :
  • CryptUnprotectData() renvoie FALSE, échouant avec une erreur inattendue/non documentée GetLastError(), ce qui entraîne le passage de Chromium à une autre clé de chiffrement dans État Local.

Conclusion

La liste ci-dessus est loin d’être complète. Puisque Brave et Chrome sont tous deux construits sur Chromium, tout ce qui précède s’applique à Brave tout autant qu’à Chrome.

En règle générale :

• Utilisez la synchronisation Brave ; puisque la clé de chiffrement de synchronisation est dérivée du code de synchronisation, la synchronisation ne sera pas affectée si la clé de chiffrement d’OSCrypt est perdue, écrasée, corrompue, inaccessible ou signalée comme absente, etc. Vous pouvez donc utiliser la synchronisation pour copier les types de données que vous avez activés dans brave://settings/bravesynchronisation/setup (sous Paramètres de synchronisation) depuis un autre appareil.
• Soyez conscient que des éléments extérieurs au domaine de Chromium peuvent rendre les éléments à l’intérieur de Brave/Chrome inutilisables; c’est-à-dire qu’il est très facile de vous mettre dans une situation délicate en faisant des choses apparemment innocentes.

En plus de traquer les bugs spécifiques à la plateforme affectant OSCrypt, nous espérons que Chromium envisagera de donner aux utilisateurs un moyen de sauvegarder et de restaurer les clés de chiffrement.