Mots de passe et phrases secrètes
Le coffre est chiffré sur votre appareil avant d’être envoyé. Reste à savoir ce qui échappe au chiffrement, pourquoi le remplissage automatique détecte l’hameçonnage, et comment migrer sans laisser un fichier en clair.
Un gestionnaire chiffre votre coffre sur votre appareil, avec une clé dérivée du mot de passe principal que l’éditeur ne reçoit jamais. Il héberge donc un bloc illisible pour lui. Trois choses échappent pourtant à ce chiffrement : les métadonnées du compte, la robustesse de la fonction de dérivation choisie le jour de l’inscription, et tout ce qui se passe sur un appareil infecté. Son bénéfice le plus sous-estimé n’est pas la mémoire : c’est le remplissage automatique, qui refuse de se déclencher sur un faux domaine.
Le navigateur propose d’enregistrer un mot de passe. Vous acceptez. Quatre ans plus tard, la liste compte deux cents entrées, dont vous ignorez à peu près tout : lesquelles sont encore valides, lesquelles partagent le même secret, lesquelles correspondent à des services fermés depuis longtemps.
Cette liste, c’est déjà un gestionnaire de mots de passe. La question n’est donc pas d’en adopter un, mais de savoir lequel, et surtout de comprendre ce qu’il fait exactement du contenu. Car l’objection revient toujours : confier tous ses secrets à un seul service, n’est-ce pas concentrer le risque ?
Si, et c’est l’intérêt du procédé, à condition de savoir où le risque se concentre précisément. Il ne se concentre pas là où on l’imagine. Le serveur de l’éditeur n’est pas le maillon faible ; votre appareil et vos gestes de migration le sont beaucoup plus.
Le mécanisme tient en une phrase : tout se chiffre et se déchiffre sur votre appareil, jamais sur le serveur. Quand vous saisissez votre mot de passe principal, l’application le transforme localement en une clé de chiffrement, puis s’en sert pour déchiffrer un fichier qu’elle a téléchargé. Ce fichier, l’éditeur l’héberge, le duplique, le sauvegarde, mais ne peut pas le lire.
La transformation du mot de passe en clé porte un nom : la dérivation. Elle n’est pas un simple calcul d’empreinte. Elle est volontairement lente et coûteuse en mémoire, pour qu’un attaquant qui essaierait des millions de candidats se heurte à ce coût à chaque tentative. Les fonctions employées aujourd’hui sont PBKDF2, avec un très grand nombre d’itérations, et surtout Argon2id, conçue pour résister aux cartes graphiques en exigeant de la mémoire vive à chaque essai.
Le chiffrement du coffre lui-même se fait ensuite avec un algorithme symétrique standard, AES-256 ou une variante de ChaCha20. Ce n’est pas là que se joue la différence entre deux produits : ces algorithmes sont solides et identiques partout. La différence se joue sur la dérivation.
Un détail d’architecture explique pourquoi l’éditeur peut vous authentifier sans jamais connaître votre clé. À partir du mot de passe principal, le client effectue deux calculs distincts. Le premier produit la clé qui déchiffre le coffre, et ne quitte jamais l’appareil. Le second produit une valeur dérivée de la première, qui est envoyée au serveur comme preuve d’identité.
Le serveur compare cette preuve à celle qu’il a stockée. Il sait donc que c’est bien vous, sans détenir de quoi ouvrir quoi que ce soit. Si sa base fuite, l’attaquant récupère deux choses : les coffres chiffrés et ces preuves d’authentification. Dans les deux cas, il devra retrouver le mot de passe principal par force brute, en payant le coût de la dérivation à chaque essai.
Cette mécanique explique aussi pourquoi la longueur du mot de passe principal reste déterminante malgré le chiffrement : elle est la seule inconnue de toute la chaîne. C’est exactement le cas d’usage d’une phrase de passe tirée au sort, de préférence à sept mots, puisque le coffre volé s’attaque sans limite de tentatives.
Le bloc chiffré contient les identifiants et les mots de passe. Il ne contient pas tout le reste, et ce reste est instructif pour qui l’observe côté serveur.
Aucune de ces données ne permet d’ouvrir un compte. Toutes permettent de dresser un profil, de cibler un message d’hameçonnage crédible, ou de repérer un titulaire intéressant. C’est pour cela que la juridiction de l’hébergeur et sa politique de journalisation comptent, même dans un modèle où le contenu lui échappe. Les questions de localisation et de responsabilité sont les mêmes que pour n’importe quel service hébergé.
C’est le bénéfice le moins mis en avant, et probablement le plus important au quotidien. Un gestionnaire ne remplit pas un formulaire parce que la page ressemble à celle de votre banque. Il le remplit parce que le domaine de la page correspond exactement au domaine enregistré avec l’entrée.
Un œil humain se laisse prendre par un caractère accentué glissé dans un nom de domaine, par un sous-domaine trompeur, par un tiret ajouté ou par une extension voisine. Le gestionnaire, lui, ne regarde pas : il compare des chaînes de caractères. Il ne propose rien, et ce silence est une alerte. La lecture attentive d’une adresse et de ses composants reste utile, mais elle demande un effort que la machine fournit gratuitement.
Le contournement par copier-coller mérite une mise en garde supplémentaire. Le presse-papiers est lisible par d’autres applications, il conserve souvent un historique, et il se synchronise parfois entre l’ordinateur et le téléphone. Un mot de passe copié peut donc voyager bien au-delà du champ où vous comptiez le déposer.
| Gestionnaire du navigateur | Application dédiée | Coffre auto-hébergé | |
|---|---|---|---|
| Ce qui déverrouille | La session du système, souvent sans autre secret | Un mot de passe principal distinct | Un mot de passe principal distinct |
| Où vit la copie chiffrée | Chez l’éditeur du navigateur | Chez l’éditeur du gestionnaire | Sur votre machine ou votre serveur |
| Usage hors navigateur | Limité | Applications mobiles, bureau, terminal | Idem, selon le client utilisé |
| Partage organisé | Rudimentaire | Collections partagées avec droits | Selon la solution retenue |
| Ce qui casse | Un ordinateur laissé déverrouillé | L’oubli du mot de passe principal | Votre propre sauvegarde, s’il n’y en a pas |
Le tableau tranche moins qu’il n’y paraît. Le gestionnaire du navigateur n’est pas mauvais : il vérifie correctement les domaines et il supprime la réutilisation, ce qui règle déjà l’essentiel. Son défaut est le déverrouillage implicite par la session. L’auto-hébergement, à l’inverse, déplace la charge : vous gagnez la maîtrise du stockage, vous héritez des mises à jour et des sauvegardes.
Une huitième question est facultative mais éclairante : le gestionnaire sait-il signaler les entrées faibles, réutilisées ou compromises. Cette revue interne fait le même travail que notre outil de mesure de solidité, mais sur l’ensemble du coffre et en une seule passe.
Changer de gestionnaire suppose presque toujours un export. Or un export est un fichier texte contenant tous vos mots de passe en clair, sans aucune protection. C’est, très concrètement, le moment le plus dangereux de la vie d’un coffre.
Quand les deux produits proposent un connecteur d’import direct, préférez-le : le transfert se fait alors sans fichier intermédiaire, donc sans clair sur le disque.
Un mot de passe envoyé par message n’est plus un secret : il existe désormais dans deux messageries, deux sauvegardes et deux téléphones, pour une durée que personne ne contrôle. Les collections partagées d’un gestionnaire résolvent le problème autrement : le secret est chiffré pour chaque destinataire, la liste des accès est visible, et le retrait d’une personne est immédiat.
Trois règles tiennent le reste. Quand le service permet des comptes nommés, préférez toujours plusieurs comptes individuels à un compte unique partagé : la trace de qui a fait quoi disparaît avec le compte partagé. Quand un partage prend fin, changez le secret, car celui qui l’a vu le connaît encore. Quand un envoi ponctuel est inévitable, utilisez la fonction de lien à usage unique et à expiration courte, plutôt que le corps d’un courriel. Dans une structure professionnelle, ces règles font partie du socle de sécurité minimal, au même rang que la sauvegarde.
Un coffre bien fait est inaccessible à tous, y compris à vos proches, y compris après votre mort. C’est une conséquence directe du modèle, et elle prend au dépourvu les familles qui découvrent le problème au pire moment.
Deux dispositifs se complètent. Le premier est technique : la plupart des gestionnaires proposent un accès d’urgence, où une personne désignée peut demander l’ouverture et l’obtient après un délai de plusieurs jours pendant lequel vous pouvez refuser. Le second est juridique : la loi Informatique et Libertés permet à chacun de laisser des directives, générales ou particulières, sur la conservation, l’effacement et la communication de ses données après le décès. Les directives générales s’enregistrent auprès d’un tiers de confiance numérique certifié par la CNIL ; les directives particulières se déposent auprès du service concerné.
La même préparation sert de son vivant, pour accompagner un proche qui perd son autonomie numérique sans se substituer à lui : un accès d’urgence documenté vaut mieux qu’un carnet transmis dans l’urgence.
Le chiffrement protège le coffre au repos et en transit. Il ne protège pas l’instant où le coffre est ouvert sur une machine compromise. Les logiciels voleurs d’informations, très répandus, cherchent précisément les fichiers de coffre, les extensions de navigateur et les jetons de session déjà validés. Sur une machine infectée, changer ses mots de passe ne sert à rien tant que l’infection n’est pas traitée : les signes d’infection et la méthode de nettoyage passent donc avant toute reprise en main.
Deux autres limites méritent d’être dites. Une extension de navigateur malveillante voit les pages que vous consultez et les champs que vous remplissez : n’en installez que le strict nécessaire, et relisez la liste une fois par an. Enfin, la synchronisation entre vos appareils n’est pas une sauvegarde : elle propage aussi bien une suppression qu’un ajout, et le rappel vaut pour tous les fichiers. Exportez une copie chiffrée de votre coffre, une ou deux fois par an, sur un support déconnecté.
Si malgré tout un accès vous échappe, l’ordre des opérations compte davantage que la vitesse : la marche à suivre après un vol de mot de passe commence par la messagerie, pas par le compte visé. Et si vous vous demandez pourquoi un secret long et unique reste indispensable même avec un coffre, la réponse tient dans le calcul de l’entropie et des trois attaques.
Devant un gestionnaire, ne demandez pas s’il est sûr, la question est mal posée. Demandez trois choses : qui détient la clé, ce qui reste lisible quand le contenu ne l’est pas, et ce qui se passe le jour où vous n’êtes plus là pour ouvrir. Un produit qui répond clairement aux trois vaut mieux qu’un produit qui promet une sécurité absolue.
Dans une architecture correcte, l’éditeur ne peut rien faire : il ne détient pas la clé et ne peut pas la reconstituer. Le coffre est perdu. C’est le prix du modèle, et c’est aussi la preuve qu’il fonctionne. Les seules portes de sortie sont celles que vous avez préparées à l’avance : une clé de récupération imprimée, un accès d’urgence confié à un proche, ou une sauvegarde chiffrée hors ligne. Un service capable de vous rendre votre coffre après un simple courriel de récupération détient forcément de quoi le déchiffrer.
Oui, et sans hésiter. Elle ne protège pas le chiffrement, qui dépend du seul mot de passe principal, mais elle empêche un tiers de télécharger la copie chiffrée de votre coffre depuis le serveur. Sans cette copie, il n’a rien à attaquer hors ligne. Préférez une application d’authentification ou une clé physique au code par SMS, et conservez les codes de secours ailleurs que dans le coffre qu’ils servent à ouvrir.
Techniquement oui, la plupart des gestionnaires savent générer les codes à usage unique. Mais cela ramène les deux facteurs au même endroit : celui qui ouvre le coffre obtient le mot de passe et le code. Pour les comptes secondaires, la commodité l’emporte souvent. Pour la messagerie principale, la banque et le coffre lui-même, séparez : les codes sur le téléphone dans une autre application, ou sur une clé physique.
Plus sûr techniquement, non : le chiffrement se fait chez vous, l’hébergeur ne voit qu’un bloc illisible où qu’il soit. Juridiquement, l’hébergement dans l’Union européenne simplifie le régime applicable aux métadonnées et aux journaux de connexion, qui, eux, ne sont pas chiffrés. Pour un usage professionnel avec des données sensibles, la qualification SecNumCloud délivrée par l’ANSSI constitue un repère sérieux, au même titre que l’existence d’un audit public du code.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Mots de passe, arnaques, fuites de données et réflexes qui changent vraiment quelque chose.