bcrypt vs Argon2 expliqué : comparez les traits de sécurité, les coûts de performance réels et comment choisir des paramètres sûrs pour les backends web modernes.
Le hachage de mot de passe permet à un backend de stocker une représentation du mot de passe sans conserver le mot de passe lui-même. Lorsqu'un utilisateur s'inscrit, le serveur applique une fonction à sens unique au mot de passe et enregistre le résultat (le hachage). À la connexion, on hache la saisie de l'utilisateur et on compare avec ce qui est stocké.
Un hachage n'est pas un chiffrement. Il n'y a pas de méthode pour le déchiffrer. Cette propriété à sens unique est précisément la raison d'utiliser le hachage pour les mots de passe.
Alors pourquoi ne pas utiliser un hachage rapide comme SHA-256 ? Parce que rapide, c'est ce que recherchent les attaquants. Si une base est volée, les attaquants n'essaient pas de se connecter un par un : ils devinent hors ligne en testant les hachages volés aussi vite que leur matériel le permet. Avec des GPU, les fonctions rapides se testent à très grande échelle. Même avec des sels uniques, un hachage rapide reste peu coûteux à brute-forcer.
Voici le scénario réaliste : une petite appli web perd sa table d'utilisateurs dans une fuite. L'attaquant obtient des emails et des hachages. Si ces hachages ont été produits par une fonction rapide, les mots de passe courants et leurs petites variations tombent rapidement. Ensuite l'attaquant utilise ces mots de passe sur d'autres sites (credential stuffing) ou pour accéder à des fonctionnalités à privilèges dans votre appli.
Un bon hachage rend les essais coûteux. L'objectif n'est pas "incassable" mais "trop lent et coûteux pour en valoir la peine".
Une configuration de hachage devrait être :
Quand on compare bcrypt vs Argon2, on choisit comment ralentir le craquage de mots de passe après une fuite de base.
bcrypt est l'option plus ancienne et largement supportée. Elle est conçue pour être coûteuse en CPU et n'offre qu'un réglage principal : le facteur de coût. Elle est aussi « ennuyeuse » dans le bon sens : facile à trouver dans les bibliothèques, simple à déployer et prévisible.
Argon2 est plus récent et conçu pour être difficile en mémoire. Il peut forcer chaque tentative à utiliser une quantité significative de RAM, pas seulement du CPU. Cela compte parce que les attaquants gagnent souvent en lançant un grand nombre de tentatives en parallèle sur GPU ou matériel spécialisé. La mémoire est plus difficile et coûteuse à monter à ce niveau de parallélisme.
Argon2 existe en trois variantes :
Si votre pile supporte Argon2id et que vous pouvez régler la mémoire de façon sûre, c'est généralement le meilleur choix moderne. Si vous avez besoin d'une compatibilité maximale avec des systèmes plus anciens, bcrypt reste solide lorsqu'il est configuré avec un facteur de coût suffisamment élevé.
La question centrale est simple : si un attaquant vole la base de mots de passe, combien coûte la découverte des mots de passe à grande échelle ?
Avec bcrypt, vous contrôlez le coût (work factor). Un coût plus élevé signifie que chaque essai prend plus de temps. Cela ralentit les attaquants mais ralentit aussi vos vérifications de connexion, il faut donc trouver un équilibre entre pénaliser l'attaquant et rester acceptable pour les utilisateurs.
Avec Argon2id, vous pouvez ajouter la hardness mémoire en plus du coût temporel. Chaque tentative nécessite du temps CPU et de la RAM accédée selon un schéma précis. Les GPU sont très rapides pour le calcul, mais perdent beaucoup de leur avantage si chaque tentative parallèle exige une mémoire substantielle.
Les sels sont non négociables. Un sel unique et aléatoire par mot de passe :
Les sels ne rendent pas un mot de passe faible plus fort. Ils protègent surtout après une fuite en obligeant l'attaquant à effectuer un travail réel pour chaque utilisateur.
bcrypt est encore très utilisé parce qu'il est simple à déployer partout. Il convient quand vous avez besoin d'une large interopérabilité, que votre pile offre peu d'options cryptographiques, ou que vous voulez un seul curseur de réglage.
Le principal piège est la limite de 72 octets. bcrypt n'utilise que les 72 premiers octets du mot de passe et ignore le reste. Cela peut surprendre les utilisateurs de longues phrases de passe ou de gestionnaires de mots de passe.
Si vous choisissez bcrypt, clarifiez le comportement sur la longueur des mots de passe : imposez une longueur maximale explicite (en octets, pas en caractères) ou traitez les entrées longues de façon cohérente entre tous les services. L'important est d'éviter la troncature silencieuse qui modifie ce que l'utilisateur pense être son mot de passe.
bcrypt est aussi moins résistant au matériel parallèle moderne que les options mémoire-difficiles. Sa défense reste valide, mais elle dépend fortement du choix d'un facteur de coût qui rend chaque essai coûteux.
Si vous construisez un nouveau système ou si vous avez des comptes à haute valeur, migrer les nouveaux hachages vers Argon2id tout en continuant d'accepter les anciens bcrypt jusqu'à la connexion des utilisateurs est une approche courante à faible risque.
Argon2 a été conçu pour le hachage de mots de passe. Argon2id est la variante que la plupart des équipes choisissent car elle équilibre résistance aux GPU et protection raisonnable contre certains canaux auxiliaires.
Argon2id offre trois paramètres :
La mémoire est l'avantage principal. Si chaque tentative exige une quantité significative de RAM, les attaquants ne peuvent pas exécuter autant de tentatives en parallèle sans payer cher en capacité mémoire et bande passante.
L'inconvénient est opérationnel : plus de mémoire par hachage signifie moins de connexions simultanées possibles avant que vos serveurs ne ressentent la pression. Si vous réglez la mémoire trop haut, des pics de connexions peuvent provoquer des files d'attente, des timeouts ou même des erreurs d'OOM. Il faut aussi penser aux abus : de nombreuses tentatives simultanées peuvent devenir un problème de ressources si vous ne limitez pas le travail.
Pour garder Argon2id sûr et utilisable, traitez-le comme une caractéristique de performance :
Avec le hachage des mots de passe, « plus rapide = mieux » est souvent la mauvaise idée. Vous voulez que chaque tentative soit coûteuse pour les attaquants, tout en gardant les connexions agréables pour les utilisateurs réels.
Une méthode pratique consiste à définir un budget de temps par vérification sur votre matériel de production. Beaucoup d'équipes visent quelque chose comme 100 à 300 ms par vérification, mais le bon chiffre dépend du trafic et des serveurs. La différence entre bcrypt et Argon2 est ce que vous payez : bcrypt consomme surtout du CPU, Argon2 peut aussi réserver de la mémoire.
Choisissez un temps de hachage cible et testez dans des conditions proches de la production. Mesurez le hachage lors des inscriptions/changes de mot de passe et lors des connexions, mais considérez la connexion comme le chemin critique.
Un plan de mesure léger :
La plupart des systèmes lâchent pendant les pics. Si une newsletter envoie une vague d'utilisateurs sur la page de connexion, vos paramètres de hachage déterminent si le service reste réactif.
Si une vérification prend 250 ms et que votre serveur peut en gérer 40 en parallèle avant mise en file, un pic de 500 tentatives peut se transformer en attentes de plusieurs secondes. Dans ce cas, une petite réduction du coût associée à des limites strictes peut améliorer la sécurité réelle plus que pousser les paramètres au point de fragiliser l'endpoint de connexion.
Toutes les opérations liées au mot de passe n'ont pas la même urgence. Maintenez un coût de connexion interactif stable, et effectuez le travail lourd hors du chemin critique. Un schéma courant est le rehash-on-login (mise à jour du hachage après une connexion réussie) ou des jobs en arrière-plan pour les migrations et imports.
Le réglage vise à augmenter le coût pour l'attaquant sans ralentir ou déstabiliser vos serveurs.
Choisissez un algorithme bien supporté par votre pile. Si Argon2id est disponible et bien supporté, c'est en général le choix par défaut. Sinon, bcrypt reste acceptable.
Définissez un temps cible par hachage sur du matériel proche de la production. Choisissez quelque chose qui garde les connexions fluides même en pointe.
Ajustez pour atteindre ce temps. Avec bcrypt, changez le facteur de coût. Avec Argon2id, équilibrez mémoire, itérations et parallélisme. La mémoire change le plus l'économie pour l'attaquant.
Stockez l'algorithme et les paramètres avec le hachage. Les formats standards incluent souvent ces détails. Assurez-vous aussi que le champ en base est assez long pour ne pas tronquer les hachages.
Prévoyez des montées de version avec rehash-on-login. Lorsqu'un utilisateur se connecte, si son hachage est plus faible que la politique actuelle, recalculer et remplacer.
Si vous avez besoin d'une base avant mesure :
Considérez ces valeurs comme un début, pas des règles. Les bons paramètres dépendent de votre trafic, votre matériel et vos pics de connexion.
La plupart des échecs viennent de mauvais réglages, pas d'un algorithme cassé.
Les erreurs de sel sont fréquentes : chaque mot de passe doit avoir son propre sel unique stocké avec le hachage. Réutiliser un sel ou en utiliser un global rend plus facile la réutilisation du travail par les attaquants.
La négligence du coût est aussi courante : des équipes publient avec un coût bas pour la réactivité, puis n'y reviennent jamais. Le matériel évolue, les attaquants montent en puissance, et vos paramètres deviennent obsolètes.
La sur-optimisation d'Argon2 arrive aussi : fixer une mémoire très élevée peut avoir l'air bien sur le papier, puis provoquer des connexions lentes, des files d'attente ou des erreurs OOM en condition réelle.
La gestion de la longueur de mot de passe est importante, surtout avec la limite de 72 octets de bcrypt. Autoriser de longs mots de passe tout en les tronquant silencieusement crée de la confusion et affaiblit la sécurité.
Quelques bonnes pratiques simples :
Gardez cette liste près de vous lors du déploiement et des changements d'infrastructure :
Un contrôle simple : lancez un test en staging avec un pic de connexions (réussies et échouées) et observez la latence end-to-end, l'utilisation CPU et RAM. Si le chemin de connexion souffre, ajustez le coût et serrez les limites de débit. Ne « corrigez » pas en supprimant des éléments essentiels comme les sels.
Imaginez une petite SaaS avec quelques milliers d'utilisateurs. En journée c'est stable, mais vous avez des pics courts après une newsletter ou en début de journée. C'est là que le choix devient une question de capacité.
Vous optez pour Argon2id pour augmenter le coût du craquage hors ligne. Choisissez un temps de vérification cible sur votre serveur réel (par exemple 100 à 250 ms), puis ajustez les paramètres pour l'atteindre en surveillant la RAM, car la mémoire limite le nombre de connexions simultanées.
Une boucle de réglage pratique :
Si vous avez déjà des hachages plus anciens, continuez à les vérifier mais migrez discrètement : après une connexion réussie, re-hachez avec les paramètres actuels et stockez la nouvelle valeur. Progressivement, les utilisateurs actifs passeront à des hachages plus forts sans réinitialisation forcée.
Après la mise en production, surveillez la connexion comme tout endpoint critique : latence tail (p95/p99), CPU et RAM pendant les pics, pics d'échecs de connexion et vitesse de remplacement des anciens hachages.
Rédigez votre politique et considérez-la comme vivante. Par exemple : “Argon2id avec X mémoire, Y itérations, Z parallélisme” ou “bcrypt facteur de coût N”, avec la date de choix et la fréquence de révision (tous les 6–12 mois est un bon début).
Gardez un chemin de montée en version pour ne pas rester bloqué avec d'anciens hachages. Le rehash-on-login est simple et fonctionne dans la plupart des systèmes.
Un bon hachage aide, mais ne remplace pas les contrôles contre les abus en ligne. Les limites de débit, les verrous et des flux de réinitialisation de mot de passe soignés sont tout aussi importants pour la sécurité réelle.
Si vous construisez votre backend avec une plateforme no-code comme AppMaster, vérifiez que le module d'authentification utilise par défaut un hachage robuste et que le coût est réglé sur le même type d'infrastructure que celle sur laquelle vous déploierez. Ce petit test en amont fait souvent la différence entre « sécurisé et fluide » et « sécurisé mais inutilisable sous charge ».
What problem does password hashing solve?Le hachage de mot de passe permet de vérifier une connexion sans stocker le mot de passe en clair. On garde une valeur hachée à sens unique, on hache la saisie de l'utilisateur et on compare : si la base fuit, les attaquants doivent deviner les mots de passe plutôt que de les lire directement.
Why not just encrypt passwords instead of hashing them?Le chiffrement est réversible avec une clé : si cette clé est compromise, les mots de passe peuvent être récupérés. Le hachage est conçu pour être irréversible, on ne peut pas « déchiffrer » la valeur stockée pour retrouver le mot de passe initial.
Why is SHA-256 a bad choice for storing passwords?Les fonctions rapides comme SHA-256 sont favorisées par les attaquants car elles permettent d'essayer des milliards de combinaisons rapidement, surtout avec des GPU. Les mots de passe doivent être hachés avec une fonction volontairement lente (et idéalement dépendante de la mémoire) pour rendre les attaques massives coûteuses.
What is a salt, and does it actually make passwords safer?Un sel est une valeur unique et aléatoire stockée avec chaque hachage. Il empêche que des mots de passe identiques donnent des hachages identiques et bloque l'utilisation de tables pré-calculées. En revanche, un sel ne transforme pas un mot de passe faible en mot de passe fort.
When should I choose Argon2id vs bcrypt?Choisissez Argon2id si votre environnement le supporte bien et que vous pouvez régler la mémoire en toute sécurité : il est conçu pour résister au craquage parallèle. Prenez bcrypt si vous avez besoin d'une compatibilité maximale et d'un réglage plus simple, en augmentant suffisamment le facteur de coût.
What’s the big gotcha with bcrypt and long passwords?bcrypt a une limite de 72 octets : il n'utilise que les 72 premiers octets du mot de passe et ignore le reste. Pour éviter les surprises, imposez une longueur max explicite (en octets) ou traitez les entrées longues de façon cohérente pour ne pas tronquer silencieusement le mot de passe.
Which Argon2id parameter matters most, and why?La mémoire est le paramètre le plus important car elle limite le nombre de tentatives parallèles qu'un attaquant peut lancer sans payer cher en RAM et bande passante. Trop de mémoire nuit aussi à votre capacité à traiter les connexions simultanées : ajustez pour le trafic de pointe, pas seulement pour un test isolé.
How slow should password hashing be in a web backend?Visez un temps de vérification prévisible sur votre matériel de production, souvent autour de 100–300 ms par vérification, puis testez la concurrence en charge. Le bon réglage reste celui qui garde le service réactif pendant les pics tout en rendant le craquage hors ligne coûteux.
How do I upgrade hashing settings without forcing everyone to reset passwords?Stockez l'algorithme et ses paramètres avec le hachage pour pouvoir vérifier les anciens comptes et augmenter le coût plus tard. Une méthode courante est le rehash-on-login : après une connexion réussie, si le hachage est trop faible par rapport à la politique actuelle, recalculer et sauvegarder la nouvelle valeur.
What are the most common mistakes that weaken password storage?Les erreurs fréquentes sont l'absence ou la réutilisation de sels, le déploiement avec un coût trop faible puis l'oubli de le revoir, et la sur-optimisation de la mémoire pour Argon2 qui provoque des timeouts ou des erreurs pendant les pics. Surveillez aussi la gestion des longueurs de mot de passe (surtout pour bcrypt) et protégez le point de connexion avec des limites de débit et de courts verrous.
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
