Comprendre le cryptage : chiffrement, hachage & salage

Chiffrement

Comprendre le chiffrement

Le chiffrement est une méthode de transformation des données qui est réversible. Autrement dit, il est possible de chiffrer et de déchiffrer les données.

Elle repose sur :

• Une clé de chiffrement
• Un algorithme de chiffrement (AES, RSA, DES…)

Lors du chiffrement, la clé est couplée à l’algorithme pour chiffrer les données. En d’autres termes, la clé est utilisée comme un paramètre dans l’algorithme de chiffrement pour transformer les données d’origine en une forme chiffrée.

L’objectif premier du chiffrement est de rendre les données illisibles pour quiconque n’a pas la clé de déchiffrement appropriée. Le chiffrement est utilisé lorsqu’il y a une nécessité de décodage des données.

Une même clé de chiffrement peut être identique pour le chiffrement/déchiffrement, on parle alors de chiffrement symétrique.

À l’inverse, dans le cas d’un chiffrement asymétrique, deux clés distinctes sont utilisées : une clé publique pour chiffrer les données et une clé privée correspondante pour les déchiffrer. La clé publique peut être partagée largement, tandis que la clé privée doit rester secrète.

key = 2
alphaEncode("laConsole", key) // Retourne en sortie "ncEqptqng"
alphaDecode("ncEqptqng", key) // Retourne en sortie "laConsole"

Cas d’usage

Un bon exemple d’utilisation est celui des communications sécurisées sur Internet (via https), telles que les transactions bancaires en ligne, utilisent le chiffrement pour protéger les données sensibles en cas d’interception lors de leur transmission.

Hachage

Comprendre le hachage

À l’opposé du chiffrement, le hachage est une méthode de transformation unidirectionnelle. Autrement dit, il est impossible de déchiffrer les données.

Un algorithme de hachage (tel que bcrypt, MD5, SHA-256…) prend des données en entrée et génère une empreinte unique de taille fixe, appelée « hash ».

L’élément clé ici est que le processus de hachage est irréversible, ce qui signifie qu’il est en théorie impossible de retrouver les données d’origine à partir du hash. En théorie… Je m’explique.

Considérons le mot de passe 123456. Le hash généré via l’algorithme MD5 sera alors e10adc3949ba59abbe56e057f20f883e.

md5("123456") // Retourne en sortie "e10adc3949ba59abbe56e057f20f883e"

Si plusieurs utilisateurs utilisent ce mot de passe, alors tous auront le même hash en base de données.

Cas d’usage

Les systèmes d’authentification utilisent le hachage pour stocker de manière sécurisée les mots de passe. Au lieu de stocker les mots de passe en clair, les systèmes stockent leur hash correspondant.

Lors de la vérification d’un mot de passe saisi dans un champ de formulaire, le système compare simplement le hash stocké avec le hash généré à partir du mot de passe saisi.

Vulnérabilités

Les attaques traditionnelles (lorsque nous n’avons pas connaissance du hash) exploitent généralement :

• Des dictionnaires de données : consistant à automatiser via un script des tests successifs de mots de passe courants (admin, azerty, 123456…)
• La force brute : consistant à automatiser via un script des tests méthodiques et successifs de toutes les combinaisons de caractères possibles (a, b… z, aa, ab… az…)

Ces attaques s’effectuent généralement sur des champs de formulaire, par exemple un formulaire de connexion.

À ce niveau, la sécurité conférée par le hachage importe peu puisque les données ne sont pas compromises (le pirate n’en a pas connaissance).

En revanche, en cas de fuite de mots de passe, même hachés, suite au piratage d’un serveur de base de données, le hachage seul présente des limites en matière de sécurité.

Bien qu’unidirectionnel, le hachage n’est pas imparable puisqu’il n’offre pas de protection contre la rétro-ingénierie, telle que les attaques de type « Rainbow Table ». 🌈

Une Rainbow Table ou « Table Arc-en-ciel » est une table pré-calculée contenant une multitude de combinaisons de caractères, ainsi que leur correspondance dans un algorithme de hachage défini.

Ces tables générées en amont permettent généralement de limiter les ressources nécessaires, contrairement aux attaques par force brute qui requièrent beaucoup de temps et aux attaques par dictionnaires qui nécessitent beaucoup de mémoire.

Exemple simplifié de Rainbow Table pour l’algorithme MD5

Si un pirate parvient à voler des mots de passe hachés dans ce même algorithme, il va alors exécuter un script afin de rechercher pour chaque mot de passe volé, si une correspondance existe dans sa table.

Pour renforcer la sécurité et contrer les attaques par Rainbow Table, on recommande systématiquement l’utilisation complémentaire du salage.

Salage

Le salage (ou « salting » en anglais) est une pratique de sécurité qui consiste à ajouter des caractères au début ou à la fin d’un mot de passe (ou un autre type de texte, selon le besoin) avant de le hacher. Cette portion de caractères, appelée « sel » ou « salt » vient d’une certaine manière assaisonner notre mot de passe !

1. 🧂 Ajouter une pointe de sel
2. 🔪 Hacher le mot de passe en fines lamelles … Bientôt des tutos cuisine ici ! 🧑‍🍳

Le sel est lui aussi stocké de manière sécurisée sur un serveur. Il contribue grandement à la complexification du processus de décryptage d’un hash, ne correspondant plus au mot en clair, mais au mot salé.

Désormais, même si deux utilisateurs ont le même mot de passe, le sel les différencie et les hachages seront bel et bien distincts.

Imaginons deux utilisateurs, Camille et Arthur, ayant tous deux le mot de passe 123456.

Le salage avant hachage est aujourd’hui indispensable, car il présente 2 atouts considérables en termes de résistance aux attaques :

Chaînes identiques, hash différents

En l’absence de sel, les utilisateurs partageant le même mot de passe auraient des hachages identiques.

Le salage évite cette corrélation en introduisant une chaîne aléatoire unique dans le mot de passe avant hachage. La reconnaissance de mots de passe partagés n’est dès lors plus possible.

Résistance aux attaques par table arc-en-ciel

Le salage rend les attaques par Rainbow Table beaucoup moins efficaces.

Les hachages pré calculés pour des mots de passe connus ne tiennent pas compte du sel unique utilisé pour chaque utilisateur. Il faudrait donc que l’attaquant regénère ces tables en incluant tous les sels possibles… 😩

Le sel rallongeant la chaîne à hacher, il est peu probable que les Rainbow Tables contiennent les hash correspondants aux mots de passe complexes (exemple : 8yh!dTr-Ss895Ty2), non-issus de dictionnaire de données (admin, azerty, 123456…).