Stockage de données sensibles S’abonner
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éslogin
dans l’application Accès au trousseau).
- Il crée l’entrée
-
Windows :
- Une clé de chiffrement similaire est enregistrée dans
os_crypt.encrypted_key
(dans le fichierLocal 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()
).
- Une clé de chiffrement similaire est enregistrée dans
-
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.).
- 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,
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 sesClé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 queCryptUnprotectData()
échoue suros_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.
- Idem pour macOS ci-dessus (par exemple via
-
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).
- 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
-
macOS :
Causes moins courantes/plus obscures de perte de données
-
macOS :
- Le champ
Dernière modification
de l’entrée de la trousseauBrave 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.
- Le champ
-
Windows :
-
CryptUnprotectData()
renvoieFALSE
, échouant avec une erreur inattendue/non documentéeGetLastError()
, 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 dansbrave://settings/braveSync/setup
(sousParamè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.