Mots de passe et entropie

Un mot de passe est un secret dont la connaissance donne un privilège.  La signification originale était que celui qui pouvait dire ce mot de passe, pouvait passer les gardiens et entrer dans la ville ou le château.  C'est un mot (secret) qui vous permet de "passer".  Dans le sens de la cyber sécurité, le privilège n'est pas de pouvoir, physiquement, passer une porte ou un gardien, mais de franchir un obstacle afin de pouvoir:

  1. accéder à des informations (lire des e-mails...)
  2. donner des instructions à une machine
  3. accéder à un compte cloud
  4. modifier des données sur une machine

Ces privilèges ont été accordés, on peut le supposer, pour des raisons légitimes, c.a.d. vous connaissez le mot de passe, parce que vous avez de façon légitime droit d'avoir l'accès, par exemple, à un compte e-mail.  Le mot de passe sert seulement à pouvoir automatiser votre accès, sans devoir vérifier à chaque fois la légitimité de cet accès.   Ainsi, là où le but est de donner accès aux personnes ayant un droit légitime d'accès, on le remplace par le "proxy" des gens qui connaissent un mot de passe.  Idéalement, donc, les gens, et seulement les gens, qui ont légitimement accès peuvent connaître le mot de passe.  Est-ce possible que des gens qui n'ont pas légitimement accès (qu'on appellera "des attaquants"), connaissent quand-même le mot de passe pour en abuser ?  Il y a trois façons dont un attaquant peut apprendre le mot de passe:

  1. une personne qui connaît le mot de passe pour des raisons légitimes, lui donne ce mot de passe volontairement
  2. une personne qui connaît le mot de passe pour des raisons légitimes, l'a enregistré quelque part (post-it, fichier...) et l'attaquant a accès à cet enregistrement
  3. l'attaquant devine le mot de passe

Il est clair que la nature du mot de passe ne joue pas dans les deux premiers cas ; mais la nature du mot de passe a un rôle primordial dans la troisième façon de faire. Là aussi, il faut distinguer deux cas:

  1. En essayant de deviner le mot de passe, l'attaquant a une façon facile de vérifier si sa devinette est la bonne
  2. En essayant de deviner le mot de passe, l'attaquant n'a pas de moyens pour vérifier si c'est bon, sauf en essayant de l'utiliser et donc, de trahir le fait qu'il essaie

Le cas le plus dangereux est clairement le premier, et c'est là que la notion que nous allons introduire, est importante: la notion d'entropie de mot de passe, qui est une mesure objective de la difficulté de deviner un mot de passe.

L'erreur qu'on peut facilement commettre, est de penser que si la façon dont nous avons choisi un mot de passe est impénétrable, l'attaquant ne peut jamais le deviner, car il ne pourra jamais suivre le même raisonnement.  Imaginons que je choisis un mot de passe consistant d'un seul chiffre, mais ce chiffre est obtenu de la façon suivante: je prends le jour d'anniversaire de ma femme, et je multiplie cela avec mon année de naissance.  J'ajoute le carré du numéro de ma maison, et je multiplie le tout avec les 3 derniers chiffres de mon numéro de carte bancaire.  En suite, je vais soustraire de cela, les quatre premiers chiffres du numéro de téléphone de ma tante.  Du nombre obtenu, je prends le deuxième chiffre.  C'est 8.  Personne ne pourra le deviner, non ?  Personne ne sait comment j'ai pu fabriquer ce chiffre.  L'erreur est de penser que l'attaquant doit retrouver cette façon de raisonner pour deviner le résultat.    En fait, l'attaquant doit juste essayer: 0, 1, 2, 3, 4, 5, 6, 7, 8 ou 9.  S'il peut essayer 10 mots de passe, il va trouver votre mot de passe et obtenir un accès illégitime.  La raison est simplement que votre mot de passe consiste de seulement un seul chiffre, et que cela implique qu'il n'y ait que 10 possibilités parmi lesquelles vous avez choisi votre mot de passe, raisonnement compliqué, tirage au sort, ou pas.  On dit qu'un mot de passe comme ça possède une très faible entropie.  L'entropie est essentiellement le logarithme, en base 2, du nombre de possibilités de choix du mot de passe, et exprimé en "bits".  Ici, le "chiffre de passe" a une entropie d'un peu plus que 3 bits (3.32 bits).  C'est extrêmement faible.

Ainsi, un bon mot de passe doit avoir beaucoup d'entropie.  Il doit y avoir beaucoup de mots de passe possibles.  Mais en même temps, il faut pouvoir se souvenir du mot de passe, car sinon, on va l'écrire et l'enregistrer partout, et alors, on rend le mot de passe vulnérable d'une autre façon.

L'entropie est additive, dans le sens suivant: si on combine deux mots de passe en un seul, en les collant ensemble, l'entropie du mot de passe combiné, est la somme des entropies de chaque mot de passe individuellement, à condition que les choix des deux mots de passe sont indépendants.  Ainsi, un mot de passe de 3 chiffres aura une entropie de 3 fois 3.32 bits, ou 10 bits.  Il faut effectivement essayer 1000 mots de passe, de 000 à 999, pour être sûr de deviner le bon.

Il y a plus de lettres que de chiffres: il y a 26 majuscules, et 26 minuscules, ce qui nous donne une entropie par lettre de 5.7 bits.  Un mot de passe de 3 lettres (majuscules et minuscules mélangées) a donc 17.1 bits d'entropie.  C'est toujours faible, mais c'est plus que 3 chiffres.

Un mot courant aléatoire du dictionnaire français contient à peu près 10 à 12 bits d'entropie (selon que ce dictionnaire possède 1000 mots courants, ou 4000 mots moins courants).  Il vaut mieux considérer 7-8 bits par mot si c'est des mots dans une phrase, car la corrélation entre mots dans une phrase fait qu'on ne place pas les mots de façon parfaitement aléatoire.  Il y a des études qui indiquent que l'entropie par mot d'un langage courant, utilisé normalement dans un texte, tourne autour de 6-11 bits par mot, selon la langue.  Une estimation de 7-8 bits par mot est un bon indicateur sans prétention de grande précision.

Si on combine chiffres, lettres et symboles comme +,-,#,$,% etc... on peut arriver à presque 7 bits par symbole.  C'est pour cela que beaucoup de conseils de mots de passe consistent à vous demander/imposer d'utiliser des mots de passe qui consistent de lettres majuscules, minuscules, chiffres et symboles, afin d'augmenter l'entropie par symbole.  C'est totalement stupide.  Cela n'a qu'un sens si le nombre de symboles dans un mot de passe est très restreint, ce qui était le cas il y a 20 ans, quand un compte Unix avait un mot de passe de 8 symboles.

C'est stupide, parce qu'il est difficile pour un être humain de se souvenir d'une série de symboles aléatoires sans signification.  Ainsi, on se limitera toujours à des mots de passe de quelques symboles, s'il faut des majuscules, minuscules, chiffres et symboles, et l'entropie totale du mot de passe restera très faible.  Il vaut mieux avoir un très long mot de passe qu'on arrive à retenir, qu'un petit mot de passe avec beaucoup d'entropie par symbole.

Le mot de passe "le_jour_ou_j_ai_rencontre_ma_femme_j_etais_sur_la_tour_eiffel" contient beaucoup, beaucoup plus 'entropie que "Ux%!4Fk7" et le premier est beaucoup, beaucoup plus facile à retenir que le deuxième.

 Le premier mot de passe contient à peu près 14 x 8 = 112 bits (ou 14 x 7 = 98 bits) d'entropie, le deuxième contient 8x7 = 56 bits d'entropie.

Le premier mot de passe commence à avoir une quantité d'entropie comparable à une clé cryptographique, tandis que la deuxième est un très bon mot de passe, mais une faible clé.  Mais surtout, le premier mot de passe est facile à retenir.  Le deuxième, pas du tout.  Pour obtenir la même entropie, il faudrait que le deuxième mot de passe contienne 16 caractères bizarres: "Ux%!4Fk78C*)Bz;v".... allez retenir cela !

On trouve encore beaucoup de conseils pour les mots de passe avec des caractères bizarres et des choix totalement aléatoires, mais ce n'est pas mémorisable.  Je conseille de choisir une phrase "insolite" que vous allez pouvoir retenir, contenant plusieurs mots et qui ne vient surtout pas d'un livre, d'un filme ou d'une autre source, mais que vous avez inventé vous-même.   Si vous pouvez y mettre des mots d'une autre langue, ou mieux encore, des mots de votre propre fabrication, sans que cela vous gêne à l'apprendre par cœur facilement, tant mieux.  Connectez les mots avec un symbole de votre choix.   Vous pouvez estimer l'entropie en multipliant le nombre de mots par 8.  Si vous avez 5 mots dans votre phrase, vous avez un mot de passe de 40 bits d'entropie ; si vous en avez 10, vous avez 80 bits d'entropie. 

A quoi sert cette entropie ?  Elle donne une indication de la quantité d'essais avec réponse qui sont nécessaires en moyenne pour deviner le mot de passe sans autre moyen.  Ce nombre d'essais déterminera si essayer le mot de passe est en pratique faisable ou non.  Il faut que ce ne soit pas faisable pour vos attaquants probables.

Mais en quoi consiste un essai ?  C'est là qu'il faut distinguer si on peut essayer "hors ligne" ou s'il faut chaque fois faire un vrai essai de communication.  S'il faut essayer chaque fois de faire une vraie communication avec un appareil sûr, alors quelques dizaines de bits d'entropie sont largement suffisants.  Le code PIN de votre carte bancaire contient 4 chiffres, ce qui correspond à une entropie de seulement 13 bits.  C'est vrai que c'est très faible, mais la seule façon de l'utiliser, c'est avec la possession physique de la carte, et on n'a que trois essais avant que la carte ne soit bloquée.   Ainsi, il faut en moyenne voler 3300 cartes bancaires pour en trouver une dont vous devinez le code PIN et dont vous pouvez vous servir jusqu'à ce que le propriétaire la bloque.  Si vous laissez la possibilité de faire un essai par seconde, alors un mot de passe de 20 bits d'entropie sera deviné en 12 jours (mais vous allez vous rendre compte qu'il y a quelqu'un qui essaie toutes les secondes de se loguer sur le serveur pendant 12 jours...).  Un mot de passe de 30 bits d'entropie prendra 34 ans pour deviner.  Un mot de passe de 10 bits prendra 20 minutes.

On voit tout de suite le niveau de sécurité: deviné en 20 minutes (10 bits - 1 mot) ; deviné en 12 jours (20 bits - 2 mots), deviné en 34 ans (30 bits - 4 mots).   Un mot de passe de 30 bits est donc parfaitement sûr et un mot de passe de 10 bits ne vaut rien dans cette application.  Un mot de passe de 20 bits est sûr à condition que l'administrateur du système détecte des comportements bizarres.

Ainsi, quand un mot de passe est utilisé dans un système qui implique un "vrai essai" pour savoir s'il est bon ou pas, et si on peut mettre une temporisation de l'ordre de la seconde sur ces essais (ce qui ne gène pas l'utilisateur légitime), alors nous voyons qu'il faut choisir des mots de passe au-delà de 20 bits, et que 30 bits est suffisamment bon.  On peut considérablement baisser cela si on limite le nombre d'essais avant de bloquer l'accès pour de bon, mais alors on s'expose à une autre attaque: exclure l'utilisateur légitime par attaque.

Par contre, si un attaquant possède des éléments qui lui permettent de constater hors-ligne si un mot de passe est bon ou non, alors il faut se dire qu'avec l'état de la technologie actuelle:

  • un mot de passe de 60 bits sera cassé par un attaquant modeste mais déterminé
  • un mot de passe de 80 bits peut être cassé par un attaquant avec des moyens conséquents (agence d'espionnage, grand groupe....)
  • un mot de passe de 100 bits est sans doute sûr

Nous voyons qu'il est judicieux d'essayer d'éviter qu'un mot de passe puisse être vérifié hors-ligne. 
Par exemple, si un fichier protégé par un mot de passe est volé, est-ce que le voleur peut vérifier, à l'aide de ce fichier, s'il a bien deviné le mot de passe ou non ?  Avec une installation de moins de 10 000 € on peut tester un mot de passe tous les 10 microsecondes ou mieux ; un mot de passe de 20 bits est alors deviné en 10 secondes, un mot de passe de 30 bits sera deviné en 3 heures. 

Mots de passe versus clés

La distinction entre un mot de passe et une clé est qu'un mot de passe est sensé être appris par cœur et tapé au clavier par un humain ; une clé est enregistrée sur une machine (un ordinateur, un smart phone...).   Un mot de passe, comme on vient de voir, n'a pas beaucoup d'entropie, et il n'est pas raisonnable de demander à un humain d'en connaître beaucoup.  Une clé, par contre, peut contenir beaucoup d'entropie, mais un humain ne peut pas la retenir.

La politique de sécurité consiste en la transformation de la plupart des "mots de passe" en clés.  On peut effectivement considérer que beaucoup d'applications sont encore sur le mode "mot de passe" pour donner un accès à l'utilisateur légitime.  Ce n'est pas la meilleure façon de s'authentifier, mais on n'a pas souvent le choix.  La plupart des services cloud, par exemple, fonctionnent sur le mode "mot de passe".  Si vous voulez vous connecter à votre compte Facebook, vous avez besoin d'un mot de passe de votre compte.  Si vous voulez vous connecter à votre compte Twitter, vous avez aussi besoin du mot de passe de votre compte.  Si vous participez à des discussions sur des forums, vous avez besoin de votre mot de passe pour les comptes sur ces forums.   Si vous voulez acheter des choses sur Amazon, vous avez besoin du mot de passe de votre compte.  Si vous voulez lire vos e-mails, il vous faut donner le mot de passe du compte e-mail pour y accéder.

Ce n'est pas raisonnable d'avoir des mots de passe de grande entropie appris par cœur et différents pour toutes ces applications.  Alors on utilise 3 "stratégies" qui sont toutes défaillantes:

  1. On fabrique un "bon mot de passe" et on l'utilise partout (éventuellement avec une petite variation)
  2. On utilise de simples mots de passe différents partout
  3. Pire: on utilise un même simple mot de passe partout

C'est normal, et ce n'est pas la faute de l'humain ; la faute est que beaucoup de services font l'authentification par "mot de passe", ce qui est une mauvaise façon de faire.

La meilleure solution, quand on est forcé de choisir un "mot de passe" pour une application, est de considérer ce mot de passe comme une clé.  Alors, il ne faut pas se souvenir de ce "mot de passe", mais il faut l'avoir enregistré quelque part.  Contrairement aux mots de passe, ces clés ne doivent donc en principe jamais être mémorisé, ni, tapé au clavier.  Mais c'est là où le bat blesse: la plupart de ces applications présentent une interface humaine où l'humain est sensé "taper son mot de passe".  Il faut donc un mécanisme qui remplit cette interface automatiquement, mais c'est quelque part une rustine sur une mauvaise technologie, imposée par des services ou des applications mal conçus mais qui sont partout.

Un "mot de passe" qui est une clé doit être généré de façon aléatoire, et peut contenir jusqu'à 6-7 bits par caractère si on peut utiliser majuscules, minuscules, chiffres et symboles spéciaux.  Il n'y a pas de raison de ne pas utiliser le maximum de caractères permis (car en plus, beaucoup de services limitent le nombre de caractères).

Un "mot de passe" comme cela aura entre 120 et 140 bits d'entropie s'il contient 20 caractères ; on peut considérer cela comme sûr.  Si on peut utiliser 30 ou 40 caractères, c'est encore mieux, mais souvent la sécurité auxiliaire n'est pas aussi forte, donc ça ne sert alors à rien (mais ça ne coûte rien non plus).

Donc: générez des clés "mot de passe" de façon aléatoire avec majuscules, minuscules, chiffres et caractères bizarres, et utilisez le maximum de caractères possibles, mais de préférence au moins 20, pour avoir une clé sûre.

Mais maintenant, il faut que ces clés "mot de passe" soient enregistrés quelque part.  C'est là qu'il faut utiliser des "gestionnaires de mot de passe" pour pallier au fait que ce qui est une clé, est par erreur considéré comme un mot de passe à taper par un humain.  Il faut donc considérer un "gestionnaire de mots de passe" comme une sorte d'équivalent "clé-mot de passe" que le Key Ring dans la plupart des systèmes d'exploitation qui gère les clés sur un système, mais avec la faculté de pouvoir passer la clé dans une interface pour un humain.

Le problème fondamental qui est posé par cette utilisation erronée de la notion de "mot de passe" dans la plupart des applications, est le suivant: tout est conçu pour un vrai mot de passe (donc mémorisé par un humain) tandis qu'en réalité, c'est une clé qui est enregistrée sur une machine.  La difficulté consistera à transporter cette clé d'une machine à l'autre sans la compromettre.  Un vrai mot de passe n'est pas enregistré, et "voyage avec l'humain" qui connaît ce mot de passe.  Une clé se trouve enregistrée sur une machine.

Mots de passe en local

Le vrai mot de passe reste un outil de sécurisation important, mais comme c'est un "secret fragile" et qu'il ne contient pas une grande quantité d'entropie, qu'il a sa plus grande utilité quand il est mémorisé, et que sa forme la plus évidente est une phrase relativement longue, il faut:

  • limiter le nombre de mots de passe à mémoriser
  • ne pas devoir utiliser le mot de passe tout le temps

Considérons quelques visions ou stratégies qu'on peut suivre et réfléchissons à des attitudes incohérentes.

Le premier cas consiste à choisir un seul bon mot de passe d'une 30 - 40 bits d'entropie (4 - 6 mots) par "environnement", et c'est tout.  On utilise ce mot de passe pour se connecter à ses machines.  On peut aussi considérer la biométrie. Les mots de passe/clés sont "en clair" sur le système, mais dans des fichiers seulement accessibles par l'utilisateur.  Cela correspond à une machine personnelle dont on est le seul administrateur, et dont on a le contrôle physique garanti (on ne craint pas l'intrusion).  Le mot de passe sert alors seulement pour éviter l'intrusion occasionnelle par des proches/collègues.   L'avantage est que c'est très léger.  Le désavantage est que la protection est minimale.  Mais il faut se rendre compte que cette sécurité devient déjà beaucoup plus importante quand on utilise le chiffrement du disque.  Une protection de 30/40 bits n'arrêtera aucun voleur du système physique à casser le mot de passe (30 bits, c'est une affaire de quelque minutes ou quelques heures, selon le matériel utilisé - 40 bits commence à jouer dans les semaines), mais cela protège contre l'intrusion occasionnelle par des proches et cela peut rendre la tâche quand-même plus longue, coûteuse et pénible pour l'attaquant.  Il faut se rendre compte qu'un disque chiffré enlève la possibilité de "vite démarrer sur un système sur clé USB et de copier des fichiers en clair".   Votre ordinateur, éteint, peut être démarré sur un autre système, et alors les permissions de vos fichiers ne sont plus d'actualité.  Ainsi, quelqu'un qui peut démarrer votre machine sur un autre système, peut accéder à tous vos fichiers... sauf si le disque est chiffré. 

Le deuxième cas ressemble beaucoup au premier, sauf que vous allez chiffrer vos mots-de-passe-clés avec le même mot de passe de 30 - 40 bits d'entropie que celui qui vous permet de vous connecter à votre machine.  Ce cas de figure, qui peut sembler étrange, a un avantage : vos mots-de-passe-clés sont protégés légèrement contre un administrateur de votre machine qui pourrait être tenté occasionnellement de voler un mot de passe clé, et cela protège vos mots de passe aussi bien que le chiffrement total du disque.  Cela protège aussi contre un accès occasionnel par un collègue.  Les protections sont "légères", parce que la seule différence entre ce cas-ci, et le cas précédent, est que dans le cas précédent, ceux qui pouvaient avoir accès au fichiers de mots-de-passe-clés en clair, ont maintenant à casser un mot de passe de 30-40 bits, ce qui prend quelques heures ou quelques semaines avec un matériel qui n'est pas trop onéreux.

Chiffrer les mots de passe clé avec un autre mot de passe d'entropie comparable n'a pas vraiment beaucoup de sens.  Effectivement, dans la mesure où vous craignez que votre mot de passe "accès" serait compromis, un attaquant peut toujours installer un petit logiciel malveillant dans votre système qui va espionner vos entrées de l'autre mot de passe.  Si vous craignez que votre mot de passe accès est compromis, de toute façon, tout ce que vous faites sur cette machine sera compromis.  Vouloir protéger une liste de mots-de-passe-clés au-delà de l'accès à votre machine est illusoire.  Ainsi, votre mot de passe "accès" est sûr, et vous n'avez pas besoin d'un autre, ou de toute façon, toutes vos actions sur la machine, y compris, tous les mots de passe que vous pourriez taper, sont compromis.  Cela rend donc ce cas inutile.

On peut utiliser un mot de passe de grande entropie (>80 bits) pour se connecter, et/ou chiffrer ses mots de passe clé en local.  Cela a un sens si votre machine est physiquement moins sûre: un portable par exemple, qui peut être volé, ou si ce qui s'y trouve est d'une importance stratégique.  Mais le prix à payer est qu'il faudra taper régulièrement un long mot de passeUtiliser un faible mot de passe pour accéder à la machine, mais un mot de passe fort pour protéger les clés n'a pas de sens.  Si on peut accéder à votre compte (faible protection), alors on peut facilement installer un espion qui va récupérer le mot de passe fort quand vous allez le taper.  Si vous faites la peine d'avoir un mot de passe fort pour les clés, alors, utilisez-le aussi pour l'accès et par exemple, le chiffrement du disque.

Ainsi, nous avons donc localement, 3 cas d'usage qui sont raisonnables, selon la situation:

  1. pas de mot de passe (ou seulement pour se loguer), mots-de-passe-clés en clair, sur une machine physiquement sûre
  2. mot de passe pour se connecter, disque chiffré, une fois connecté, les mots-de-passe-clés sont disponibles en clair
  3. mot de passe pour se connecter, et même mot de passe pour déchiffrer les mots-de-passe-clés (on peut selon le choix, chiffrer le disque ou non)

Dans le premier cas, la sécurité vient de la sécurité physique de la machine: si vous êtes sûr qu'elle ne peut pas être accédée physiquement, et qu'elle ne peut pas être compromise, il n'y a pas besoin d'un mot de passe.  Pour les deux autres cas, la force du mot de passe (30 bits - 80 bits) dépend de la menace crédible et de l'enjeu.   Plus le mot de passe est grand, plus il protège, mais plus que vous devez taper un long mot de passe.  Un petit mot de passe protège contre l'intrusion occasionnelle de proches ou l'accès physique rapide ; un gros mot de passe protège partiellement en cas de vol, ou d'accès physique longue durée.

Les gestionnaires de mot de passe dans Firefox et Thunderbird feront parfaitement l'affaire pour ces cas.

Gardez votre capacité à connaître quelques mots de passe différents plutôt pour des environnements différents (utilisation privée, travail, club de sport ....).

Il faut savoir que même un "faible" mot de passe, quand les mots-de-passe-clés sont seulement gardés localement, peut vous donner une protection adéquate, si se mot de passe protège contre une intrusion physique locale.  Si vous ne craignez pas d'intrusion du tout, le mot de passe n'est même pas nécessaire.  Votre sécurité dépend alors seulement de l'entropie de vos clés que vous utilisez "à l'extérieur", et pas du mot de passe.

Mots de passe "cloud"

La situation est totalement différente si on garde ses mots-de-passe-clés dans le cloud, car alors, il n'y a plus de protection locale, et le mot de passe est le seul rempart contre la disponibilité de vos mots de passe partout dans le monde.  C'est donc simple: dans la mesure du possible, il ne faut pas en avoir.

Je crois qu'il faut éviter l'utilisation d'un gestionnaire de mots de passe "cloud" si on peut faire autrement.  et si on l'utilise, il faut l'utiliser de façon indirecte. Effectivement, l'utilisation standard de ces outils (LastPass, Firefox Sync...) est dangereux, car on expose tous ces clés de haute entropie à tout l'internet par un mot de passe, certes de qualité, mais de moins d'entropie que les clés qu'ils protègent. Effectivement, toute personne qui peut accéder au compte du gestionnaire de mot de passe cloud, peut obtenir vos clés, et pour accéder à ce gestionnaire, il suffit de deviner le mot de passe du gestionnaire, ce qui est plus facile, que de deviner une clé.  Vos clés sont cryptés dans le cloud, mais seulement avec un mot de passe ; vous n'avez pas le contrôle sur le reste.  Tant que le gestionnaire de mot de passe fonctionne bien, il y aura des temporisations sur les essais, mais, comme avec le service iCloud de Apple en 2014, il peut y avoir une faiblesse qui laisse un attaquant essayer rapidement beaucoup de mots de passe. 

C'est une aberration de mettre des clés de grande entropie dans le cloud, quand elles sont protégées seulement par une plus faible entropie d'un mot de passe.  La seule façon raisonnable de mettre une liste de clés dans le cloud, est de les protéger avec une clé de même entropie.  La seule façon crédible d'utiliser un gestionnaire de mots de passe "cloud" est d'utiliser une clé pour ce gestionnaire, ce qui repousse le problème vers le gestionnaire de cette clé bien sûr, mais il y a moins a gérer.

Il y a deux applications standard qui utilisent régulièrement des "mots de passe": c'est votre navigateur internet, et votre client e-mail.  Je propose fortement d'utiliser Firefox et Thunderbird respectivement pour les deux.  Ces deux applications ont un bon gestionnaire de mots de passe local intégré.  Il faut activer le "Master Password" pour les deux ; ainsi, vos mots-de-passe/clés sont cryptés localement.

Cependant, l'utilisation de ce Master Password peut être contraignant car il faut le taper une fois par session au moins. 

Il n'y a qu'une seule exception à la règle de ne pas utiliser de mot de passe "cloud": c'est quand vous êtes obligé de devoir, peut-être, voyager "nu", sans appareil.  Par exemple, vous êtes en fuite (ou la possibilité se pose qu'un jour vous serez en fuite).  Ou vous vivez dans un environnement qui peut être détruit, ou d'où vous pouvez être exclu à tout moment.    Alors, il faut apprendre par cœur un mot de passe d'au moins 100 bits, et vous pouvez utiliser le cloud.  Mais seulement dans ce cas.  Et vous n'avez toujours pas besoin d'un gestionnaire "cloud", mais seulement d'un stockage cloud.

Il faut bien se rendre compte de la grande différence entre avoir des clés en local, ou des clés dans le cloud.  Les clés en local ne doivent être protégées contre des intrusions locales, c. a. d. des proches/collègues et des intrusions rares.  Le pire cas est le vol d'appareil, qui peut arriver, mais dont on peut espérer qu'il est rare, et qu'il sera remarqué.  Il vous faut alors juste le temps pour changer les clés avant qu'un voleur acharné casse les protections des clés pour les utiliser.  La plupart des vols sont d'ailleurs intéressés par le matériel, et non par des mots de passe à cracker, mais cela fait partie de l'analyse de la menace.  En tout cas, la surface d'attaque pour des clés en local est faible.

Par contre, des clés dans le cloud peuvent être attaquées par tout le monde, et vous ne le savez pas.  La surface d'attaque est grande, et vous n'en connaissez pas l'ampleur.

On peut protester que la surface d'attaque en local contient aussi la corruption des machines, et c'est vrai, mais contre la corruption de machine, aucun système ne protège des clés et mots de passe, car toute interaction avec l'utilisateur peut être espionnée, y compris, donc, tous les mots de passe et accès cloud.  Si vous acceptez de travailler sur une machine corrompue, alors il ne faut pas prendre la peine de vouloir protéger des clés.

Ainsi, la seule façon relativement sûre d'avoir des clés dans le cloud, est, de les chiffrer avec d'autres clés qui ne sont pas dans ce cloud, ou avec un mot de passe exceptionnellement sûr, de plus de 100 bits.  Il faut bien sûr que le chiffrement et le déchiffrage se fasse en local seulement.

La règle d'or est donc: tout ce qui quitte l'environnement local (tout ce qui est "cloud") doit être protégé par une clé (non-mémorisable) unique.  Les mots de passe ne servent qu'en local.  La seule exception est le "voyage nu".

Mais ceci pose alors le problème de la synchronisation de la connaissance des clés sur des appareils différents.

Synchronisation

Le vrai mot de passe n'a pas de problème de synchronisation, car il est dans la tête de la seule entité qui doit la connaître: vous !  Les systèmes de mot de passe ayant été conçu pour cela, il n'y a pas de prévision de synchronisation pour des mots-de-passe-clé.   Alors, il y a des propositions d'utiliser des gestionnaires de mot de passe "cloud" qui font cela pour vous, mais nous venons d'argumenter contre cette utilisation, car vous abaissez la sécurité de vos clés par celle d'un mot de passe comme seul rempart contre tout l'internet.

Si vous utilisez qu'une seule machine, alors le problème ne se pose pas: utilisez le gestionnaire de mots de passe local de Firefox et de Thunderbird (et de Filezilla) et c'est tout: vos clés sont disponibles dans ces applications sur cette machine, et ne la quittent pas (sauf pour le back-up, voir plus loin).  Mais la plupart d'entre nous utilisent plusieurs machines (portables, machines de bureau, tablettes, smart phones...).  Il serait bien d'avoir accès à ses clés sur toutes ses machines.  Comment faire ?

Je propose l'utilisation d'un gestionnaire de mots de passe "local et dédié".   En fait, je n'en connais qu'un seul qui satisfait toutes les exigences, même s'il n'est pas le plus convivial à utiliser: c'est Keepass.  Un gestionnaire de mots de passe doit, selon moi:

  1. être open source (pour s'assurer qu'il ne pompe pas tous les mots de passe en secret et qu'il ne contienne pas de porte dérobée)
  2. être en local, sans compte cloud en fonctionnement hors ligne
  3. avoir quelques fonctions utiles comme la génération de mots de passe/clé aléatoires
  4. être multi-plateforme, qu'on puisse l'utiliser sous windows, linux, android, apple ...

Keepass est essentiellement un gestionnaire d'une petite base de données "mot de passe-clé" qui est chiffrée et avec quelques utilitaires comme un bon générateur de mots de passe-clé.  En outre, le chiffrement a une propriété extrêmement utile: il peut être chiffré à la fois avec un mot de passe et une clé locale, qui sera la façon d'utiliser la synchronisation "cloud" sûre.

Par contre, il ne faut pas utiliser les intégrateurs de Keepass dans Firefox.  Il faut utiliser Keepass comme un outil séparé, dans lequel on va chercher les mots de passe pour les copier dans Firefox, Thunderbird et autre quand on en a besoin la première fois. 

Keepass associe un mot de passe à un "coffre-fort de clés" (une base de données chiffrée) ; et ce mot de passe restera le même pour toute utilisation.  Il faut donc avoir un "coffre-fort" par environnement, même si vous utilisez des clés de deux environnements: alors il faut utiliser deux coffre-forts, chacun avec son mot de passe environnement. 

Il y a différentes façons d'utiliser Keepass, selon le besoin.

  1. partager le coffre-fort sur un réseau local sûr (fichier "maître" sur un serveur local, copie locale et re-copie sur le serveur quand on ajoute des clés).
  2. partager le coffre-fort sur un réseau local et utilisation d'une clé locale sur les machines
  3. partager le coffre-fort dans le cloud et utilisation d'une clé locale sur les machines
  4. partager le coffre-fort dans le cloud avec une clé locale sur clé USB
  5. avoir son coffre-fort sur une clé USB

Quand vous utilisez un coffre-fort avec seulement un mot de passe (donc sans clé), tout le monde qui peut avoir une copie du coffre-fort et le mot de passe peut accéder à toutes les clés qui s'y trouvent.  Si votre réseau local est sûr, alors vous pouvez mettre votre coffre-fort sur un serveur de fichiers sur ce réseau, et vous l'utilisez à partir de chaque machine que vous connectez à ce réseau.  Il est judicieux de faire une copie locale (par exemple, sur un portable ou un téléphone), car si vous emportez votre appareil et qu'il n'est plus sur le réseau local, vous avez toujours vos clés de disponible.  C'est la façon de faire quand vous êtes sur un réseau de confiance, que vous ne savez pas à l'avance sur quelle machine du réseau vous allez avoir besoin d'une clé.  Typiquement, c'est l'utilisation sur un réseau de petite entreprise où on ajoute régulièrement des machines et tout le monde travaille un peu sur toutes les machines.  C'est aussi le cas pour un petit réseau domestique.  Il ne sert à rien d'avoir la clé de chiffrement sur toutes les machines, car alors cette clé ne protège plus rien: là où se trouve le coffre-fort se trouve aussi la clé.

Il peut être judicieux de combiner Keepass et Git.  Cela permet d'utiliser les mécanismes de synchronisation de git avec la/les coffre-forts Keepass.

Si vous voulez ajouter de la sécurité, vous pouvez utiliser le double chiffrement de Keepass.  Alors, il faut copier (une seule fois) la clé de chiffrement sur les machines où vous voulez avoir accès.  C'est une façon d'exclure les machines d'un réseau d'avoir tous accès au clés avec le mot de passe.  Il faut transporter la clé de chiffrement d'une machine à l'autre.  Cela peut se faire par clé USB, ou par e-mail chiffré.  Dès que les machines sur lesquelles vous allez avoir besoin de vos clés est relativement fixe et limitée, c'est le choix à faire.

Exactement la même technique peut être utilisée dans le cloud: vous mettez votre coffre-fort dans le cloud (Dropbox, MegaSync,....), mais vous distribuez la clé de chiffrement "à la main" ou par e-mail chiffré, sur les machines où vous voulez avoir accès.  Cependant, si vous n'avez pas besoin de mettre votre coffre-fort dans le cloud, c'est quand-même mieux.  Il ne faut jamais mettre la clé de chiffrement dans le cloud, sauf par e-mail chiffré éventuellement.

Finalement, vous pouvez vous balader avec une clé USB contenant votre copie de votre coffre-fort.

Si vous avez des mots de passe-clés à synchroniser à travers plusieurs appareils (ce qui est le plus souvent le cas), vous avez localement besoin de "mettre à jour" le coffre-fort, mais aussi, vous devez mettre à jour le coffre-fort "maître".  Comme déjà mentionné, on peut utiliser git pour cela, ou bien, on copie à la main (avec le danger d'écraser la copie "maître" par une version vidée ou cassée...).   On suppose dans la suite que vous avez un moyen de synchroniser le coffre-fort.  Comment l'utiliser localement alors ?

Quand vous utilisez Firefox ou Thunderbird, et vous avez besoin d'accéder à une adresse e-mail ou un site pour la première fois sur cette machine, mais dont la clé se trouve déjà dans le coffre-fort, vous utilisez Thunderbird ou Firefox normalement, et quand on vous demande votre mot de passe-clé pour le compte e-mail ou le compte cloud en question, vous ouvrez (avec le mot de passe du coffre-fort) le coffre-fort de Keepass, et vous copiez (copier-coller) la clé dans l'interface de Thunderbird ou Firefox.  En suite, quand Thunderbird ou Firefox vous demandent s'il faut enregistrer la clé, vous dites oui.  Vous n'aurez plus à utiliser Keepass pour ce compte, sur cette machine, car la clé est enregistré localement dans Thunderbird ou Firefox.

Quand vous créez un nouveau compte et on vous demande de définir un nouveau mot de passe, vous ouvrez Keepass, et vous ajoutez une nouvelle entrée.  Dans Keepass, il y a un bon générateur de mots-de-passe-clés où vous spécifiez le genre de mot de passe-clé (nombre de caractères, minuscules, majuscules, chiffres, symboles...), qui va vous générer un mot de passe sûr et unique.  En suite, vous procédez comme avant: vous copiez ce mot de passe-clé dans Firefox, et vous lui dites de s'en souvenir.  Par contre, il faudra mettre à jour le coffre-fort "maître" maintenant, tôt ou tard.

Quand on vous donne un nouveau mot de passe (vous n'avez pas le choix), alors ajoutez une nouvelle entrée dans Keepass, et copiez le mot de passe dedans.  Il faudra aussi synchroniser le nouveau coffre-fort pour propager ce mot de passe.  Vous pouvez utiliser la même technique pour des mots de passe déjà enregistré dans Firefox ou Thunderbird: ouvrez, dans les préférences, le gestionnaire interne de mots de passe, rendez-les visibles, et copiez dans le coffre-fort de Keepass.

Si en général, vous ne créez pas beaucoup de nouveaux mots de passe par jour, cette technique est largement suffisante et sûre: vous utilisez Keepass comme mécanisme de synchronisation, et vous gardez, pour utilisation quotidienne, vos mots de passe-clés dans Firefox localement.

Cependant, si vous créez beaucoup de nouveaux comptes par jour, et vous changez beaucoup de machines, cette technique peut être lourde, car il faut copier manuellement chaque nouveau mot de passe une fois sur chaque machine entre Firefox et Keepass.  Alors, vous pouvez envisager d'utiliser la synchronisation par un compte Mozilla Sync.  Seulement, il vous faut alors générer (avec Keepass) une clé pour le compte sync, que vous distribuez avec Keepass, et que vous utilisez en suite sur toutes les machines.  Vous vous exposez, comme toute utilisation de gestion de clés "cloud", à des vulnérabilités dans cette gestion.  Il vaut donc mieux seulement utiliser Firefox Sync si vous en avez réellement besoin, et toujours avec une clé.

A part Firefox, Thunderbird, et certaines versions de Filezilla, qui ont leur propre gestionnaire de mots de passe, et où Keepass sert seulement comme outil sûr de synchronisation, il y a aussi des applications de mots de passe en local: les porte-monnaies de crypto-monnaies.  Les clés secrètes d'un porte-monnaie qui permettent de disposer des monnaies (de signer des transactions) sont chiffrés avec un "mot de passe".  Il est judicieux d'utiliser une clé pour ce mot de passe, et d'enregistrer cette clé dans un coffre-fort Keepass. 

Sauvegarde

Nous avons  beaucoup parlé de protéger des clés contre du vol, mais le problème inverse est souvent plus important: perdre ses clés !  Une clé perdue est perdue à jamais.  Il faut donc des sauvegardes.  Avec les coffre-forts de Keepass, qui sont simplement des fichiers sur ordinateur, cependant, il n'y a aucun danger de perdre son coffre-fort, car il y a bien une sauvegarde des fichiers de l'ordinateur (il y a quand-même une sauvegarde, non ? !).

La seule chose qui pourrait se passer, c'est que vous oubliez le mot de passe.   Vous pouvez avoir un problème de santé qui fait que votre mémoire flanche.  Alors, écrivez-le quelque part sur un papier, et enfermez ce papier dans un vrai coffre-fort ou déposez-les chez un notaire.  Faites cela avec tous les vrais mots de passe.  Surtout ceux qui déverrouillent vos porte-monnaies bitcoin et autres...  Le jour où vous décédez, ou le jour où vous avez perdu vos moyens cognitifs, vos proches pourront alors accéder à vos affaires numériques.  Ceci pour le coté privé et personnel ; une notion similaire peut s'appliquer au niveau entreprise.  Dans la mesure où vos clés sont à utilisation professionnelle, il peut être judicieux d'avoir accès au coffre-fort d'un collègue qui n'est pas disponible.  Le chef d'entreprise pourrait tenir un coffre-fort de mots de passe des employés pour leurs mots de passe de leurs coffres professionnels.

Politique de changement de mot de passe

Contrairement à une idée reçue, il n'est pas nécessaire de changer régulièrement de mot de passe ou de clé.  La seule raison de faire cela est quand il y a un soupçon de mot de passe compromis et alors il faut agir vite.  Il est relativement rare qu'un mot de passe compromis ne soit pas utilisé aussitôt.  Un mot de passe de grande entropie qui n'est pas compromis, n'a pas besoin d'être changé, et un mot de passe compromis doit être changé très vite.  Changer son mot de passe tous les 6 mois n'a donc pas de sens.  La difficulté de changer un vrai mot de passe régulièrement est qu'on va ne pas pouvoir retenir autant de mots de passe et qu'on va inventer des "systèmes" qui rendent, finalement, l'entropie du mot de passe plus faible qu'un bon mot de passe gardé longtemps.  Le problème de changer les clés partout, tous les 6 mois, est que la procédure de changement peut introduire des vulnérabilités sur le moment même.  Par contre, dès qu'on a un soupçon de mot de passe ou clé compromise, il faut la changer tout de suite.  Mais tant qu'il n'y a pas ce soupçon, il vaut mieux garder sa clé haute entropie, ou son mot de passe haute entropie.

Récupération de mot de passe: attention !

Beaucoup de comptes dans le cloud ont la possibilité d'y accéder si on a "oublié" le mot de passe.  Souvent, cela se passe en vous envoyant un e-mail ou un SMS avec un "lien de récupération de mot de passe".  Ce lien contient en fait un code, un "mot de passe", qui permet à la personne qui en dispose, de changer le mot de passe du compte.  En fait, cela tue complètement la protection du mot de passe !  Un attaquant a maintenant le choix entre deviner le mot de passe (ce qui est rendu difficile s'il y a une grande entropie), ou intercepter le code envoyé par e-mail ou SMS !

Il faut donc se rendre compte que la sécurité d'un compte e-mail ne concerne pas seulement le contenu des messages, mais aussi, tous les comptes cloud qui vont utiliser cette adresse pour changer le mot de passe en cas d'oubli.   D'où l'importance de protéger un compte e-mail avec un mot de passe-clé de grande entropie, de choisir un hébergeur de e-mail fiable, et surtout, d'utiliser toujours des liens cryptés pour accéder à sa messagerie (TLS/SSL).  Mais comme votre messagerie est dans le cloud, vous n'avez pas le contrôle complet de ce qui peut se passer avec votre messagerie sauf si vous hébergez votre serveur e-mail chez vous (ce qui est une possibilité).  Si vous perdez votre téléphone ou votre carte SIM, et quelqu'un a accès à votre numéro de téléphone, même pendant peu de temps, alors il peut accéder à tous les comptes cloud qui vont envoyer la récupération de mot de passe par SMS.

Il faut dire que Facebook a une bonne solution à ce danger potentiel: si vous donnez votre clé publique PGP à Facebook, alors Facebook vous enverra le message contenant le code (le lien) de façon chiffré.  Ainsi, un attaquant ayant accès à votre messagerie n'aura pas accès à ce code.

Il faut se méfier aussi des "questions de confiance", comme "le nom de jeune fille de votre mère" ou autre.  Dans la mesure où c'est une protection supplémentaire, il n'y a pas de souci ; mais dans la mesure où on permet de changer le mot de passe si on répond correctement à ces questions, il faut alors considérer que la réponse à ces questions est aussi un mot de passe, et donc spécifier des réponses aléatoires avec le plus d'entropie possible.

La sécurité de votre compte cloud n'est pas plus grande que la méthode de récupération de mot de passe la moins fiable.  Si vous gérez bien vos clés, vous n'aurez jamais besoin de ces méthodes ; il faut donc faire en sorte qu'elles ne posent pas de problème.