Comment (ne pas) hacher un mot de passe

L’erreur la plus répandue : stocker SHA-256(mot de passe). C’est rapide… pour vous comme pour l’attaquant. Voici pourquoi, et quoi faire à la place.

Le problème : les hachages rapides sont trop rapides

SHA-256 est conçu pour être très rapide. Une carte graphique en calcule des milliards par seconde. Si votre base de mots de passe fuit, un attaquant teste tous les mots courants et toutes les combinaisons courtes en un rien de temps (voyez laforce brute). Un hachage rapide ne freine personne.

La solution : des fonctions lentes et salées

Les fonctions dédiées aux mots de passe sont volontairement lentes et paramétrables : on choisit un coût qui rend chaque essai coûteux. Elles intègrent aussi un sel.

• bcrypt : éprouvée, coût réglable ;
• Argon2id : recommandée aujourd’hui, coûteuse en mémoire ;
• scrypt : coûteuse en mémoire ;
• PBKDF2 : standard historique, très répandu.

Le sel : contre les tables précalculées

Le sel est une valeur aléatoire, différente pour chaque mot de passe, ajoutée avant le hachage. Deux personnes ayant le même mot de passe obtiennent des empreintes différentes. Surtout, le sel rend inutiles les tables précalculées (rainbow tables) : l’attaquant ne peut plus réutiliser un travail fait à l’avance. Le sel n’est pas secret ; il est stocké avec l’empreinte (les formats bcrypt/Argon2 l’incluent).

Le poivre : un secret côté serveur

Le poivre (pepper) est un secret global, identique pour tous, mais conservé hors de la base (dans la configuration du serveur, un module matériel…). Ainsi, une fuite de la seule base de données ne suffit pas : sans le poivre, les empreintes résistent. Sel et poivre sont complémentaires.

En résumé

• Jamais un simple SHA-256/MD5 pour un mot de passe.
• Une fonction lente et salée : Argon2id de préférence, sinon bcrypt/scrypt.
• Un sel unique par mot de passe (géré automatiquement par ces fonctions).
• Éventuellement un poivre, gardé à part.