Stocker un mot de passe

Un site ne doit jamais stocker les mots de passe en clair. Le jour où sa base fuite — et cela arrive — tous les comptes tombent, y compris sur les autres sites où les gens ont réutilisé le même mot de passe.

La première idée : hacher

On stocke l'empreinte, pas le mot de passe. À la connexion, on hache ce qui est saisi et on compare.

Le site peut donc vérifier un mot de passe sans jamais le connaître. Une fuite de la base ne livre que des empreintes.

Pourquoi ça ne suffit pas

Un attaquant précalcule les empreintes des mots de passe courants — des milliards — et compare. Ce sont les tables arc-en-ciel.

Pire : deux personnes ayant le même mot de passe ont la même empreinte. La fuite révèle donc qui partage un mot de passe avec qui.

Le sel

On ajoute à chaque mot de passe une valeur aléatoire unique, le sel, stockée à côté de l'empreinte :

empreinte = H(sel + mot_de_passe)

Conséquences : deux mots de passe identiques donnent des empreintes différentes, et une table précalculée devient inutile — il faudrait en refaire une par sel.

Le coût de calcul

Il reste un problème : SHA-256 est rapide. Une carte graphique en teste des milliards par seconde.

Pour les mots de passe, on veut donc l'inverse d'une fonction rapide. Les algorithmes dédiés — bcrypt, argon2 — sont délibérément lents et gourmands en mémoire, avec un coût réglable.

Un utilisateur légitime attend 100 millisecondes à la connexion : imperceptible. Un attaquant qui teste des milliards de possibilités voit son travail multiplié par un million.

À retenir : pour les mots de passe, on n'utilise pas SHA-256 seul, mais bcrypt ou argon2. La lenteur est ici une fonctionnalité.