Quand on monte une application web et qu’on stocke des identifiants, la première tentation est de hacher les mots de passe avec SHA-256, d’ajouter un sel et de passer à la suite. Sur le papier, ça tient. En production, c’est une erreur qui se paie cher le jour où la base fuit. Comprendre pourquoi demande de distinguer deux usages du hachage que l’on confond trop souvent.
SHA-256 pour stocker des mots de passe : un choix rapide, trop rapide
SHA-256 a été conçu pour être performant. Vérifier l’intégrité d’un fichier ISO, signer un certificat TLS, valider un bloc dans une chaîne de transactions : dans tous ces cas, on veut un hash calculé en quelques microsecondes. C’est exactement ce qui le rend dangereux pour le stockage de mots de passe.
A lire aussi : Stockage des mots de passe sur PC : emplacement et sécurité expliqués
Un attaquant qui récupère une base hachée en SHA-256 peut tester des milliards de combinaisons par seconde sur un GPU grand public. La vitesse de SHA-256 devient l’arme de l’attaquant, pas sa protection. Ajouter un sel rend les rainbow tables inutiles, mais ne ralentit pas la force brute sur un mot de passe ciblé.
On touche ici au malentendu central : le sel empêche la réutilisation de tables précalculées et garantit que deux utilisateurs avec le même mot de passe obtiennent des empreintes différentes. Il ne compense pas la rapidité de l’algorithme. Contre une attaque hors ligne, la seule parade réelle est un algorithme volontairement lent.
A découvrir également : Mot de passe perdu sur SOGo Lille : que faire étape par étape ?
Algorithmes mémoire-durs : bcrypt, scrypt et Argon2 face au brute force
Les fonctions comme bcrypt, scrypt ou Argon2 intègrent un paramètre de coût qui contrôle le temps de calcul par hash. Là où SHA-256 produit une empreinte quasi instantanément, bcrypt impose un facteur de travail réglable. Augmenter ce facteur d’un cran double le temps nécessaire pour chaque tentative.
Argon2, recommandé par le Password Hashing Competition, va plus loin. Il est qualifié de mémoire-dur : chaque calcul consomme une quantité configurable de RAM, ce qui complique le parallélisme massif sur GPU ou sur ASIC. On ne se contente plus de ralentir le processeur, on sature aussi la mémoire.
Le choix entre ces algorithmes dépend de la stack et des contraintes de latence. Sur un formulaire de connexion classique, viser un temps de hachage entre 200 et 500 millisecondes par tentative est un compromis courant. Les retours varient sur ce point selon la charge du serveur et l’expérience utilisateur tolérée, mais un hash de mot de passe qui prend moins de 10 ms est trop rapide.
Sel, poivre et paramètres de coût : les trois couches à combiner
Réduire la sécurité du stockage de mots de passe au seul salage, c’est oublier deux tiers du dispositif. Voici ce que chaque couche apporte concrètement :
- Le sel (salt) est une donnée aléatoire, unique par utilisateur et d’au moins 128 bits selon la recommandation CNIL. Il se stocke en clair à côté du hash. Son rôle : rendre chaque empreinte unique, même pour des mots de passe identiques, et neutraliser les rainbow tables.
- Le poivre (pepper) est un secret global stocké en dehors de la base de données, typiquement dans une variable d’environnement ou un coffre-fort de secrets. Si un attaquant exfiltre uniquement la base, il lui manque le poivre pour lancer ses calculs. C’est un complément, pas un substitut au sel.
- Le paramètre de coût (work factor, memory cost) contrôle la lenteur volontaire de l’algorithme. Il doit être réajusté périodiquement pour suivre l’augmentation de la puissance matérielle. Ce que bcrypt calculait en 300 ms en 2015 peut se faire en 50 ms aujourd’hui sur du matériel récent.
Ces trois éléments fonctionnent ensemble. Retirer l’un des trois affaiblit l’ensemble du dispositif. Un Argon2 sans sel perd sa résistance aux attaques par dictionnaire parallélisé. Un bcrypt avec sel mais sans poivre reste vulnérable si la base est le seul périmètre compromis.
SHA hashes et vérification d’intégrité : le bon usage de SHA-256
Dire que SHA-256 est mauvais serait un contresens. Il reste la référence pour tout ce qui touche à la vérification d’intégrité et à l’authentification de données.
Quand on télécharge un binaire depuis un dépôt officiel, le hash SHA-256 publié permet de confirmer que le fichier n’a pas été altéré en transit. Dans les systèmes de signature numérique, SHA-256 intervient pour produire un condensé du document avant chiffrement asymétrique. Dans les protocoles HMAC, il sert à authentifier des messages entre deux parties qui partagent un secret.
Dans ces scénarios, la vitesse de SHA-256 est un atout. On vérifie des milliers de signatures par seconde sans impact sur les performances. SHA-256 excelle partout où la vitesse de hachage est un avantage, c’est-à-dire partout sauf dans le stockage de mots de passe.
Mettre à jour le hachage des mots de passe sur une base existante
Migrer une base qui utilise SHA-256 vers bcrypt ou Argon2 ne nécessite pas de demander à chaque utilisateur de recréer son mot de passe. La méthode la plus courante consiste à appliquer le nouvel algorithme par-dessus le hash existant.
Concrètement, on prend le hash SHA-256 stocké et on le passe dans bcrypt avec un nouveau sel. À la prochaine connexion de l’utilisateur, on recalcule directement le hash Argon2 ou bcrypt depuis le mot de passe en clair, puis on remplace l’ancien enregistrement. Cette approche de migration progressive permet de basculer sans interruption de service.
Deux points à ne pas oublier pendant la transition :
- Conserver un marqueur dans la table pour distinguer les comptes déjà migrés de ceux qui utilisent encore le hash intermédiaire (bcrypt sur SHA-256).
- Planifier la montée du paramètre de coût lors de chaque mise à jour majeure de l’infrastructure, pour que le temps de hachage reste dans la fourchette cible malgré le matériel plus performant.
- Auditer les comptes inactifs depuis longtemps : s’ils ne se reconnectent jamais, leur hash ne sera jamais migré. Une politique d’expiration de compte résout ce cas.
La tendance actuelle pousse vers une actualisation régulière des paramètres de coût, pas uniquement lors d’une migration initiale. Un algorithme bien choisi avec des paramètres obsolètes finit par offrir le même niveau de protection qu’un algorithme faible.
Le duo SHA plus salage reste pertinent quand on parle d’intégrité de fichiers ou de signatures. Pour les mots de passe, le vrai duo opérationnel est un algorithme lent, un sel unique par compte, un poivre séparé et des paramètres de coût maintenus dans le temps. Quatre éléments, pas deux.
