Hash mot de passe : bcrypt, Argon2 et bonne politique

Hash mot de passe : comment stocker les identifiants de vos clients avec bcrypt ou Argon2, quelle politique adopter et quels pièges éviter sur votre site.

Le hachage des mots de passe, expliqué simplement

Une fonction de hachage prend un texte et en tire une chaîne de longueur fixe. Sens unique. Impossible, à partir du hash, de remonter au mot de passe d'origine. Comment le site vérifie-t-il alors votre saisie ? Il hache ce que vous venez de taper et compare le résultat à l'empreinte qu'il a conservée.

Là se joue toute la différence avec le chiffrement. Quiconque détient la clé peut déchiffrer une donnée chiffrée : qu'un pirate emporte la base et la clé, et il lit tout. Un hachage bien conçu, lui, n'a aucune clé à dérober. C'est pourquoi je le répète à chaque client : un mot de passe se hache, il ne se chiffre pas.

Pourquoi un hash rapide ne suffit pas

MD5 et SHA-1 ont été pensés pour la vitesse. Parfait pour contrôler un fichier. Désastreux pour des identifiants. Sur ces algorithmes, une carte graphique ordinaire teste des milliards de combinaisons chaque seconde, si bien qu'une attaque par force brute contre une base en MD5 retrouve en peu de temps les mots de passe courts ou banals.

Le sel : un ingrédient unique par compte

Avant le hachage, on ajoute au mot de passe une valeur aléatoire, propre à chaque compte : le sel. Résultat, deux clients qui ont choisi le même mot de passe obtiennent des hashs différents. Et les tables précalculées, ces gigantesques dictionnaires d'empreintes prêtes à l'emploi ? Elles deviennent inutiles. Bonne nouvelle, vous n'avez rien à faire : bcrypt et Argon2 génèrent le sel eux-mêmes et l'intègrent au résultat.

Bcrypt ou Argon2 : quel algorithme choisir ?

Même principe des deux côtés : calculer un hash doit coûter cher. Assez peu pour passer inaperçu lors d'une connexion normale, beaucoup trop pour des milliards d'essais. Ce coût se règle. Beaucoup oublient pourtant de le relever à mesure que les serveurs gagnent en puissance.

L'algorithme bcrypt, la valeur sûre

Né en 1999, bcrypt tient toujours la route. On le trouve dans presque tous les langages, frameworks et CMS. Un seul paramètre à régler, le facteur de coût : chaque point supplémentaire double le temps de calcul. Une limite mérite d'être connue, puisque seuls les 72 premiers octets du mot de passe sont pris en compte. Sur un site de PME, je n'ai pratiquement jamais vu cela poser problème.

Argon2id, le choix recommandé pour un projet neuf

Vainqueur de la Password Hashing Competition en 2015, Argon2 se décline en plusieurs variantes. L'OWASP, référence mondiale de la sécurité web, recommande aujourd'hui Argon2id. Pourquoi lui ? Parce qu'il réclame du temps de calcul mais aussi de la mémoire, ce qui rend bien moins efficaces les attaques menées avec des puces spécialisées. On l'ajuste sur la mémoire, le nombre de passes et le parallélisme.

  • Projet neuf sur un hébergement récent ? Choisissez Argon2id.
  • Outil existant en bcrypt avec un coût correct : ne touchez à rien, il fait très bien son travail.
  • Base en MD5, SHA-1 ou SHA-256 sans sel : migration prioritaire.
  • Mots de passe en clair ou chiffrés de manière réversible : urgence absolue, à régler cette semaine.

Les étapes pour stocker les mots de passe de vos clients

Nouveau site ou audit d'un outil existant, l'ordre reste le même. À chaque étape, vous fermez une porte que des acteurs malveillants pourraient pousser.

1. Utiliser les fonctions natives du langage

Première règle, non négociable : on ne code jamais sa propre cryptographie. En PHP, password_hash() avec PASSWORD_DEFAULT produit du bcrypt ; avec PASSWORD_ARGON2ID, de l'Argon2id. La comparaison ? password_verify() s'en charge. Node.js, Python, Java, .NET et WinDev proposent eux aussi des bibliothèques ou des fonctions conçues pour cela. WordPress est passé à bcrypt avec sa version 6.8. Sous Linux, enfin, le fichier /etc/shadow des distributions récentes repose sur yescrypt, un algorithme de la même famille.

2. Ne stocker que le hash

Dans la base de données, une colonne suffit pour le mot de passe. Elle contient le hash complet, algorithme, coût et sel compris. Le mot de passe brut ne doit traîner nulle part ailleurs : ni dans les logs, ni dans un e-mail de bienvenue, ni dans un export Excel. Mon conseil ? Prévoyez une colonne assez longue pour absorber les formats de demain.

3. Passer de MD5 à bcrypt sans réinitialiser tous les comptes

Forcer toute votre clientèle à changer de mot de passe serait inutile. Deux méthodes s'offrent à vous. La première rehache le mot de passe lors de la connexion réussie suivante ; en PHP, password_needs_rehash() repère les hashs à mettre à jour. La seconde enveloppe immédiatement les anciens MD5 dans bcrypt, ce qui couvre aussi les comptes dormants. Je recommande de combiner les deux.

4. Freiner les tentatives de connexion

Le meilleur hachage protège une base volée, pas votre page de connexion. Limitez donc les essais par compte et par adresse IP. Allongez le délai après chaque échec. Gardez un œil sur les connexions inhabituelles. Le détail de ces défenses figure dans les ressources sur l'OWASP Top 10.

Quelle politique de mots de passe adopter ?

Caractère spécial obligatoire, renouvellement tous les trois mois : ces règles d'autrefois ont montré leurs limites. Qui n'a jamais vu passer Motdepasse1! puis Motdepasse2! ? Le NIST américain et la CNIL misent désormais d'abord sur la longueur et sur le rejet des mots de passe déjà compromis.

  • Une longueur minimale suffisante, autour de 12 caractères, et un plafond généreux pour laisser passer les phrases de passe.
  • Le rejet de tout mot de passe présent dans des listes de fuites connues.
  • Pas de changement imposé à date fixe, sauf soupçon de compromission.
  • Le copier-coller autorisé, sans quoi les gestionnaires de mots de passe ne servent à rien.
  • La double authentification proposée à chacun, obligatoire pour les accès d'administration.

Mot de passe oublié ? Envoyez un lien à usage unique, valable peu de temps, et jamais le mot de passe lui-même. Un site capable de vous renvoyer le vôtre avoue, sans le dire, qu'il le conserve de façon réversible.

Les attaques “pass-the-hash” et les autres pièges

Hacher ne règle pas tout. Sur un réseau Windows ou Active Directory, les attaques “pass-the-hash” rejouent directement un hash volé pour s'authentifier, sans que l'attaquant connaisse jamais le mot de passe. Il extrait le hash NTLM d'un poste compromis, puis rebondit vers d'autres machines. La parade ? Réduire le nombre de comptes administrateurs, leur interdire de se connecter n'importe où et activer les protections intégrées à Windows.

Côté site web, ce sont souvent d'autres failles qui exposent des identifiants pourtant correctement hachés. Une injection, une extension restée sans mise à jour, un poste de travail infecté : il n'en faut pas plus. Pour passer ces points en revue d'un coup, servez-vous de la checklist sécurité de votre site web.

  • Hacher dans le navigateur au lieu du serveur : le hash devient de fait le vrai mot de passe.
  • Réutiliser le même sel pour tous les comptes.
  • Laisser traîner des mots de passe dans les journaux d'erreurs ou les outils de suivi.
  • Conserver en production des comptes utilisateur de test aux identifiants faibles.
  • Ne plus toucher au facteur de coût pendant des années.

Le rôle de vos partenaires et du support

Rares sont les PME qui développent elles-mêmes leur authentification : un CMS, un SaaS ou une agence s'en charge. Exigez une réponse écrite. Quel algorithme, quel réglage, qui assure les mises à jour ? Un partenaire sérieux répond sans hésiter et vous décrit la réaction de son support en cas d'incident. Et si le pire arrive malgré tout, le guide site piraté : que faire liste les gestes des premières heures.

Combien coûte une authentification bien sécurisée ?

Pas de tarif standard. Tout dépend de l'existant. Un outil récent, bâti sur un framework sérieux, intègre déjà un hachage correct, et une simple vérification suffit. Un vieux logiciel avec une base en MD5, c'est une autre histoire : migration, tests, parfois refonte du module de connexion. Le volume de comptes, les technologies en place, l'ajout de la double authentification ou d'une connexion unique via Google ou Microsoft pèsent également sur le budget.

Chez RankerSquare, nous proposons un site vitrine sur-mesure dès 19,90 € par mois en abonnement, hébergement et mises à jour de sécurité inclus. Espaces clients, extranets et outils métier font l'objet d'un devis, une fois l'existant examiné. Vous montez un projet avec comptes utilisateur ? Notre équipe de création de logiciel intègre Argon2id et une politique de mots de passe moderne dès la conception.

Questions fréquentes

L'empreinte d'un mot de passe, obtenue par une fonction de hachage à sens unique. Le site conserve cette empreinte, pas le mot de passe. À chaque connexion, il recalcule le hash et compare. Si la base est volée, les pirates ne récupèrent que ces empreintes, d'autant plus longues à casser que l'algorithme est lent.

Pas directement, car le calcul ne va que dans un sens. Rien n'empêche cependant un attaquant de tester des millions de mots de passe probables jusqu'à tomber sur le même hash. Avec MD5, c'est rapide. Face à bcrypt ou Argon2id bien réglés et à un mot de passe long, le nombre de possibilités explose et l'effort ne vaut plus la peine.

Tous deux sont lents, salés et conçus pour les mots de passe. Bcrypt mise surtout sur le temps de calcul. Argon2id combine temps et mémoire, ce qui handicape davantage le matériel spécialisé des attaquants. Pour un projet neuf, je choisirais Argon2id. Un bcrypt bien configuré reste néanmoins parfaitement défendable.

À lire aussi. Sur le même thème.