Salut à tous !
Aujourd’hui, je vous propose de dépatouiller l’utilisation des fonctions de hachage pour stocker les mots de passe.
Et promis, ça va être assez facile.
On se sert de fonction de hachage (cf. cours précédent) en informatique pour se connecter à un site Web ou votre ordinateur lorsqu’on utilise un mot de passe. En effet, votre mot de passe n’est pas stocké tel quel (“en clair”), mais sous forme de haché et, si c’est bien fait, “mixé” avec ce que l’on appelle un sel.
Prérequis :
- Connaissances basiques sur l’informatique
- Avoir lu l’article sur les fonctions de hachage.
La réalité des fonctions de hachage et leur application aux mots de passe
En informatique, une fonction de hachage prend des données (fichiers, blocs, etc.) et en produit une empreinte de taille fixe (assez court, usuellement entre 128 et 512 bits).
Les fonctions de hachage sont employées par votre ordinateur assez régulièrement, afin de vérifier l’intégrité (non modification) de fichiers. Par exemple, un fichier critique peut être surveillé par le système, ou encore lors d’installations/téléchargement de logiciels. En cas de haché calculé différent de celui d’origine, quelque chose d’anormal s’est produit donc on alerte l’utilisateur.
Comme ces fonctions sont très rapides à calculer et qu’elles sont difficile à inverser (c’est notre résistance à la pré-image du cours précédent). Quelqu’un s’est dit : pourquoi ne pas stocker les mots de passes des utilisateurs ?
Prenez le site AcheterUnSuperTruc.com. Il dispose d’une boutique en ligne, et donc d’une gestion de clients par compte, accessible via un couple adresse e-mail / mot de passe. Vous avez un compte, et votre mot de passe est stocké haché sur le serveur. Vous utilisez votre mot de passe habituel, Jeanine1946, le prénom et l’année de naissance de votre mère.
Jeanine1946 -> Fonction de hachage SHA256
-> 3d6155e85ccd2c725d39827ad97d23627265a4bd1b84561b5b145dea5d4e5108
C’est le haché qui sera sauvegardé dans la base de données clients du site.
A chaque connexion sur ce site, le serveur va hacher le mot de passe que vous saisissez dans la fenêtre de connexion, et comparer le résultat au haché stocké lors de la création du compte. Si les deux sont identiques, le mot de passe saisi était identique (cf. résistance à la seconde pré-image et aux collisions dans le cours précédent).
Malheureusement, un pirate décide et réussi à récupérer la base de données du site, et donc de vos coordonnées, vos commandes, … et du haché de votre mot de passe, Jeanine1946. Il souhaite trouver votre mot de passe et, à condition de connaître la fonction de hachage utilisée (et tout le monde utilisent les mêmes donc ce n’est pas bien difficile), il pourrait y arriver. On peut distinguer 3 méthodes, qui ont malheureusement déjà fait leurs preuves :
- L’attaque par dictionnaire : il va hacher pleins de “mots” d’un “dictionnaire” de mots de passe couramment utilisé, des mots de la langue ciblée, des noms propres, etc. Les 500 mots de passe les plus courants sont utilisés par plus de 75% des utilisateurs.
- L’attaque par force brute, ou brute-force : il va hacher toutes les combinaisons possibles de lettres/chiffres/symboles : a, b, …, aaa, aab, aac, …, aba, abb, … baa… C’est très très long mais comme la plupart des fonctions de hachage sont très rapides, ça fonctionne rapidement sur les mots de passe courts (moins d’une minute avec un ordinateur de jeu pour calculer les hachés avec SHA1 de tous les mots de passes comprenant jusqu’à 6 caractères pouvant être un mélange de lettres, chiffres et caractères spéciaux).
- Les rainbow tables, ou tables arc-en-ciel : elles contiennent toutes les combinaisons possibles des mots de passe en fonction des paramètres choisis à la génération. Ils disposent de correspondances directes mot de passe <-> haché. En revanche, ces tables sont extrêmement volumineuses, jusqu’à plusieurs Téraoctets ou bien plus en fonction des paramètres : longueur du mot de passe, chiffres, lettres, symboles, etc. Pour de nombreux mots classiques, une simple recherche sur votre moteur de recherche préféré est suffisante. Essayez 5ed25af7b1ed23fb00122e13d7f74c4d8262acd8 par exemple.
Mettons un peu de sel dans les épinards
Heureusement pour vous, AcheterUnSuperTruc.com a bien fait les choses. Afin de compliquer la recherche de votre mot de passe par un pirate, le site a utilisé ce que l’on appelle un sel, différent pour chaque utilisateur. Un sel, c’est une donnée informatique qui n’est pas secrète pour l’administrateur du site, souvent aléatoire, qui va être ajoutée au mot de passe avant hachage. Reprenons l’exemple de tout à l’heure.
Génération de sel de manière aléatoire pour cet utilisateur : sel = dac6595c04dda81
Jeanine1946+sel -> Fonction de hachage SHA256 -> f1c829b4039db06ef077637b8c5c25544810c557b82d40c1e22c5f2cc2889b5e
Cette fois-ci le haché et le sel seront sauvegardés, et pas au même endroit si possible.
Lors de la connexion au site, le serveur récupère le mot de passe saisi par le client, trouve le sel correspondant à l’utilisateur et applique sa fonction de hachage avec sel. Si le haché ainsi calculé est identique à celui stocké sur le serveur, le mot de passe saisi est correct (cf. résistance à la seconde préimage et aux collisions).
En quoi cela complique-t-il la tâche du pirate ? Si celui-ci n’a pas accès au sel mais uniquement aux empreintes de mot de passe, il lui devient impossible d’attaquer par dictionnaire, brute-force ou rainbow table. Et même s’il y a accès, le sel compliquera un peu sa tâche, notamment pour l’attaque par rainbow table. Par contre, si les sels sont obtenus par le pirate, il pourrait retrouver les mots de passe.
Une autre méthode est d’utiliser une “clé”. Son utilisation est similaire à un sel sauf que la même clé sera utilisée pour tous les mots de passe et qu’elle sera conservée au secret (chiffrée ou dans un endroit particulièrement protégé). Cela limite le risque que le pirate trouve la clé et donc retrouve tous les mots de passe. Par contre si deux utilisateurs ont le même mot de passe, on pourra le savoir. C’est pour ça qu’on utilise, quand c’est possible, un mélange de ces deux techniques.
Maxence (avec un grain de sel de Cryptie)
Petite mise au point
Vous l’aurez compris, hacher n’est pas chiffrer. Nous n’avons pas parlé de chiffrement encore (cela ne saurait tarder), mais le chiffrement implique le fait qu’il y ait une clé pour cacher le message, et que l’on retrouve le clair lors d’un déchiffrement ensuite. Ce n’est pas le cas du hachage.
Pour aller plus loin
https://fr.wikipedia.org/wiki/Salage_(cryptographie)
PS : Les plus avancés d’entre vous me diront que j’aurai pu parler de BCrypt, SCrypt, de PBKDF2 et autres algorithmes de dérivation, et je ne l’ai pas fait, c’est volontaire. Ils feront l’objet d’un autre article. 🙂
PS2 : L’article a été profondément édité le 23 juillet pour prendre en compte le nouvel article sur les fonctions de hachage qui en sera le pré-requis.
C’est super Chef!
Merci d’avoir commencé par un article simple à comprendre avec des illustrations adapté à la situation.
Bonne continuation! 🙂
Bon article !
Remarque : Je pense qu’il y a une typo dans :
> un pirate décide et réussi à récupérer…
C’est plutôt : un pirate décidé réussit à récupérer…
Super intéressant, merci pour ces explications, continuez comme ça 😉
Excellente initiative !
Je viens de découvrir votre site (par Reflets.info), et je compte bien suivre les articles que vous publierez… tant que j’en serai capable. Alors continuez à faire de la bonne vulgarisation comme vous avez commencé.
Bon vent !
Sympa comme article.
Étant arrivé ici suite a un échange crypter/chiffrer, je me pose la question :
Si le terme “crypter” serait de dire que l’on “code un fichier sans en connaître la clé et donc sans pouvoir le décoder ensuite. “, c’est donc exactement ce que fait le hachage non ?
Du coup le terme en devient correct non ? ( hormis la non présence dans le dico ).
Du coup ça ferait chiffrer = qu’on peut décoder / crypter = qu’on peut pas décoder ?
Vraiment très bien ! Décrit avec autant de clarté que possible des notions pas toujours simple à appréhender.
J’ai hâte de lire les autres articles.
Merci !!
Super méthode d’explication. Je vais le relire pour être sûr d’avoir bien tout compris.
3 petites corrections à apporter à ce texte :
– la première déjà relevée par Laurent ;
– la seconde que voici : “On peut distinguer 3 méthodes, qui ont malheureusement déjà fait leurs preuves”
– la troisième : “une donnée informatique qui n’est pas secrète … qui va être ajoutée”
Encore bravo de permettre aux personnes non-initiées de mieux comprendre le chiffrement.
Re-bonjour Gax3,
Corrigé, encore merci.
Pour le moment le site se limite aux fonctions de hachage, j’espère trouver un peu de temps prochainement pour plus d’explications, notamment Cryptographie Symétrique / Cryptographie Asymétrique.
Passez une bonne journée.
2 commentaires :
“Un sel, c’est une donnée informatique qui n’est pas secrète pour l’administrateur du site,” => Une formulation plus clair serait de dire que le sel n’est connu que par les entités qui ont besoin de calculer et vérifier le hash (donc la partie frontend d’un site web pour le calcul, et la partie backend de ce meme site web pour la vérification).
Une autre méthode est d’utiliser une “clé” => Je pense qu’il ne faut surtout pas parler de clé, mais d’un sel qui est unique (par opposition au passage précédent, où chaque utilisateur a son propre sel).
Salut Coulibaly,
D’abord, désolé du retard sur la réponse… :/
Sur le premier point, je suis d’accord. Néanmoins il s’agit de vulgarisation, et une ‘simplification’ a été utilisée (parler de Frontend et de Backend n’était pas le but de cet article…)
Pour le deuxième point, on appelle ça un ‘poivre’ (pepper in English) en cryptographie, et c’est pour ça que clé est entre \” \” ^_^
Je comprends tout à fait tes points, et même techniquement je les partage. Mais ça reste de la vulgarisation. Il y a très peu de termes techniques dans cette intro aux fonctions de hachage…
J’ai un nouveau boulot (je suis formateur en sécurité informatique), et je **devrais** pouvoir avoir le temps d’entrer un peu plus dans le détails des choses maintenant, du moins je l’espère.
En espérant avoir justifié la rédaction de cet article 🙂
Max