Hasher un mot de passe semble naturel, mais utiliser directement SHA-256 ou une fonction rapide crée une illusion. Après une fuite de base, l’attaquant ne tente pas de “déhasher”. Il hash des mots de passe probables et compare. Plus la fonction est rapide, plus il peut essayer de guesses. Le hashing de mots de passe est volontairement coûteux pour changer cette économie.

L’attaque se fait hors ligne

Un formulaire de login peut limiter les tentatives, déclencher une MFA ou surveiller les abus. Une table de hashes volée supprime ces protections. L’attaquant travaille sur son matériel sans contacter l’application.

Les mots de passe humains ont une entropie limitée. La fonction one-way ne compense pas des entrées prévisibles si chaque essai coûte presque rien.

Le salt empêche la précomputation partagée

Un salt est une valeur aléatoire unique stockée avec chaque hash. Deux utilisateurs avec le même mot de passe obtiennent des valeurs différentes. Les tables précomputées générales deviennent beaucoup moins utiles.

Le salt n’a pas besoin d’être secret. Il doit être unique et généré correctement. Les bibliothèques modernes le créent et l’encodent dans le format stocké.

Les algorithmes spécialisés coûtent volontairement cher

Argon2, scrypt, bcrypt et PBKDF2 permettent de régler le coût. Argon2 et scrypt peuvent aussi consommer de la mémoire, ce qui réduit l’avantage du matériel massivement parallèle. Les paramètres doivent garder le login acceptable tout en augmentant le coût pour l’attaquant.

Répéter SHA-256 manuellement n’est pas équivalent à une construction revue. Les détails de conception comptent.

Les paramètres vieillissent

Le matériel progresse. Un hash stocké devrait contenir l’algorithme et les paramètres pour permettre la vérification ancienne et le rehash après un login réussi. Le système migre ainsi progressivement.

Les APIs de plateforme fournissent souvent une fonction pour savoir si un hash doit être mis à jour. Les utiliser évite un format maison fragile.

Le pepper est une couche optionnelle

Un pepper ajoute un secret côté serveur en plus du salt. Si seule la base fuit, l’attaquant n’a pas tous les éléments. Ce secret doit vivre dans un gestionnaire de secrets avec un plan de rotation.

Le pepper ne remplace pas l’algorithme fort. Il ajoute aussi un risque opérationnel: le perdre peut empêcher la vérification.

Les mots de passe ne doivent pas être récupérables

Si un service peut envoyer le mot de passe actuel, il le stocke en clair ou de manière réversible. Un système correct vérifie seulement un mot de passe soumis et utilise un reset token en cas d’oubli.

Les tokens de reset doivent être aléatoires, courts de durée, à usage unique et stockés prudemment. Les logs ne doivent jamais capturer de mots de passe.

La vérification ne doit pas aider l’énumération

Les réponses et timings ne devraient pas révéler si un compte existe. Certains systèmes exécutent un hash représentatif même pour les comptes inconnus. Le rate limiting doit tenir compte du compte, du réseau et des signaux d’abus.

La comparaison doit utiliser la fonction de la bibliothèque. Réimplémenter parsing et égalité ajoute des risques de timing et de compatibilité.

Les paramètres doivent être mesurés

Copier un coût depuis un autre projet est dangereux. Mesurez sur le matériel réel, avec concurrence réaliste. Un coût trop faible aide l’attaquant; un coût trop élevé peut devenir une surface de déni de service.

Les comptes administratifs et de service méritent le même traitement, avec MFA et contrôle de rotation. Un hash fort ne compense pas un secret partagé entre environnements.

La normalisation des mots de passe doit rester stable

Espaces, accents, caractères combinés et encodage doivent être traités de la même manière à l’inscription et à la connexion. Changer une règle de trimming ou de normalisation Unicode peut bloquer des utilisateurs légitimes. Les transformations cachées sur un secret sont dangereuses.

Si une politique de normalisation existe, elle doit être testée. Sinon, transmettez à la bibliothèque les bytes définis par le canal sans correction surprise.

Le reset ne doit pas laisser d’anciens accès

Après changement de mot de passe, le système doit décider quoi faire des sessions, refresh tokens et liens de récupération. Garder ces accès actifs peut annuler le bénéfice du nouveau secret. L’audit doit enregistrer l’événement sans jamais stocker le mot de passe.

Les notifications utilisateur aident aussi. Un message après changement de mot de passe ou reset permet de réagir rapidement si l’action n’était pas légitime. Le hashing protège la base; l’expérience de sécurité protège le compte.

Un bon hash achète du temps

Après une fuite, il faut invalider sessions, forcer reset si nécessaire, surveiller credential stuffing et communiquer clairement. Le hashing n’annule pas l’incident; il limite sa vitesse d’exploitation.

Ce temps doit être utilisé. Sans plan de réponse, même un excellent algorithme devient seulement une consolation technique.

La bonne séparation est simple: hashes rapides pour empreintes de données, password hashes pour résister au guessing. C’est une discipline de sécurité, pas un appel générique à une fonction.