Stockage de mots de passe #2 : le salage

05 Apr 2020

Suite de l'article sur le stockage de mot de passe, à lire obligatoirement avant sinon ça risque d'être compliqué.
Nous allons voir cette fois le principe de l'opération de salage.

Actuellement, si deux utilisateurs utilisent le même mot de passe alors il est stocké avec un hash identique en base de données.
Egalement, à partir du hash le mot de passe peut éventuellement être retrouvé en testant tous les mots de passe courants.

C'est là qu'intervient le "sel" et l'opération de salage.

En plus du mot de passe, chaque utilisateur va se voir affublé d'un sel unique, chaine de caractères générée aléatoirement.
Ce sel sera ajouté au début ou à la fin du mot de passe et ensuite seulement le résultat sera transformé par la fonction de hachage.

Par exemple le mot de passe de Bob est password1234, le sel généré automatiquement par le système est Hç4[,t2+, la concaténation des deux donne : password1234Hç4[,t2+ et une fois passé dans la fonction de hachage on obtient le hash suivant : 4420d1918bbcf7686defdf9570bb5087d20076de
Si Charlie a aussi choisi le mot de passe password1234, le sel généré automatiquement parle système est 6é&t8U/5, la concaténation des deux donne : password12346é&t8U/5 et une fois passé dans la fonction de hachage on obtient le hash suivant :6fde9b7e35de1a6bd4bcb34953057abdddf334f6

Donc même si un pirate connait le mot de passe de Bob, il ne peut pas deviner que Charlie partage le même mot de passe en se basant sur son hash.

L'autre avantage est que même si le pirate connait le hash et le sel utilisé, il ne peut pas utiliser les rainbow table (basées uniquement sur les mots de passe courants). Ou il doit tout recalculer ce qui lui prendrait un temps très long et beaucoup de ressources.

Voilà, c'est tout sur le stockage de mots de passe.
Maintenant que l'on a vu la théorie, je vais faire un article (ou plusieurs, je ne sais pas encore), sur les méthodes utilisées par les pirates, dans la vie réelle, pour récupérer les mots de passe.