Salage (cryptographie)

Un article de Wikipédia, l'encyclopédie libre.

Le salage est une méthode permettant de renforcer la sécurité des informations qui sont destinées à être hachées (par exemple des mots de passe) en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques ne conduisent à la même empreinte (la résultante d’une fonction de hachage). Le but du salage est de lutter contre les attaques par analyse fréquentielle, les attaques utilisant des rainbow tables, les attaques par dictionnaire et les attaques par force brute. Pour ces deux dernières attaques, le salage est efficace quand le sel utilisé n’est pas connu de l’attaquant ou lorsque l’attaque vise un nombre important de données hachées toutes salées différemment.

Rappels sur la problématique de la gestion des mots de passe[modifier | modifier le code]

Recommandations pour la protection des mots de passe[modifier | modifier le code]

Les attaques par force brute en ligne représentent une menace modérée : les systèmes en lignes sont en général conçus pour bloquer les attaques les plus grossières et les temps de latence liés à la connexion distante rendent la durée des tentatives prohibitive.

Le principal risque concerne le cas de figure où un attaquant arrive à pirater le système d'authentification et à en extraire la table des mots de passe des utilisateurs. Ce type d'incident intervient malheureusement assez régulièrement[1],[2]. Les systèmes de gestion de mots de passe sont conçus de manière à limiter les conséquences de tels incidents.

Les normes de sécurité informatique actuelles considèrent que seul l'utilisateur doit connaître son mot de passe exact : mot de passe texte brut. Ce choix a plusieurs raisons :

  • d'une part elle peut servir d'authentification ultime de l'utilisateur (les fonctions de hachage cryptographique étant en général choisies pour être difficilement inversables) ;
  • d'autre part les études montrent qu'il est courant que les utilisateurs choisissent le même mot de passe pour plusieurs services[3]. En ne connaissant pas le mot de passe complet, le gestionnaire d'authentification diminue sa responsabilité dans le cas où sa base de mots de passe serait compromise.

Pour atteindre cet objectif, le gestionnaire de mots de passe ne manipule que des empreintes du mot de passe, c'est-à-dire le résultat du traitement du mot de passe par des fonctions de hachage cryptographiques.

Lorsque l'utilisateur définit son mot de passe en entrant celui-ci sous forme de texte brut, celui-ci est traité par la fonction de hachage. Le couple identifiant–empreinte du mot de passe est stocké dans la table des mots de passe du système d'authentification, le mot de passe brut n'étant pas mémorisé.

Lorsque ultérieurement l'utilisateur souhaite s'authentifier, il entre son identifiant et son mot de passe. Le mot de passe est alors traité par la fonction de hachage et le couple identifiant–empreinte du mot de passe est comparé à la table de mots de passe du système.

Principe de l'attaque[modifier | modifier le code]

Comme indiqué plus haut, le risque principal est celui lié aux attaques hors-ligne. La compromission de la table de mots de passe permet à l'attaquant de tromper l'ensemble du système d'authentification compromis, il va cependant tenter d'augmenter son gain en déduisant des versions hachées les mots de passe bruts, sous l'hypothèse que les utilisateurs ont employé les mêmes mots de passe pour d'autres authentifications.

De manière générale, les fonctions de hachages cryptographiques sont conçues pour être mathématiquement très difficiles ou impossibles à inverser directement. L'attaquant tentera donc en général des attaques de confirmation par force brute : pour chaque mot de passe de son dictionnaire d'attaque, il calcule l'empreinte, puis cherche à trouver une correspondance avec les empreintes de la table de mots de passe dérobée. S'il la trouve, il a réussi à trouver un mot de passe, ou au moins une collision avec celui-ci.

Principe du salage[modifier | modifier le code]

Initialisation[modifier | modifier le code]

Le salage consiste à concaténer le mot de passe avec une chaîne de caractères quelconque, le plus souvent aléatoire. Le salage peut être statique : chaque mot de passe est salé avec la même chaîne de caractères (mais ce type de salage est considéré comme dépassé), ou dynamique : chaque mot de passe est salé aléatoirement (cela empêchera à deux utilisateurs d'avoir la même empreinte s'ils ont le même mot de passe).

Dans le cas où le salage est dynamique, chaque enregistrement de la table de mots de passe du système d'authentification contient les informations suivantes :

identifiant | hachage(mot de passe + salage) | salage

Exemple[modifier | modifier le code]

Prenons par exemple le mot de passe « Wikipedia », qui utilisé avec l’algorithme SHA-1 produit : 664add438097fbd4307f814de8e62a10f8905588. Utilisons un salage du mot de passe en y ajoutant « salé ». En hachant « Wikipediasalé », le hashage est maintenant : c0a0770637de1601a08404aff3e88dfb4b58c35b. On voit bien que le hash salé est différent du hash non salé.

Emploi[modifier | modifier le code]

L'utilisateur entre son identifiant et son mot de passe brut. À partir de l'identifiant, le système d'authentification retrouve le salage associé, il concatène le salage et mot de passe brut, traite la chaîne de caractères obtenue par la fonction de hachage cryptographique, puis compare le résultat avec le mot de passe haché enregistré dans la table des mots de passe.

Gains apportés – failles compensées[modifier | modifier le code]

Pour rappel, nous faisons l'hypothèse raisonnable qu'un attaquant qui a pu extraire la table des mots de passe d'un système d'authentification a pu également facilement prendre connaissance des salages employés, statiques ou dynamiques.

Attaques pré-calculées[modifier | modifier le code]

Afin d'augmenter les temps de cassage, les fonctions de hachage cryptographiques sont en général conçues pour présenter une charge de calcul suffisamment faible pour ne pas être gênante en usage normal, mais suffisamment importante pour être handicapante pour une attaque par force brute.

L'attaquant va chercher à contourner ce problème en utilisant des dictionnaires d'attaque pré-calculés plus ou moins sophistiqués (par exemple les tables arc-en-ciel).

Le fait de devoir, pour l'attaquant, calculer autant de tables qu'il y a de salages possibles, en plus des tables de mots de passe du dictionnaire d'attaque, augmente mécaniquement le nombre de dictionnaires à utiliser. Même si le mot utilisé pour le salage est connu, le salage annule l'avantage de la table précalculée : la table précalculée est unique sur une base non salée. 1 table pour attaquer 1 base de N hash.

Le salage induit que l'équation devient 1 table pour attaquer 1 base de N hash ayant le même salage.

Avec un seul salage, la table n'est recalculée qu'une fois. Mais si tous les hashs sont salés aléatoirement, et même si le salage est connu, il faut recalculer chaque table arc-en-ciel pour chaque salage. L'équation devient (1 table pour attaquer 1 base de 1 hash avec un salage aléatoire unique pour ce hash) * N hash .

La technique du salage est donc la « contre-mesure » des tables de mots de passe recalculés (Il y a toujours moins de temps de calcul avec les dictionnaires d'attaques que sans, mais comme le nombre de dictionnaire augmente avec les possibilités de salage, le temps nécessaire pour casser le code redevient relativement prohibitif pour l'attaquant, par rapport à une attaque sur une base « non salée »).

Cassage d'une table de mots de passe[modifier | modifier le code]

Hors du cas évoqué précédemment, le salage n'apporte qu'un gain limité pour la protection d'un mot de passe d'utilisateur précis (il suffit à l'attaquant de concaténer le salage à chaque mot de son dictionnaire d'attaque avant de tester celui-ci). Le travail pour calculer 1 table pour attaquer 1 base de 1 hash est le même que 1 table pour attaquer 1 base de 1 hash avec un salage aléatoire unique pour ce hash.

Le salage améliore par contre la sécurité quand l'attaquant dispose d'une table de mot de passe de grande taille (comme c'est généralement le cas quand un système d'authentification est compromis).

Si chaque mot de passe de la table est haché sans salage ou avec un salage statique, l'attaquant ne devra générer qu'un seul dictionnaire sans salage ou avec le salage statique de la table des mots de passe respectivement, et comparer ce dictionnaire à la table des mots de passe. 1 table pour attaquer 1 base de N hash ayant le même salage

Si au contraire chaque mot de passe est haché avec un salage aléatoire différent, l'attaquant devra générer un dictionnaire pour chaque salage de la table des mots passe et comparer ces dictionnaires à la table des mots de passe, rendant le nombre de calculs prohibitif. (1 table pour attaquer 1 base de 1 hash avec un salage aléatoire unique pour ce hash) * N hash

Remarques[modifier | modifier le code]

La complexité de calcul ainsi induite demeure par essence relative, étant donné la nature intrinsèquement discrète des calculs et la dimension fondamentalement finie des données traitées avec un ordinateur ou un système informatique. Elle se mesure essentiellement en temps utile à consacrer au calcul et en espace de données candidates à parcourir de manière raisonnable pour le recouvrement de la donnée de départ.

Le salage est le plus souvent utilisé dans un contexte de sécurité de données (intégrité, contrôle d'accès, chiffrement). Dans d'autres cas d'utilisation de fonctions de hachage, aucun salage n'est appliqué, l'intérêt étant au contraire la catégorisation efficace des données de départ et la mise en correspondance rapide entre une empreinte et la donnée de départ.

Références[modifier | modifier le code]

  1. Guillaume Champeau, OVH victime d'un piratage massif de ses données clients Numérama.com, 22 juillet 2013, page consultée le 4 octobre 2013
  2. Emilien Ercolani, Ubisoft piraté : la base de données compromise, linformaticien.com, 3 juillet 2013, page consultée le 4 octobre 2013
  3. John Fontana, Password's rotten core not complexity but reuse, Zdnet.com, 22 mars 2013, consulté le 24 octobre 2013