Audit du stockage des mots de passe : hachage, salage et migration sûre

Ce que vérifie un audit du stockage des mots de passe (et pourquoi ça compte)

Un bon stockage des mots de passe revient à une chose simple : si quelqu'un vole votre base d'utilisateurs, il ne doit pas pouvoir réutiliser ces mots de passe.

Votre appli ne doit jamais stocker les mots de passe en texte clair. Elle doit enregistrer un hachage à sens unique, lent à deviner, unique par utilisateur, et conçu pour pouvoir être amélioré au fil du temps.

Un audit du stockage des mots de passe vérifie toute la chaîne, pas seulement l'écran de connexion. Dans du code hérité (surtout généré rapidement par des outils IA), les logins peuvent sembler fonctionner alors que le stockage est dangereux. Un prototype peut hacher les mots de passe avec une fonction rapide, réutiliser le même sel, ou enregistrer des secrets par erreur lors du debug. Rien de tout cela ne casse le chemin heureux, mais ça transforme une fuite de données en vague de prises de comptes.

Si des attaquants obtiennent des hachages faibles, ils peuvent lancer des attaques hors ligne. Ils n'ont pas besoin d'atteindre vos serveurs ni de déclencher des limites de taux. Ils essayent des hypothèses sur leurs propres machines jusqu'à trouver des correspondances. Une fois qu'ils craquent un mot de passe, ils essaient souvent de l'utiliser ailleurs, car les gens réutilisent les mots de passe.

Un bon stockage inclut généralement :

• Un algorithme moderne et lent adapté aux mots de passe (pas un hash généraliste comme MD5 ou SHA-1).
• Un sel aléatoire unique par mot de passe, stocké avec le hachage.
• Optionnellement un pepper : un secret séparé conservé hors de la base.
• Une version claire du schéma pour pouvoir changer les réglages sans casser les logins.
• Aucune exposition accidentelle (logs, analytics, messages d'erreur, sauvegardes).

La séquence la plus sûre est : auditer d'abord, migrer ensuite. L'audit identifie ce que vous avez aujourd'hui (algorithme, paramètres, où se trouve le code, comment fonctionnent les réinitialisations), puis vous choisissez un plan d'amélioration.

Un plan courant est le « ré-hachage à la prochaine connexion » : les utilisateurs continuent de se connecter normalement, et quand un mot de passe est vérifié avec succès, vous mettez à jour son hachage vers le nouveau standard.

Signaux d'alerte à repérer rapidement dans du code hérité

Il n'est pas nécessaire de tout réécrire pour trouver les plus gros risques. Un audit rapide commence souvent par des recherches simples qui révèlent si les mots de passe sont stockés ou traités de façon dangereuse.

Le signal d'alerte le plus urgent est tout ce qui suggère que les mots de passe peuvent être récupérés. Si vous voyez des mots de passe enregistrés directement dans une colonne de la base, loggés sur la console, envoyés à de l'analytics, ou « encryptés » avec quelque chose de réversible (comme AES avec la clé stockée), considérez cela comme un incident. Les mots de passe doivent être stockés uniquement sous forme de hachages à sens unique.

Un autre problème courant est l'utilisation de hachages rapides. Vous pouvez voir MD5, SHA-1, ou SHA-256 appliqués directement au mot de passe. Même si c'« a l'air haché », les hachages rapides sont conçus pour la vitesse, ce qui les rend faciles à craquer à grande échelle. Si le code dit hash(password) et rien d'autre, c'est un fort indice qu'il n'utilise pas correctement une fonction de hachage adaptée aux mots de passe.

Vérifications rapides qui attrapent beaucoup des pires problèmes :

• Mentions de md5, sha1, sha256(password), ou d'aide-méthodes "encryptPassword".
• Sorties de hachage qui ont toujours la même longueur et le même format, sans signe d'un sel par utilisateur.
• Mots de passe ou tokens de réinitialisation apparaissant dans les logs, rapports d'erreur ou dumps de base.
• Secrets (clés JWT, mots de passe de DB, PEPPER=...) codés en dur dans le repo ou les configs commités.
• Code de login qui n'accepte qu'un seul format de hachage et n'a aucune voie d'évolution.

Un salage manquant ou incorrect est subtil mais facile à repérer quand on sait quoi chercher. Si deux utilisateurs avec le même mot de passe ont la même valeur stockée, le système utilise probablement aucun sel, un sel global, ou un sel prédictible. Une configuration saine produit des résultats stockés différents même pour des mots de passe identiques.

Exemple concret : vous héritez d'une app Node et trouvez une colonne users.password pleine de chaînes hex de 64 caractères. Le gestionnaire de login fait sha256(req.password) et compare au stockage. Ça « fonctionne », mais c'est vulnérable, et cela ne vous donne aucun moyen sûr d'améliorer la sécurité sans prévoir plusieurs formats de hachage.

Enfin, vérifiez si le flux de connexion peut gérer le changement. Si le code ne sait pas vérifier des hachages legacy puis ré-hacher avec une méthode plus forte à la connexion suivante, les upgrades deviennent risqués et peuvent mener à des verrouillages de comptes.

Cartographier où les mots de passe et les flux de réinitialisation sont gérés

Un audit va plus vite quand vous commencez par une carte simple : chaque endroit où un mot de passe ou un token de réinitialisation est créé, envoyé, traité ou stocké. Dans du code hérité, les parties risquées ne sont souvent pas dans un dossier « auth ». Elles sont dispersées dans les formulaires UI, les routes API, les jobs en arrière-plan et les outils admin.

Commencez par lister chaque point d'entrée où un mot de passe peut entrer dans le système, puis confirmez chacun dans le code et dans les configs de production. Lieux courants : flux d'inscription, login (y compris chemins de secours SSO), réinitialisation et récupération de mot de passe, outils admin/support, et imports ou migrations (uploads CSV, synchronisation CRM, scripts de seed).

Ensuite, localisez où les données liées aux mots de passe résident en base. Vérifiez les colonnes évidentes comme password, password_hash, hashed_password, mais aussi les tables legacy et les copies fantômes (par exemple une ancienne table users_legacy toujours lue par un job en arrière-plan). Si vous trouvez plusieurs champs de hachage, notez lequel est réellement utilisé au login.

Les logs sont une fuite commune. Cherchez dans le code et la config de monitoring tout ce qui pourrait capturer des valeurs sensibles : logs de requêtes, événements analytics, rapports d'erreur, prints de debug. Un mode d'échec réaliste : un gestionnaire d'échec de login logge le corps complet de la requête « pour le dépannage », expédiant silencieusement des mots de passe en clair dans les logs.

Les réinitialisations méritent leur propre mini-carte car les tokens se gèrent mal facilement. Identifiez comment les tokens sont générés (source d'aléa), où ils sont stockés (ligne DB, cache, payload du lien email), et comment ils expirent. Vérifiez aussi s'ils sont à usage unique, et que se passe-t-il si un token est rejoué après un changement de mot de passe.

Enfin, tracez la frontière du service. Notez chaque composant qui touche l'auth : client frontend, API gateway, service auth, workers (email, SMS), et tout fournisseur d'identité tiers. Dans les projets générés par IA, on trouve souvent des endpoints d'auth en trop laissés après des itérations, incluez donc les anciennes routes et les feature flags désactivés dans votre scan.

Vérifier l'algorithme de hachage et ses réglages

Un audit du stockage commence par une question directe : utilisez-vous une fonction de hachage pour mots de passe, ou un hash généraliste ?

Si vous voyez MD5, SHA-1, SHA-256, ou n'importe quoi présenté comme "encrypt password", considérez cela comme un problème sérieux. Ces outils ne sont pas conçus pour ralentir un attaquant.

Préférez des hachages dédiés aux mots de passe comme Argon2id, bcrypt ou scrypt. Ils sont conçus pour être coûteux à casser, donc des hachages volés sont plus difficiles à convertir en mots de passe réels.

Comment déduire l'algorithme à partir du hachage stocké

La plupart des systèmes stockent l'algorithme et les paramètres dans la chaîne de hachage, donc un coup d'œil rapide sur une valeur en base peut vous en dire beaucoup.

Schémas courants :

• Argon2id commence souvent par $argon2id$ et inclut la mémoire et les itérations.
• bcrypt commence souvent par $2a$, $2b$ ou $2y$ et inclut un coût comme 10 ou 12.
• scrypt peut montrer $scrypt$ ou des paramètres N, r, p selon la librairie.

Si vous voyez une chaîne hex de longueur fixe (par ex. 32 ou 64 hex) sans séparateurs $, il peut s'agir d'un hash généraliste ou d'un schéma personnalisé qui nécessite une revue approfondie.

Vérifiez les réglages, pas seulement le nom

Le choix d'algorithme n'est que la moitié de l'histoire. Argon2id peut être faible si la mémoire allouée est minuscule. bcrypt peut être faible si le coût est bas.

Cherchez où le facteur de travail est défini, et si vous pouvez le changer sans redeployer. Les installations plus saines gardent les paramètres de coût en config, utilisent la méthode verify intégrée de la librairie (pas une comparaison de chaînes manuelle), et comparent en temps constant.

Confirmez aussi que le point de connexion a des défenses de base : limitation de taux par compte et par IP, et règles de verrouillage sensées. Des verrouillages temporaires et courts sont souvent plus sûrs que des blocages permanents.

Vérifier le salage : unicité, stockage et aléa

Un audit doit confirmer une règle : chaque hachage de mot de passe doit avoir son propre sel unique et aléatoire.

Si deux utilisateurs choisissent le même mot de passe, leurs hachages stockés doivent quand même être différents. Si ce n'est pas le cas, quelque chose cloche.

Unicité : un sel par mot de passe, sans exception

Les sels empêchent l'usage de tables précomptées et rendent le craquage en masse beaucoup plus difficile. Cela ne marche que si les sels ne sont pas réutilisés.

Un problème courant dans le code hérité est un sel unique codé en dur dans un fichier de config ou un « sel par défaut » réutilisé pour tous les utilisateurs. Un contrôle de sanity simple : prélevez un petit échantillon de hachages (20 à 50) et voyez s'ils partagent un segment de sel identique ou un préfixe répétitif qui suggère une réutilisation. Si vous trouvez de la répétition, traitez-le comme un bug de sécurité.

Stockage : sel intégré au hachage vs colonne séparée

Beaucoup de formats modernes stockent le sel dans la chaîne de hachage elle-même. Par exemple, bcrypt et Argon2 incluent souvent l'algorithme, les paramètres, le sel et le hachage en un seul champ. C'est normal.

Certaines implémentations stockent le sel dans une colonne séparée à côté du hachage. Ça peut aussi convenir, tant que le sel est vraiment par-utilisateur et n'est pas nullable ou par défaut un valeur partagée. Le risque avec une colonne séparée est la réutilisation accidentelle via des migrations, des valeurs par défaut d'ORM ou des scripts de seed.

Contrôles pratiques qui détectent la plupart des problèmes :

• Confirmer que chaque utilisateur a une valeur de sel différente (ou un sel intégré différent dans la chaîne de hachage).
• Vérifier que les sels sont générés lors du set ou reset du mot de passe, pas au démarrage de l'app.
• S'assurer que la longueur du sel correspond aux attentes de l'algorithme.
• Vérifier que le code utilise une source d'aléa cryptographique.
• Éviter les formats de sel custom qui concatènent des chaînes manuellement.

L'aléa compte autant que l'unicité. Si le sel provient de sources prévisibles (timestamps, noms d'utilisateur, IDs incrémentaux), les attaquants peuvent le deviner.

Un mode d'échec réaliste dans des prototypes générés par IA est un helper comme salt = Math.random().toString(36) ou un SALT="abc" copié dans plusieurs fichiers. Ça paraît aléatoire, mais ce n'est pas sécurisé.

Si vous devez changer la façon dont les sels sont générés ou stockés, faites-le de manière à ce que les utilisateurs existants puissent toujours se connecter normalement, puis migrez leurs hachages en toute sécurité à la prochaine connexion réussie.

Décider du pepper et comment stocker le secret en sécurité

Un pepper est une valeur secrète ajoutée au mot de passe avant le hachage. Contrairement au sel (unique par utilisateur et stocké avec le hachage), le pepper est partagé entre de nombreux utilisateurs et doit être conservé uniquement sur le serveur.

Le pepper est utile surtout si vous craignez une fuite de la base et un craquage hors ligne. Il est particulièrement pertinent dans des apps héritées où vous ne faites pas entièrement confiance au code généré ou si des secrets ont déjà pu être exposés.

Le pepper peut se retourner contre vous si vous le traitez comme une chaîne de config normale. Si le pepper fuit (codé en dur dans le repo, imprimé dans des logs, copié dans une app cliente), vous n'avez pas gagné en sécurité et vous avez ajouté un risque. Il peut aussi provoquer une panne si un déploiement supprime ou change le pepper : soudainement personne ne peut se connecter.

Stockez le pepper comme un vrai secret :

• Gardez-le hors de la base et hors du contrôle de source.
• Chargez-le depuis des variables d'environnement ou un gestionnaire de secrets fourni par votre hébergeur.
• Limitez l'accès aux seules personnes et services qui en ont besoin.
• Ne l'envoyez jamais au navigateur ou à l'app mobile.
• Évitez de logger quoi que ce soit qui puisse le révéler (même partiellement).

Prévoyez la rotation avant le déploiement. Faire tourner un pepper est plus compliqué que faire tourner une clé API car cela affecte chaque vérification de mot de passe.

L'approche la plus sûre est de supporter deux peppers pendant une fenêtre de rotation : acceptez l'ancien et le nouveau pepper, puis migrez progressivement. À la connexion, vérifiez d'abord avec le nouveau pepper. Si ça échoue, vérifiez avec l'ancien. Si l'ancien fonctionne, ré-hachez et enregistrez avec le nouveau pepper. Cela permet une rotation sans forcer de réinitialisations massives.

Documentez qui peut voir ou changer le pepper, où il est défini dans chaque environnement, et quel est le plan de rollback si un déploiement casse les connexions.

Pas à pas : migrer les hachages en toute sécurité à la prochaine connexion

Un plan sûr de « ré-hachage à la prochaine connexion » vous permet d'accepter les mots de passe existants, puis d'améliorer le stockage sans demander une réinitialisation massive. C'est une des corrections à fort impact car elle réduit rapidement le risque sans interrompre les utilisateurs.

1) Détecter si un hachage stocké est legacy ou moderne

Rendez la valeur en base auto-descriptive. La plupart des formats de hachage modernes le sont déjà. Par exemple, bcrypt commence souvent par $2a$ ou $2b$, et Argon2 par $argon2id$.

Si votre système legacy utilisait quelque chose de custom (comme sha1(salt+password)), ajoutez une colonne explicite hash_version pour savoir comment vérifier.

2) Vérifier avec la méthode legacy seulement si nécessaire

Au login, vérifiez d'abord le format/version stocké. Si c'est moderne, vérifiez normalement. Si c'est legacy, exécutez uniquement le vérificateur legacy pour cet utilisateur.

Surveillez le « double hachage » (hacher le mot de passe entrant avant de le passer au vérificateur). Assurez-vous que le vérificateur reçoit la chaîne brute exactement une fois.

3) Ré-hacher avec le nouvel algorithme et écraser en cas de succès

Si la vérification legacy réussit, ré-hachez immédiatement avec votre nouveau choix et les paramètres actuels (par exemple Argon2id ou bcrypt avec un coût plus élevé) et écrivez-le au format moderne.

Gardez la mise à jour atomique et liée à l'ID utilisateur pour éviter les courses entre deux connexions. Une approche simple : « vérifier d'abord, puis mettre à jour le hachage et hash_version en une seule écriture. »

if verify(password, stored_hash, version) == true:
  new_hash = hash_new(password)
  update users set password_hash = new_hash, hash_version = "v2" where id = user_id
  allow_login()
else:
  deny_login()

Exemple concret : vous héritez d'un prototype qui utilisait SHA-1 sans sel plus un secret global. Vous conservez ce vérificateur uniquement pour valider les comptes anciens. Après la première connexion réussie, la ligne est migrée vers Argon2id, et les logins futurs n'utilisent plus SHA-1.

4) Ajouter de l'observabilité sans exposer de secrets

Suivez l'avancement et les problèmes, mais ne loggez jamais de mots de passe ni de hachages complets. Loggez seulement des compteurs et des résultats sûrs, tels que : connexions legacy réussies (ré-hachage effectué), connexions legacy échouées, connexions modernes réussies/échouées, nombre d'utilisateurs encore en format legacy, et erreurs de ré-hachage (écriture échouée, mismatch de version).

Erreurs de migration courantes qui verrouillent les utilisateurs

Une mise à jour de hachage devrait être invisible pour les utilisateurs. La plupart des verrouillages surviennent quand la migration change le comportement, pas la sécurité.

Une grosse erreur est d'exiger une réinitialisation sans plan. Si vous invalidez tous les hachages existants, les gens qui n'ont plus accès à leur ancien email (ou qui utilisent SSO parfois) se retrouvent bloqués. Si vous devez forcer des réinitialisations après une fuite, prévoyez quand même une voie de secours, des messages clairs et du support pour les cas limites comme les emails non vérifiés.

Un autre piège courant est de mettre à jour les hachages sur des tentatives de login échouées. Sur un mauvais mot de passe, vous ne connaissez pas le plaintext correct, donc vous ne pouvez pas ré-hacher quoi que ce soit en toute sécurité. Pire, certains codes écrasent le hachage stocké avec des données dérivées de l'entrée incorrecte, verrouillant le compte même si l'utilisateur tape le bon mot de passe ensuite.

Les changements de normalisation des mots de passe peuvent aussi casser silencieusement les connexions. De petites différences comme couper les espaces, changer les règles de casse, ou modifier la gestion Unicode peuvent faire que le même mot de passe produit un hachage différent qu'avant. Exemple réaliste : une app héritée tronquait les espaces finaux à l'inscription mais pas au login. Après une réécriture, les deux côtés ont commencé à tronquer, et certains utilisateurs qui utilisaient volontairement un espace final ne pouvaient plus se connecter.

Enfin, faites attention aux connexions concurrentes et aux conditions de course pendant le ré-hachage. Si deux appareils se connectent en même temps, les deux peuvent tenter d'améliorer le hachage. Si votre mise à jour n'est pas atomique, une requête peut écraser l'autre, ou échouer d'une façon qui laisse le compte incohérent.

Checklist courte pour éviter les blocages :

• Ne ré-hachez qu'après une vérification de mot de passe réussie.
• Conservez exactement les mêmes règles de normalisation pendant la migration.
• Stockez le pepper uniquement côté serveur, jamais dans le code client.
• Rendez la mise à jour du hachage atomique (une écriture, protégée par le hachage courant attendu).
• Loggez et alertez sur les échecs de migration sans bloquer les logins valides.

Vérifications rapides avant de déployer les changements

Avant de publier des modifications liées aux mots de passe, faites un passage pratique qui attrape les erreurs ressenties immédiatement par les utilisateurs : logins échoués, réinitialisations cassées, et fuites accidentelles dans les logs.

Testez le flux de login et de ré-hachage avec des entrées réelles et bord-case. Ne comptez pas sur un seul compte en chemin heureux. Essayez des mots de passe très longs (200+ caractères), Unicode, de vieux comptes qui n'ont pas été utilisés depuis des mois, et des utilisateurs créés par différents chemins (inscription, import admin, OAuth puis définition d'un mot de passe). Confirmez que les erreurs « mauvais mot de passe » sont génériques et cohérentes et ne révèlent pas si un compte existe.

Les réinitialisations méritent une vérification séparée car le code hérité stocke souvent des tokens en clair. Traitez les tokens comme des mots de passe : stockez seulement un hachage du token, et comparez en hachant ce que l'utilisateur soumet. Vérifiez que les tokens expirent comme prévu, qu'ils sont à usage unique, et qu'ils ne peuvent pas être rejoués. Un scénario simple : demandez deux réinitialisations de suite, utilisez le premier token, puis confirmez que le second ne fonctionne plus.

Ne publiez pas sans plan de rollback. Prenez une sauvegarde fraîche et notez exactement comment revenir en arrière si les logins explosent ou si les tickets support affluent. Confirmez aussi que la mise à jour "ré-hachage à la prochaine connexion" se comporte en sécurité si elle échoue à mi-chemin (par ex. le mot de passe est vérifié mais l'écriture en base échoue). Les utilisateurs doivent pouvoir se reconnecter à la tentative suivante.

Enfin, faites un contrôle d'abus de base. Ajoutez des limites de taux sur les endpoints de login et de reset, et assurez-vous que les motifs suspects sont signalés (beaucoup de tentatives, nombreuses demandes de reset, échecs répétés depuis une même IP). Passez en revue les logs et le tracking d'erreurs : ils ne doivent jamais contenir de mots de passe bruts, de tokens de réinitialisation, ou d'en-têtes d'autorisation complets, même en mode debug.

Étapes suivantes : faire l'audit et durcir le code hérité généré par l'IA

Si vous avez hérité d'une app générée par IA, traitez l'authentification comme le point le plus rapidement dangereux. Un audit du stockage des mots de passe est souvent la manière la plus rapide de trouver des problèmes menant à des prises de comptes.

Un motif commun est un prototype livré avec une auth bricolée : paramètres de hachage faibles, secrets codés en dur, et un flux de reset qui peut être abusé. L'app marche bien en démo, mais elle n'est pas sûre en production.

Priorisez dans un ordre sensé. D'abord, retirez les secrets exposés, bloquez toute logique de login de secours dangereuse, et corrigez les chemins d'injection évidents autour des endpoints d'auth. Ensuite migrez les utilisateurs progressivement pour ne pas forcer des réinitialisations massives.

Si vous voulez un expert pour revoir et corriger vite, préparez l'accès au repo (ou un export propre), la branche que vous comptez déployer, un moyen d'exécuter l'app localement (vars d'env, DB de test), quelques comptes de test (dont un legacy si vous avez d'anciens hachages), et des notes sur où se trouvent les secrets aujourd'hui (config d'hébergement, fichiers env, CI).

Si vous traitez un codebase hérité généré par IA et que vous ne savez pas ce qui est réellement stocké, FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation d'apps construites par IA, y compris la logique d'auth, la gestion des secrets, et des migrations sûres de type « ré-hachage à la prochaine connexion ». Ils proposent un audit gratuit du code pour identifier les problèmes avant que vous ne commitiez, avec la plupart des projets livrés en 48–72 heures.

Un état « terminé » clair aide à garder le travail ciblé :

• Les nouveaux mots de passe utilisent toujours le hachage et les paramètres approuvés.
• Les logins réussis migrent automatiquement les hachages legacy.
• Les flux de reset et de changement de mot de passe sont testés et limités en taux.
• Aucun mot de passe en clair, pas d'encryption réversible, pas de secrets exposés.
• Le nombre de hachages legacy tend vers zéro au fur et à mesure que les utilisateurs actifs se connectent.

Si vous connaissez le nom de votre méthode de hachage actuelle mais pas ses paramètres, ou si vous ignorez combien d'utilisateurs restent en legacy, c'est un signe pour faire une pause et auditer avant la prochaine release.