Trois lettres suffisent à changer la sécurité d’un mot de passe hashé : d, i ou id. Depuis qu’Argon2 a remporté la Password Hashing Competition en 2015, les développeurs doivent choisir entre trois variantes aux propriétés très différentes. Une étude publiée fin 2025 par deux chercheurs de la FernUniversität de Hagen a passé au crible 161 dépôts GitHub en production et trouvé que 46,6 % d’entre eux utilisent des paramètres plus faibles que le minimum recommandé par l’OWASP. Le problème n’est donc pas de choisir un mauvais algorithme, mais de mal configurer le bon. Ce comparatif, qui s’inscrit dans notre couverture plus large de la cryptographie, détaille les différences techniques entre Argon2d, Argon2i et Argon2id, avec des benchmarks, des coûts d’attaque chiffrés et un guide de migration pour 2026.
Pourquoi un seul algorithme se décline en trois variantes
Argon2 n’est pas un algorithme unique mais une famille de trois fonctions qui partagent la même structure : une grille de blocs mémoire remplie en plusieurs passes, paramétrée par trois valeurs appelées mémoire (m), itérations (t) et parallélisme (p). Ce qui distingue Argon2d, Argon2i et Argon2id, c’est uniquement la façon dont l’algorithme choisit les blocs mémoire à lire pendant le calcul. Ce détail, qui semble mineur, change complètement le profil de sécurité de la fonction.
La norme RFC 9106, publiée par l’IRTF en 2021, formalise ce choix. Elle impose que les implémentations conformes supportent au minimum Argon2id et la recommande comme réglage par défaut pour le hachage de mots de passe. Mais elle documente aussi les deux autres variantes pour les cas où leurs propriétés spécifiques sont recherchées. Comprendre cette différence évite deux erreurs fréquentes : utiliser Argon2d dans un environnement cloud partagé, ou Argon2i dans un contexte où la résistance au GPU prime sur tout le reste.
Le contexte : un vainqueur de compétition né en 2015
Argon2 a été conçu par Alex Biryukov, Daniel Dinu et Dmitry Khovratovich pour la Password Hashing Competition, un concours ouvert lancé pour trouver un successeur à bcrypt, scrypt et PBKDF2. Le jury a désigné Argon2 vainqueur en 2015, saluant sa résistance au craquage matériel grâce à la dureté mémoire : contrairement à un simple hachage itéré, Argon2 oblige l’attaquant à allouer de grandes quantités de RAM pour chaque tentative, ce qui limite fortement l’intérêt des GPU et des ASIC de minage.
Ce choix de conception a un prix : l’algorithme doit décider, à chaque passe, quel bloc mémoire lire pour construire le suivant. Deux stratégies existent. La première laisse le contenu déjà calculé influencer l’adresse du prochain bloc. La seconde fixe les adresses à l’avance, sans rapport avec les données secrètes. Argon2d choisit la première approche, Argon2i la seconde, et Argon2id combine les deux. RFC 9106 détaille ces trois chemins et précise dans quels contextes chacun garde un intérêt pratique, onze ans après la victoire au concours.
Argon2d : la variante rapide mais exposée aux canaux auxiliaires
Argon2d (le d signifie data-dependent) choisit ses adresses mémoire en fonction des données déjà traitées, potentiellement liées au mot de passe. Ce comportement rend les accès mémoire irréguliers et difficiles à prédire à l’avance, ce qui complique sérieusement la conception de circuits ASIC optimisés pour le craquage. C’est la variante la plus résistante aux attaques par compromis temps-mémoire et aux cassages massifs sur GPU, à paramètres équivalents.
Le revers de la médaille, c’est que ces accès mémoire dépendants des données peuvent fuiter par des canaux auxiliaires, en particulier via des effets de cache observables par un processus concurrent sur la même machine physique. Dans un environnement de virtualisation partagée ou un serveur mutualisé, un attaquant capable d’exécuter du code sur la même machine pourrait théoriquement déduire des informations sur le mot de passe en observant les motifs d’accès au cache processeur. C’est pour cette raison que la documentation Rust de libsodium résume Argon2d comme offrant la meilleure résistance au craquage GPU, mais une vulnérabilité aux attaques par canal auxiliaire. Argon2d reste néanmoins largement utilisé hors du contexte des mots de passe : Monero s’appuie sur RandomX, un algorithme de preuve de travail qui construit son cache initial avec Argon2d avant d’exécuter du code aléatoire en machine virtuelle, précisément parce que le profil GPU-résistant de cette variante sert aussi à décourager le minage en ASIC. Hors de ce cas précis, Argon2d n’a pratiquement plus sa place dans une nouvelle application d’authentification : dès qu’un serveur peut héberger du code tiers, un conteneur voisin ou une fonction serverless partagée avec d’autres clients, le risque théorique de fuite par cache devient un argument suffisant pour lui préférer l’hybride.
Argon2i : l’accès indépendant pensé contre l’espionnage du cache
Argon2i (le i pour data-independent) choisit ses adresses mémoire selon un schéma fixe, sans dépendre des données secrètes en cours de traitement. Un attaquant qui observerait les accès mémoire d’un processus Argon2i n’apprendrait donc rien d’utile sur le mot de passe traité, puisque la séquence d’accès serait identique quel que soit le mot de passe. C’est exactement le scénario que cette variante a été conçue pour neutraliser.
Ce choix a un coût en sécurité ailleurs : des adresses mémoire prévisibles facilitent certaines attaques par compromis temps-mémoire, où un attaquant recalcule une partie des blocs plutôt que de les stocker tous, réduisant ainsi les besoins en mémoire au prix d’un peu plus de calcul. Pour compenser, Argon2i doit effectuer davantage de passes mémoire que Argon2d à sécurité équivalente. La documentation du projet de référence Argon2 le formule simplement : Argon2i offre une meilleure résistance à l’observation du cache mais nécessite davantage de passes, ce qui se traduit directement par un temps de calcul plus long pour un niveau de protection comparable. En pratique, peu de nouveaux projets choisissent Argon2i seul depuis que l’hybride est disponible, mais la variante reste pertinente dans des environnements WebAssembly ou JavaScript où l’exécution partagée avec du code tiers rend le risque de canal auxiliaire concret.
Argon2id : l’hybride devenu le choix par défaut
Argon2id combine les deux approches en une seule passe de calcul : la première moitié de la première itération suit le schéma indépendant des données d’Argon2i, puis le reste de l’exécution bascule sur le schéma dépendant des données d’Argon2d. L’objectif est de limiter l’exposition aux canaux auxiliaires pendant la phase initiale, tout en conservant l’essentiel de la résistance au craquage matériel pour le reste du calcul.
C’est ce compromis qui a convaincu RFC 9106 d’en faire la recommandation par défaut : la norme précise qu’Argon2id doit être pris en charge par toute implémentation conforme et qu’il s’agit du choix à privilégier lorsqu’on ignore la différence entre les variantes ou que les attaques par canal auxiliaire constituent une menace plausible, ce qui couvre la quasi-totalité des cas réels de hachage de mots de passe côté serveur. La page Wikipédia consacrée à Argon2 résume cette hiérarchie de recommandation de la même façon, et c’est aussi la variante que l’étude de Hagen a choisi d’étudier en détail, car c’est elle que la quasi-totalité des bibliothèques modernes exposent par défaut.
Tableau comparatif technique complet
Le tableau suivant regroupe les critères techniques les plus consultés par les équipes qui doivent choisir une variante pour une nouvelle application ou migrer un système existant.
| Caractéristique | Argon2d | Argon2i | Argon2id |
|---|---|---|---|
| Accès mémoire | Dépendant des données | Indépendant des données | Hybride (i puis d) |
| Résistance aux canaux auxiliaires | Faible | Forte | Moyenne à forte |
| Résistance GPU / ASIC et TMTO | Forte | Plus faible à paramètres égaux | Forte |
| Passes nécessaires à sécurité équivalente | Référence | Plus élevées | Proche d’Argon2d |
| Recommandé par défaut (RFC 9106) | Non | Non | Oui, support obligatoire |
| Minimum recommandé par l’OWASP | Non documenté | Profils dédiés séparés | Oui (19 456 KiB, t=2, p=1) |
| Défaut libsodium crypto_pwhash | Non | Non | Oui depuis la 1.0.15 |
| Défaut du paquet npm argon2 | Non | Non | Oui |
| Support PHP password_hash() | Non exposé | Non exposé | Oui via PASSWORD_ARGON2ID |
| Support Django Argon2PasswordHasher | Non | Non | Oui |
| Usage hors mot de passe | RandomX (Monero) | Rare | Dérivation de clés, chiffrement |
| Fonction de hachage interne | BLAKE2b | BLAKE2b | BLAKE2b |
| Sortie (tag) recommandée | 256 bits | 256 bits | 256 bits |
| Sel recommandé | 128 bits | 128 bits | 128 bits |
| Vainqueur Password Hashing Competition | Argon2 (famille complète), 2015 | ||
Benchmarks de performance : trois sources, trois méthodes
Comparer la vitesse brute des trois variantes est piégeux, car le temps de calcul dépend beaucoup plus des paramètres m, t et p que de la variante elle-même. La documentation officielle de libsodium donne un premier repère : une configuration nécessitant 256 Mio de RAM dédiée prend environ 0,7 seconde sur un processeur Core i7 à 2,8 GHz, tandis que le préréglage le plus strict proposé par la bibliothèque (le profil « sensitive ») dépasse les 5 secondes sur du matériel courant.
Un second repère, plus détaillé, vient du projet open source benchmark-argon2-dotnet, qui mesure Argon2id via libsodium avec BenchmarkDotNet. À 32 Mio de mémoire, une seule itération prend 16,26 ms, trois itérations 37,13 ms et six itérations 69,81 ms. En passant à 256 Mio, les mêmes réglages donnent respectivement 136,62 ms, 392,14 ms et 777,58 ms. Ces chiffres confirment une évidence trop souvent oubliée : doubler la mémoire ou le nombre de passes a un effet quasi linéaire sur le temps de calcul, bien plus déterminant que le choix entre Argon2d, Argon2i ou Argon2id à paramètres identiques.
Une troisième source, académique cette fois, apporte un angle différent : plutôt que de mesurer des millisecondes, l’étude de Pascal Tippe et Michael Berner (FernUniversität de Hagen, arXiv:2504.17121, révision d’octobre 2025) a calculé le coût économique du calcul lui-même, en dollars par hachage. C’est cette approche qui permet de construire une vraie grille tarifaire, détaillée dans la section suivante.
Un point commun relie ces trois sources : aucune ne permet de comparer la vitesse pure d’Argon2d, d’Argon2i et d’Argon2id entre elles à paramètres strictement identiques, faute de benchmark public assez détaillé pour isoler cette seule variable. Ce que montrent en revanche les trois jeux de mesures, c’est que le processeur, le compilateur, la version de la bibliothèque et surtout les valeurs de m, t et p pèsent bien plus lourd que le choix de la variante dans le temps de réponse final d’un serveur d’authentification. Tester sa propre configuration sur sa propre infrastructure reste donc la seule méthode fiable avant une mise en production.
| Source | Configuration mesurée | Résultat |
|---|---|---|
| Documentation libsodium | 256 Mio, Core i7 2,8 GHz | ≈ 0,7 s par hachage |
| Documentation libsodium | Profil « sensitive » | ≈ 5 s par hachage |
| benchmark-argon2-dotnet (GitHub) | 32 Mio, t=1 | 16,26 ms |
| benchmark-argon2-dotnet (GitHub) | 32 Mio, t=3 | 37,13 ms |
| benchmark-argon2-dotnet (GitHub) | 256 Mio, t=3 | 392,14 ms |
| benchmark-argon2-dotnet (GitHub) | 256 Mio, t=6 | 777,58 ms |
| Tippe & Berner, FernUniversität Hagen (2025) | Argon2id 2 048 Mio vs SHA-256 | Coût par hachage env. 3 850 fois plus élevé |
Le coût réel pour un attaquant : ce que révèle l’étude de Hagen
L’intérêt d’Argon2 ne se mesure pas en millisecondes mais en dollars dépensés par un attaquant pour casser un compte. L’étude de Hagen a modélisé ce coût en s’appuyant sur deux proxys économiques réels : le minage Bitcoin pour SHA-256, et le minage Monero via RandomX pour Argon2id, puisque cet algorithme de preuve de travail intègre justement Argon2d comme brique de base. Avec un hashrate Bitcoin de 701,72 EH/s relevé le 20 février 2025, le coût d’un hachage SHA-256 est estimé à environ 7,079 × 10⁻¹⁹ dollar. Pour Argon2id en configuration RFC 9106 (2 048 Mio), le coût grimpe à environ 2,729 × 10⁻¹² dollar par hachage, soit près de 3 850 fois plus cher à calculer que SHA-256. Une validation croisée par la consommation électrique d’un processeur grand public, à 0,05 $/kWh, donne un coût encore plus élevé : environ 4,17 × 10⁻⁷ dollar par hachage.
Pour transformer ce coût unitaire en risque concret, les chercheurs ont simulé des attaquants disposant de budgets de 0,10 $, 1 $ et 20 $ par compte ciblé, appliqués à deux jeux de données : la base RockYou (mots de passe réels divulgués en 2009, filtrés aux entrées de 8 caractères ou plus) et un jeu synthétique représentant des politiques de mot de passe plus strictes. Sur RockYou, dont la force médiane n’est que de 21,7 bits, même la configuration Argon2id la plus coûteuse ne change pas grand-chose : à 1 $ de budget, SHA-256 compromet 99,83 % des comptes contre 98,81 % pour Argon2id à 46 Mio et 96,89 % pour Argon2id à 2 048 Mio. Les mots de passe faibles restent le facteur décisif, quel que soit l’algorithme.
Le tableau change radicalement avec des mots de passe plus robustes. Sur le jeu synthétique, à 1 $ de budget, le taux de compromission tombe à 88,31 % pour SHA-256, 50,74 % pour Argon2id à 46 Mio et 38,92 % pour Argon2id à 2 048 Mio, soit un écart de 37,57 points de pourcentage entre SHA-256 et la configuration OWASP, une réduction relative de 42,5 %. À 20 $ de budget, l’écart entre les deux profils Argon2id (46 contre 2 048 Mio) atteint 10,48 points, pour un surcoût mémoire de 44,5 fois. C’est la preuve chiffrée d’un principe que les auteurs résument eux-mêmes : la dureté mémoire d’Argon2 offre des rendements décroissants, et passer de SHA-256 à Argon2 protège beaucoup plus de comptes que de pousser des paramètres Argon2 déjà robustes encore plus haut.
| Algorithme / configuration | Taux de compromission à 1 $ (Dsyn) | Taux de compromission à 20 $ (Dsyn) |
|---|---|---|
| SHA-256 | 88,31 % | 91,85 % |
| Argon2id, profil OWASP (46 Mio) | 50,74 % | 59,16 % |
| Argon2id, profil RFC 9106 (2 048 Mio) | 38,92 % | 48,69 % |
Ce qu’aucune variante d’Argon2 ne peut compenser
Le résultat le plus inconfortable de l’étude de Hagen ne concerne aucune des trois variantes : il concerne les utilisateurs. Sur la base RockYou, dont la force médiane plafonne à 21,7 bits, le passage de SHA-256 à Argon2id en configuration RFC 9106 la plus coûteuse (2 Gio de mémoire) ne fait reculer le taux de compromission que de quelques points, de 99,83 % à 96,89 % à 1 $ de budget. Autrement dit, un mot de passe prévisible reste cassable quelle que soit la robustesse de la fonction de hachage choisie, parce que l’attaquant n’a pas besoin d’épuiser tout l’espace possible : il lui suffit de tester les motifs les plus fréquents.
Les auteurs en tirent une conclusion opérationnelle simple, qui rejoint les recommandations classiques de l’OWASP sur la composition des mots de passe : les gains d’Argon2id explosent uniquement lorsque les mots de passe sont déjà robustes. Sur le jeu synthétique à force doublée, l’écart entre SHA-256 et Argon2id dépasse 40 points de pourcentage, alors qu’il reste marginal sur des mots de passe faibles. Pour un responsable sécurité, cela justifie d’associer systématiquement Argon2id à un estimateur de force type zxcvbn, à une politique de longueur minimale et à une liste noire des mots de passe déjà compromis, plutôt que de considérer le choix de l’algorithme de hachage comme une protection suffisante à elle seule.
RFC 9106 : les deux profils officiellement recommandés
RFC 9106 ne donne pas trois réglages séparés pour Argon2d, Argon2i et Argon2id. Elle propose deux profils génériques, tous deux construits autour d’Argon2id. Le premier, destiné aux systèmes capables de dédier beaucoup de mémoire par opération, utilise m=2²¹ KiB (2 097 152 KiB, soit 2 Gio), t=1 et p=4. Le second, pensé pour les environnements à mémoire contrainte, retient m=2¹⁶ KiB (65 536 KiB, soit 64 Mio), t=3 et p=4. Les deux profils partagent un sel de 128 bits et une sortie de 256 bits.
Le texte précise explicitement qu’Argon2d peut être préféré lorsque les canaux auxiliaires ne sont pas une menace plausible, typiquement pour des usages de preuve de travail plutôt que pour un service d’authentification exposé. Argon2i reste documenté pour les cas où l’accès mémoire indépendant des données est la priorité absolue, à condition d’accepter un nombre de passes plus élevé pour compenser la résistance TMTO plus faible. Mais pour un nouveau projet qui hache des mots de passe en 2026, la lecture directe de RFC 9106 mène presque toujours à Argon2id.
| Profil RFC 9106 | Mémoire (m) | Itérations (t) | Parallélisme (p) | Variante |
|---|---|---|---|---|
| Premier profil recommandé | 2 097 152 KiB (2 Gio) | 1 | 4 | Argon2id |
| Second profil recommandé | 65 536 KiB (64 Mio) | 3 | 4 | Argon2id |
OWASP 2026 : la grille de paramètres pour les développeurs
Le Password Storage Cheat Sheet de l’OWASP recommande Argon2id et fixe un plancher minimal à m=19 456 KiB (19 Mio), t=2, p=1. Ce plancher n’est pas la seule option : la fiche propose plusieurs couples mémoire/itérations à parallélisme 1, pour permettre d’ajuster le réglage à la charge serveur réelle plutôt que de copier un chiffre sans réfléchir.
Deux de ces profils portent une mise en garde explicite : « ne pas utiliser avec Argon2i », car les réglages à une ou deux passes sont calibrés pour la résistance TMTO d’Argon2id et seraient insuffisants pour Argon2i, qui a besoin de davantage de passes pour atteindre un niveau de protection comparable. C’est un détail que beaucoup d’équipes ignorent en recopiant une configuration trouvée en ligne sans vérifier la variante associée.
| Mémoire (m) | Itérations (t) | Parallélisme (p) | Remarque OWASP |
|---|---|---|---|
| 47 104 KiB (46 Mio) | 1 | 1 | Ne pas utiliser avec Argon2i |
| 19 456 KiB (19 Mio) | 2 | 1 | Minimum recommandé, ne pas utiliser avec Argon2i |
| 12 288 KiB (12 Mio) | 3 | 1 | — |
| 9 216 KiB (9 Mio) | 4 | 1 | — |
| 7 168 KiB (7 Mio) | 5 | 1 | Pour serveurs très contraints |
Qui utilise quoi par défaut : libsodium, PHP, Django, Node.js, Java
La variante choisie par défaut dans les bibliothèques les plus utilisées suit massivement la même direction. Libsodium a basculé son algorithme de hachage de mot de passe par défaut sur Argon2id depuis la version 1.0.15, via sa fonction crypto_pwhash(). Le paquet npm argon2, largement employé côté Node.js, documente Argon2id comme type par défaut. En PHP, password_hash() ne bascule pas automatiquement sur Argon2id avec la constante PASSWORD_DEFAULT : il faut appeler explicitement PASSWORD_ARGON2ID pour sélectionner la variante hybride, une nuance qui explique une partie des configurations faibles observées en production, comme le montre notre comparatif Argon2id face à bcrypt et scrypt.
Django prend en charge Argon2id via sa classe Argon2PasswordHasher, mais une installation standard continue d’utiliser PBKDF2 tant que ce hasher n’est pas placé en tête de la liste PASSWORD_HASHERS dans les réglages du projet. Autrement dit, le support d’une bibliothèque ne garantit pas son usage effectif. Du côté du monde Java, un brouillon de JEP OpenJDK propose d’intégrer Argon2 nativement dans le JDK, avec la même hiérarchie de recommandation : Argon2id par défaut, Argon2d documenté pour sa meilleure résistance TMTO, Argon2i pour les cas d’exposition au canal auxiliaire. Le module golang.org/x/crypto/argon2 implémente les trois variantes et cite directement les paramètres de RFC 9106 dans sa documentation.
| Bibliothèque / plateforme | Variante par défaut ou recommandée | Action requise |
|---|---|---|
| libsodium (crypto_pwhash) | Argon2id | Aucune depuis la 1.0.15 |
| Node.js, paquet npm argon2 | Argon2id | Aucune, type par défaut |
| PHP password_hash() | Argon2id disponible | Préciser PASSWORD_ARGON2ID |
| Django | Argon2id disponible | Placer Argon2PasswordHasher en tête de liste |
| Go golang.org/x/crypto/argon2 | Les trois variantes exposées | Choisir IDKey() pour Argon2id |
| OpenJDK (JEP en projet) | Argon2id recommandé | En cours de standardisation |
Ce que révèle l’analyse de plus de 1 000 dépôts GitHub en production
Au-delà des recommandations théoriques, l’étude de Hagen a analysé l’adoption réelle d’Argon2 en explorant les dépôts publics de GitHub entre 2008 et 2024. Après filtrage des faux positifs et des projets liés au minage de cryptomonnaies, la recherche par dépôt a identifié 1 032 dépôts Argon2, loin derrière les 12 065 dépôts bcrypt mais devant les 994 PBKDF2, 595 scrypt et seulement 40 yescrypt, son concurrent direct à la Password Hashing Competition. Sur la période 2015-2024, Argon2 affiche une moyenne de 102,7 nouveaux dépôts créés par an, contre 85,3 pour PBKDF2 et 51 pour scrypt, une croissance statistiquement significative face à scrypt selon le test de Kruskal-Wallis appliqué par les auteurs.
L’examen manuel de 161 dépôts à forte notation a permis d’extraire les paramètres réellement déployés. Les cinq configurations les plus fréquentes sont t=3/m=4 096 KiB (33 occurrences), t=3/m=65 536 KiB (28), t=2/m=19 456 KiB (11), t=1/m=65 536 KiB (10) et t=2/m=65 536 KiB (9). Les chercheurs attribuent ce regroupement aux valeurs par défaut des bibliothèques plutôt qu’à un choix délibéré des développeurs, ce qui explique la présence massive de t=3/m=4 096 KiB, un réglage à seulement 4 Mio de mémoire, nettement sous le plancher le plus permissif de l’OWASP. Pour les équipes qui veulent éviter ce piège lors d’une implémentation en Python ou en Node.js, notre tutoriel Argon2id pas à pas détaille chaque paramètre avant mise en production.
Globalement, 75 des 161 dépôts (46,6 %) utilisent des paramètres plus faibles que l’extrapolation des recommandations OWASP, contre 86 (53,4 %) qui les dépassent. La tendance s’améliore avec le temps : la part de configurations faibles tombe de 60,3 % avant 2018 à 33,3 % sur la période 2022-2024, une évolution statistiquement significative que les auteurs relient à la publication de RFC 9106 en 2021. Un résultat surprend particulièrement les chercheurs : les applications sensibles, gestionnaires de mots de passe et outils de chiffrement de fichiers, n’utilisent pas des paramètres significativement plus robustes (73,3 % de configurations fortes) que les applications générales (72,7 %). Ce sont surtout les composants, bibliothèques et liaisons logicielles, qui tirent la moyenne vers le bas, avec 52,4 % de configurations sous le seuil recommandé. Ce constat rejoint les leçons tirées de la fuite des 324 000 comptes publiée sur BreachForums, où la variante utilisée n’était pas en cause mais son paramétrage l’était.
Un autre résultat de l’étude surprend à première vue : les dépôts les plus populaires, ceux qui affichent le plus d’étoiles, présentent en moyenne des paramètres plus faibles que les dépôts récents et moins connus. Les chercheurs expliquent ce paradoxe par l’âge des projets plutôt que par leur qualité : un dépôt ancien a eu plus de temps pour accumuler des étoiles, mais il a aussi été créé avant la publication de RFC 9106 en 2021 et avant la mise à jour des recommandations OWASP, ce qui gèle ses valeurs par défaut à un niveau de sécurité daté tant que personne ne les révise.
Cinq cas d’usage et la variante à privilégier pour chacun
Authentification web grand public. Argon2id avec le profil OWASP minimal (19 Mio, t=2, p=1) ou légèrement renforcé selon la charge serveur mesurée. C’est le scénario pour lequel la quasi-totalité des bibliothèques modernes sont calibrées par défaut.
Gestionnaires de mots de passe et chiffrement de fichiers locaux. Argon2id avec le second profil RFC 9106 (64 Mio, t=3, p=4) au minimum, voire le premier profil à 2 Gio quand le calcul s’exécute sur la machine de l’utilisateur plutôt que sur un serveur partagé qui doit absorber des milliers de connexions simultanées.
API et fonctions serverless à mémoire limitée. Argon2id avec les profils OWASP les plus bas du tableau (9 à 12 Mio), en testant le temps de réponse réel sur l’infrastructure cible plutôt qu’en recopiant un chiffre générique, car les environnements facturés à la mémoire allouée rendent chaque mébioctet supplémentaire directement coûteux.
Environnements cloud multi-tenant ou WebAssembly partagé. Argon2id plutôt qu’Argon2d, pour limiter l’exposition aux canaux auxiliaires lorsque le code s’exécute à côté d’autres charges de travail non maîtrisées sur la même machine physique.
Preuve de travail et anti-spam, hors authentification. Argon2d reste pertinent quand la menace de canal auxiliaire est faible et que la priorité absolue est la résistance au calcul massif en GPU ou en ASIC, comme le démontre l’usage de Monero dans RandomX.
Avantages et inconvénients de chaque variante
| Variante | Avantages | Inconvénients |
|---|---|---|
| Argon2d | Meilleure résistance GPU/ASIC et TMTO à paramètres égaux, performant pour la preuve de travail | Exposé aux canaux auxiliaires sur machine partagée, déconseillé pour l’authentification serveur mutualisée |
| Argon2i | Accès mémoire indépendant des données, aucune fuite par observation du cache | Besoin de davantage de passes pour une sécurité comparable, peu adopté dans les bibliothèques récentes |
| Argon2id | Compromis recommandé par RFC 9106, défaut de facto dans l’écosystème moderne, bon équilibre canal auxiliaire / résistance matérielle | Légèrement plus complexe à paramétrer finement qu’un choix binaire, dépend toujours de m, t et p bien calibrés |
Guide de migration : passer de bcrypt, scrypt ou PBKDF2 à Argon2id
La migration d’un algorithme de hachage de mot de passe ne se fait jamais en un seul déploiement, car les hachages existants ne peuvent pas être reconvertis sans connaître le mot de passe en clair. La bonne pratique consiste à faire cohabiter l’ancien et le nouveau système le temps que les utilisateurs se reconnectent, comme pour une migration depuis bcrypt en Node.js. Cette logique vaut aussi pour une équipe qui part de scrypt ou de PBKDF2, deux algorithmes encore présents dans des centaines de milliers de dépôts recensés par l’étude de Hagen malgré leur adoption en recul depuis 2018.
- Auditer la configuration actuelle : quel algorithme, quelle bibliothèque, quels paramètres exacts sont en production aujourd’hui.
- Choisir le profil cible selon le contexte : OWASP minimal pour un service web classique, second profil RFC 9106 pour une application sensible.
- Mesurer le temps de hachage réel sur l’infrastructure de production, pas sur une machine de développement, avant de figer les paramètres.
- Activer Argon2id explicitement dans la bibliothèque choisie, en vérifiant que la constante correcte est bien utilisée (PASSWORD_ARGON2ID en PHP, Argon2PasswordHasher en tête de liste sous Django).
- Mettre en place un hachage progressif : à chaque connexion réussie, vérifier le mot de passe avec l’ancien algorithme puis le re-hacher immédiatement avec Argon2id avant de l’enregistrer.
- Surveiller la charge CPU et mémoire du serveur d’authentification après déploiement, pour détecter un risque de saturation sous forte affluence.
- Envisager un pré-hachage côté client pour les applications à fort trafic, afin de réduire le risque de déni de service lié au coût de calcul côté serveur.
- Revoir les paramètres tous les deux ans environ, à mesure que la puissance de calcul disponible pour un attaquant augmente.
Pour les équipes qui partent d’une base déjà sous Argon2id mais avec des paramètres hérités d’une ancienne version de bibliothèque, l’étape d’audit révèle souvent les mêmes configurations faibles que celles recensées par l’étude de Hagen, en particulier des réglages à 4 Mio de mémoire hérités d’anciens défauts. Une faille comme CVE-2026-59648 dans Bouncy Castle rappelle qu’une implémentation défaillante peut annuler les bénéfices d’un bon paramétrage, ce qui justifie de vérifier aussi la version de la bibliothèque utilisée, pas seulement les valeurs m, t et p.
Le verdict : quelle variante pour 2026
Pour la très grande majorité des projets qui hachent des mots de passe, la réponse est tranchée : Argon2id. C’est la seule variante que RFC 9106 impose de prendre en charge, celle que l’OWASP recommande explicitement, et celle que libsodium, le paquet npm argon2, PHP et Django exposent comme choix moderne par défaut ou quasi-défaut. Les données de l’étude de Hagen confirment que l’écart entre SHA-256 et Argon2id protège beaucoup plus de comptes, jusqu’à 46,99 % de réduction relative du taux de compromission à 20 $ de budget d’attaque sur des mots de passe robustes, que l’écart entre deux configurations Argon2id de force différente.
Argon2d garde un rôle précis hors du périmètre de l’authentification serveur, pour la preuve de travail ou les contextes où le canal auxiliaire n’est pas une menace réaliste. Argon2i, de son côté, devient difficile à justifier pour un nouveau projet depuis que l’hybride existe, sauf contrainte technique très spécifique liée à un environnement d’exécution partagé qui exclurait tout accès dépendant des données. Le vrai risque en 2026 n’est donc plus de choisir la mauvaise variante, mais de déployer Argon2id avec des paramètres hérités d’un ancien défaut de bibliothèque, un scénario qui concerne encore 46,6 % des déploiements analysés par les chercheurs de Hagen.
En résumé, Argon2id gagne sur presque tous les critères qui comptent pour une équipe produit : conformité RFC 9106, support natif dans les bibliothèques majeures, bon équilibre entre résistance matérielle et canaux auxiliaires. Argon2d et Argon2i gardent chacun un usage de niche justifié, mais plus aucun des deux ne constitue un choix par défaut raisonnable pour un nouveau service d’authentification lancé cette année.
Questions fréquentes
Quelle est la différence essentielle entre Argon2d, Argon2i et Argon2id ?
Les trois variantes partagent le même cœur de calcul mais diffèrent sur la façon de choisir les blocs mémoire à lire : Argon2d dépend des données traitées, Argon2i en est indépendant, et Argon2id combine les deux approches en une seule exécution.
Faut-il toujours utiliser Argon2id ?
Pour le hachage de mots de passe côté serveur, oui dans la quasi-totalité des cas. RFC 9106 impose son support et la recommande par défaut, et c’est la variante que la plupart des bibliothèques modernes exposent directement.
Quels paramètres minimum respecter en 2026 ?
L’OWASP recommande au minimum 19 456 KiB de mémoire, 2 itérations et un parallélisme de 1 pour Argon2id. RFC 9106 propose deux profils plus exigeants : 64 Mio à trois itérations, ou 2 Gio à une itération pour les systèmes qui peuvent se le permettre.
Argon2d est-il dangereux pour une application web ?
Il n’est pas cassé, mais son exposition aux canaux auxiliaires le rend moins adapté à un serveur d’authentification mutualisé où du code tiers pourrait s’exécuter à proximité. Argon2id couvre déjà la quasi-totalité de ses avantages sans ce risque.
Pourquoi tant de dépôts utilisent-ils des paramètres trop faibles ?
L’étude de Hagen attribue ce phénomène surtout aux valeurs par défaut des bibliothèques plutôt qu’à un choix délibéré des développeurs, un réglage copié sans être revérifié restant actif des années durant.
Un mot de passe fort compense-t-il une configuration Argon2 faible ?
En partie seulement. Les simulations montrent qu’un mot de passe robuste profite beaucoup plus d’Argon2id que d’un mot de passe faible, mais aucune configuration ne protège un mot de passe trivial issu d’une liste comme RockYou.
Peut-on migrer de bcrypt à Argon2id sans interrompre le service ?
Oui, via un hachage progressif : l’ancien algorithme continue de vérifier les connexions existantes, et chaque connexion réussie déclenche un re-hachage silencieux avec Argon2id, sans jamais demander aux utilisateurs de changer leur mot de passe.
Argon2i a-t-il encore un avenir ?
Son usage recule depuis la généralisation d’Argon2id, qui en reprend l’essentiel des propriétés sans le surcoût en passes mémoire. Il reste documenté par RFC 9106 mais de moins en moins choisi pour de nouveaux projets.
