Hachez, salez, poivrez : la petite cuisine de la sécurité informatique

Que se passe-t-il dans l’arrière boutique d’un service en ligne consciencieux ? Comment un bon cuisinier développeur s’y prend-il afin de protéger les mots de passe de ses utilisateurs ? 

Avant de jeter un oeil en cuisine pour le découvrir, il n’est pas inutile de revenir sur le problème à résoudre : le développeur ne vous connait pas, il ne vous a jamais rencontré, mais il veut malgré tout pouvoir vous reconnaître de manière fiable lorsque vous reviendrez sur son service.
La manière la plus simple d’y parvenir est de vous demander de choisir lors de votre inscription un secret (votre mot de passe) qu’il conservera précieusement, le plus souvent dans une base de donnés accessible depuis son application web. Désormais toute personne prétendant être vous-même devra lui fournir le même secret en arrivant, et notre développeur n’aura plus qu’à le comparer à celui qu’il a en stock. S’ils sont identiques, vous entrez, sinon, il faudra tenter autre chose !

Le lecteur attentif aura remarqué que les mots de passe de tous les utilisateurs du service sont donc écrits dans une base de données parfaitement accessible à l’application web. Cela est nécessaire car l’application doit pouvoir vous demander votre mot de passe d’un côté et de l’autre aller le comparer à celui qui a été stocké la première fois. Comment alors empêcher un pirate d’aller lire directement la base de donnée et consulter ainsi la totalité des mots de passe qui y sont stockés ?

Réponse courte : c’est très difficile ! Evidemment il existe une série de mesures de protection élémentaires bien connues. Ainsi la base de donnée est elle-même systématiquement protégée par mot de passe et elle n’est généralement pas accessible directement depuis Internet : seule l’application web est autorisée à l’interroger.
Le développeur consciencieux aura également pris soin de concevoir son application afin qu’un attaquant ne puisse pas la forcer à lire pour son propre compte les mots de passe (via la fameuse attaque de type « injection SQL », notamment). Et il existe également d’autres mesures de protection, moins élémentaires, qui visent à protéger l’infrastructure elle-même, et même les personnes qui disposent d’un accès à la base de données.

Mais quoi qu’il en soit, le développeur réaliste partira du principe que la base de données contenant les mots de passe de ses utilisateurs tombera un jour ou l’autre aux mains des pirates. Son objectif est alors de rendre la vie difficile au pirate qui tentera de lire ces mots de passe volés.

Hachez menu, menu

La première technique consiste à « hacher » les mots de passe. N’y voyez pas cependant l’outil indispensable du boucher mais plutôt une fonction mathématique, dite fonction de « hash« . 

Cela consiste, en partant d’un mot de passe parfaitement lisible, à produire un suite de chiffres et de lettres totalement distincte. Ainsi le mot « Casimir » (un très mauvais mot de passe, au demeurant) devient 8a7b9eadc09b43afa96ce42c5febdca94ea8ac04 une fois passé à la moulinette de la fonction SHA1, qui n’est qu’une parmi d’autres.

Mais attention : ce n’est pas là un « code secret » : n’importe qui peut trouver le « hash » de Casimir, il n’y a pas besoin de clé secrète. Tout cela est public (vous pouvez d’ailleurs essayer vous-même sur ce site).
Quel est l’intérêt, alors, de hacher les mots de passe ?

Cela empêche le pirate de les lire immédiatement dans la liste qu’il vient de dérober.
Dans le cadre d’une utilisation normale lorsque l’utilisateur se présente sur le site web il entre son mot de passe, qui est alors dit « en clair » (Casimir, ici). L’application web en calcule ensuite le hash et compare ce dernier avec le hash stocké dans la base de données. Le mot de passe n’est donc jamais vu, ni stocké, en clair.

Si le processus est transparent pour l’utilisateur, pour le pirate la tâche est plus corsée. Pour savoir qu’il faut entrer sur le site web le mot « Casimir » alors qu’il ne dispose que du hash 8a7b9eadc09b43afa96ce42c5febdca94ea8ac04, l’attaquant doit essayer tous les mots possibles et calculer leur hash avant de les comparer à ceux présents dans la base de données volée. Quand c’est bien fait, cela peut prendre une éternité…

A ce stade, l’on comprend donc déjà tout l’intérêt de ne pas choisir comme mot de passe des termes usuels présents dans un dictionnaire : car pour se faciliter la tâche les pirates ont depuis longtemps pris l’habitude d’essayer automatiquement tous les mots du dictionnaire (et dans plusieurs langues…) à chaque vol de mot de passe. Ils calculent le « hash » de chaque mot du dictionnaire et vérifient (automatiquement bien sûr) si un hash équivalent existe dans la liste des mots de passe volés. Si c’est le cas, ils viennent de casser un mot de passe et peuvent se connecter au compte dérobé.

Pour leur complexifier la tâche, les spécialistes de la sécurité (et surtout les mathématiciens, que l’on ne remerciera jamais assez de ne pas avoir décroché, eux, pendant les cours de math du lycée) ont créé des fonctions de hachage qui exigent de consacrer un temps relativement long pour calculer un hash. Cela se joue certes en millisecondes, mais la différence est de taille. Le postulat est que lorsqu’un utilisateur légitime se connecte l’application web dispose, elle, de tout le temps nécessaire pour calculer le hash unique de son mot de passe. Y consacrer quelques millisecondes supplémentaires ne va donc rien changer pour elle.

Pour un pirate qui vient en revanche de dérober plusieurs centaines de millions de mots de passe, la différence peut s’exprimer en années de calcul. C’est toujours bon à prendre, d’autant que pendant ce temps là la victime est censée contacter ses utilisateurs pour leur demander de changer de mot de passe. Chaque heure qui s’écoule voit donc le nombre de mot de passe valides se réduire pour le pirate, et donc la valeur de son butin diminuer.

A titre d’exemple aujourd’hui, l’état de l’art est d’utiliser une fonction telle bcrypt, qui peut offrir une « complexité » de calcul des hashes suffisante pour rendre extrêmement coûteux le calcul en masse.

Evidemment, les pirates n’allaient pas en rester là. Puisque il faut aller très vite et qu’au moment d’une brèche ils ne disposent pas toujours de plusieurs mois de calcul devant eux, qu’à cela ne tienne : ils vont pré-calculer les hashes des mots les plus communs (plusieurs millions, tout de même). Ces lots de hashes pré-calculés s’appellent des tables arc-en-ciel. Ainsi lorsqu’ils mettront la main sur une nouvelle liste de mots de passe la comparaison sera immédiate grâce à leurs fameuses « rainbow tables » (tables arc-en-ciel).

Là encore, vous comprenez peut être mieux pourquoi choisir « 123456 » comme mot de passe (ou « Casimir » !) n’est pas une bonne idée : ils ont été pré-calculés dans des tables arc-en-ciel depuis très longtemps, et seront donc les premiers à tomber.

Salez généreusement !

La réponse des défenseurs ne s’est pas faite attendre : pour empêcher les pirates de pré-calculer ces fameux hashes, l’on va désormais ajouter à chaque mot de passe une valeur arbitraire, différente pour chaque utilisateur, qui sera collée au mot de passe en clair juste avant le calcul du hash. Ainsi bien que vous entriez « Casimir » dans le champs « mot de passe » de votre service en ligne, sous le capot en réalité c’est le mot de passe « 494301c9-2e9c-48ef-965e-2a74ac373dc9::Casimir » qui est haché et comparé avec l’original.

Cette valeur, c’est le fameux « sel » du mot de passe ! Ce sel doit être unique pour chaque utilisateur, mais il n’a pas besoin d’être secret : il peut apparaître tel quel dans la base de données, à côté des autres informations. Car son seul objectif est d’empêcher le pirate d’utiliser les tables précalculées dont il dispose.

Il y a en effet très peu de chance pour qu’il dispose déjà d’une table arc-en-ciel contenant tous les mots du dictionnaire déjà hachés avec le sel « 494301c9-2e9c-48ef-965e-2a74ac373dc9 », puis la même chose avec le sel « 594301c9-2e9c-48ef-965e-2a74ac373dc0 », et ainsi de suite. Il va donc être obligé de repartir de zéro et calculer en temps réel pour chaque mot de passe son hash avec le sel indiqué. Et tant pis pour l’arc-en-ciel !

Et poivrez pour relever le niveau

Nous sommes déjà ici sur de la bonne pratique : des mots de passe « hachés » à l’aide d’un algorithme sérieux tel bcrypt et salés individuellement devraient donner du fil à retordre à notre pirate. Mais il reste un dernier As dans la manche du défenseur : le poivre !

Le poivre est l’exact opposé du sel : il s’agit d’une valeur unique (alors que le sel est différent pour chaque utilisateur) et qui doit être gardée secrète (alors que le sel est stocké en clair). Cette valeur est conservée en dehors de la base de données, le plus souvent dans le code de l’application elle-même.

Le poivre est utilisé exactement comme le sel, en l’ajoutant devant le mot de passe et son sel, avant de calculer le hash.

Quel intérêt ? Là encore, l’objectif est de forcer le pirate à travailler plus dur.

Car très souvent lors d’un piratage seule la base de données est dérobée. Soit parce que le pirate ne parvient pas à prendre le contrôle de l’infrastructure et des serveurs (il n’a réussi qu’à exploiter une injection SQL et donc obtenir seulement le contenu de la base de données), soit parce qu’il manque de temps pour explorer l’environnement et qu’il va alors au plus facile à repérer : la base de données. 

En ajoutant une valeur supplémentaire secrète avant chaque hash, l’on complexifie considérablement le travail du pirate car l’on vient tout simplement de renforcer mécaniquement l’ensemble des mots de passes en augmentant leur longueur et leur complexité, avec une valeur qui lui demande – s’il veut la découvrir – un accès plus étendu au système piraté, ce dont il ne dispose peut être pas (dont un accès au code source de l’application).

Vous voilà désormais en mesure d’évaluer, lorsque vous lirez les informations au sujet de la prochaine méga-brèche, le niveau de l’alerte : 

  • « Les mots de passe étaient stockés en clair » : catastrophe (et accessoirement, à la limite de la faute professionnelle)
  • « Les mots de passe n’étaient pas salés » : presque tout aussi catastrophique aujourd’hui, sauf s’il est indiqué qu’ils étaient hachés avec bcrypt (qui sale automatiquement)
  • « Les mots de passe étaient hachés, salés, poivrés » : relax !

Et bon appétit, bien sûr !

   

Plus d'info :
  •  
Lire les articles précédents :
Le consultant, le technicien et les métiers

Ou comment avoir collectivement tort quand tout le monde a raison. Et comment la transformation numérique, ce n'est pas juste...

Fermer