Un mot de passe stocké en clair, c’est un incident de sécurité qui attend son heure. Mais même hashé, un mot de passe reste vulnérable si l’algorithme choisi tourne trop vite sur une carte graphique moderne. C’est exactement le dilemme que tranchent Argon2id, bcrypt et scrypt : trois façons de transformer un mot de passe en empreinte, avec des coûts de calcul, des besoins mémoire et des niveaux de résistance très différents face aux attaques par force brute. En 2026, le choix n’est plus vraiment ouvert selon l’OWASP, mais des millions de systèmes en production tournent encore avec l’un des deux autres algorithmes. Voici ce que chacun vaut réellement, avec des chiffres à l’appui.
Argon2id, bcrypt, scrypt : trois générations de hachage de mots de passe
bcrypt date de 1999. Niels Provos et David Mazières l’ont conçu à partir du chiffrement par bloc Blowfish, à une époque où les attaquants disposaient de processeurs et non de cartes graphiques massivement parallèles. Son principal levier de défense est un facteur de coût qui contrôle le nombre de tours de calcul, mais il ne consomme quasiment aucune mémoire vive, autour de 4 Ko par hachage. C’est précisément ce point faible qu’exploitent les fermes de cartes graphiques modernes.
scrypt est arrivé dix ans plus tard, en 2009, signé Colin Percival. Il introduit la notion de coût mémoire réglable via trois paramètres, N, r et p, qui forcent l’attaquant à réserver plusieurs mégaoctets de RAM par tentative. C’est un vrai progrès face à bcrypt, mais son réglage reste délicat : mal configuré, scrypt perd une bonne partie de son avantage.
Argon2 clôt la compétition. Vainqueur de la Password Hashing Competition en 2015, portée par Alex Biryukov, Daniel Dinu et Dmitry Khovratovich de l’université du Luxembourg, la variante Argon2id combine résistance aux attaques par canal auxiliaire et résistance aux attaques par compromis temps-mémoire. Elle est aujourd’hui normalisée dans la RFC 9106 de l’IETF, et c’est le choix par défaut recommandé par l’OWASP pour tout nouveau système en 2026.
La différence fondamentale entre les trois tient en un mot : la dureté mémoire. bcrypt est lié au CPU et ne bloque presque rien face à une carte graphique. scrypt et Argon2id forcent l’attaquant à consommer de la mémoire vive à chaque tentative, ce qui casse le parallélisme massif propre aux GPU et aux ASIC. Entre les deux, Argon2id va plus loin grâce à trois paramètres indépendants (mémoire, temps, parallélisme) qui permettent un réglage bien plus fin que les deux valeurs de scrypt.
Argon2d, Argon2i, Argon2id : trois variantes, un seul choix recommandé
La spécification Argon2 ne se limite pas à un seul algorithme : elle définit trois variantes distinctes, et confondre les trois est une erreur d’implémentation fréquente. Argon2d accède à la mémoire de façon dépendante des données traitées, ce qui maximise la résistance aux attaques par compromis temps-mémoire, le scénario où un attaquant échange de la mémoire contre du temps de calcul supplémentaire. C’est le choix le plus robuste sur ce critère précis, mais cet accès mémoire prévisible en fonction des données ouvre une brèche théorique aux attaques par canal auxiliaire, où un observateur mesure les temps d’accès mémoire pour déduire des informations sur le mot de passe traité.
Argon2i corrige ce point en rendant l’accès mémoire totalement indépendant des données d’entrée, ce qui neutralise la classe d’attaques par canal auxiliaire. Le compromis, c’est une résistance légèrement inférieure aux attaques par compromis temps-mémoire par rapport à Argon2d, puisque le motif d’accès devient prévisible pour un attaquant qui chercherait à optimiser son propre calcul.
Argon2id, enfin, découpe le calcul en deux phases : la première passe utilise un accès indépendant des données comme Argon2i, la seconde bascule vers un accès dépendant comme Argon2d. Cette construction hybride hérite du meilleur des deux approches sans en cumuler les faiblesses respectives, ce qui explique pourquoi la RFC 9106 de l’IETF et l’OWASP la désignent explicitement comme variante par défaut pour le hachage de mots de passe. Sauf cas d’usage très spécifique en dérivation de clé pure sans risque de canal auxiliaire, Argon2id est la seule des trois variantes à retenir en production en 2026.
Qui utilise quoi : Argon2id, bcrypt et scrypt dans l’industrie
Au-delà des recommandations théoriques, l’adoption réelle varie beaucoup selon l’âge du produit et son secteur. Les gestionnaires de mots de passe, dont le métier consiste précisément à protéger un secret unique et critique, ont massivement migré vers Argon2id : c’est un choix cohérent avec leur modèle de menace, puisqu’un coffre-fort chiffré ne se déverrouille qu’une poignée de fois par jour et peut se permettre un coût de calcul plus élevé que la connexion d’un site web à fort trafic.
Les grandes plateformes de messagerie chiffrée et de stockage cloud grand public appliquent la même logique à leurs mécanismes de dérivation de clé à partir du mot de passe utilisateur, en s’appuyant sur des fonctions à coût mémoire réglable plutôt que sur PBKDF2 seul. Du côté des plateformes SaaS B2B plus anciennes, la situation est plus contrastée : beaucoup restent sur bcrypt parce que le coût de migration d’une base de plusieurs millions de comptes dépasse largement le risque perçu, tant qu’aucune fuite n’a eu lieu.
Un cas particulier mérite d’être mentionné hors du strict périmètre de l’authentification web : scrypt a connu une seconde vie inattendue dans les cryptomonnaies. Litecoin, lancé en 2011, a choisi scrypt comme fonction de preuve de travail précisément pour sa résistance au minage par circuits spécialisés ASIC, un objectif proche de celui recherché pour le hachage de mots de passe, même si le contexte d’usage diffère radicalement. Cet emprunt croisé illustre bien la propriété centrale de scrypt : rendre le calcul massivement parallèle économiquement moins avantageux, que la cible soit un mot de passe ou un bloc de blockchain.
Implémentation pratique : exemple de code Argon2id en Node.js
Voici un exemple minimal d’implémentation avec la bibliothèque npm argon2, qui expose directement les trois paramètres recommandés par l’OWASP pour le hachage et la vérification d’un mot de passe.
const argon2 = require('argon2');
async function hacherMotDePasse(motDePasseClair) {
return argon2.hash(motDePasseClair, {
type: argon2.argon2id,
memoryCost: 65536, // 64 Mio, au-dessus du minimum OWASP de 19 Mio
timeCost: 3, // 3 itérations
parallelism: 1,
});
}
async function verifierMotDePasse(hachageStocke, motDePasseSaisi) {
try {
return await argon2.verify(hachageStocke, motDePasseSaisi);
} catch (erreur) {
return false; // hachage corrompu ou format invalide
}
}Le format de sortie encode directement le sel, la variante et les paramètres utilisés, ce qui permet à la fonction de vérification de reconnaître automatiquement les réglages appliqués lors du hachage initial, même si les paramètres par défaut évoluent plus tard sur le système. C’est un avantage pratique important pour toute stratégie de migration progressive : il n’est jamais nécessaire de stocker les paramètres séparément dans une colonne de base de données distincte.
Tableau comparatif : spécifications techniques d’Argon2id, bcrypt et scrypt
Le tableau ci-dessous réunit les caractéristiques techniques qui comptent vraiment lors du choix d’un algorithme de hachage de mots de passe pour un système en production.
| Caractéristique | bcrypt | scrypt | Argon2id |
|---|---|---|---|
| Année de création | 1999 | 2009 | 2015 |
| Base cryptographique | Chiffrement Blowfish | Fonction de dérivation à coût mémoire | Vainqueur PHC, RFC 9106 |
| Dureté mémoire | Non (environ 4 Ko fixes) | Oui, réglable (N, r, p) | Oui, réglable (m, t, p) |
| Résistance GPU/ASIC | Modérée | Élevée | Très élevée |
| Résistance aux canaux auxiliaires | Faible (non conçu pour) | Faible | Élevée (variante hybride) |
| Limite de longueur d’entrée | 72 octets, troncature silencieuse | Pas de limite pratique documentée | Pas de limite pratique |
| Paramètres réglables | 1 (facteur de coût) | 3 (N, r, p) | 3 (mémoire, itérations, parallélisme) |
| Recommandation OWASP 2026 | Compatibilité legacy uniquement | Solution de repli si Argon2id indisponible | Premier choix pour tout nouveau système |
| Sortie type | 60 caractères encodés | Variable selon implémentation | Variable, encodage PHC standard |
| Support natif Node.js | Via bibliothèque npm bcrypt/bcryptjs | Intégré à crypto.scrypt depuis Node 10 | Via bibliothèque npm argon2 |
| Disponibilité PHP | password_hash() natif depuis PHP 5.5 | Non natif, extensions tierces | password_hash() natif depuis PHP 7.2 |
| Complexité de réglage correct | Faible | Élevée | Moyenne |
Paramètres recommandés par l’OWASP en 2026
La Password Storage Cheat Sheet de l’OWASP fixe des seuils précis pour chaque algorithme, et ces chiffres servent de référence à la quasi-totalité des équipes sécurité en Europe. Pour Argon2id, le minimum recommandé est une mémoire de 19 Mio, un coût temporel de 2 itérations et un degré de parallélisme de 1. En pratique, beaucoup d’équipes montent à 32 ou 64 Mio avec 2 à 3 itérations dès que le budget serveur le permet, pour élargir la marge de sécurité sans dégrader l’expérience utilisateur au-delà de quelques centaines de millisecondes.
Quand Argon2id n’est pas disponible dans la pile technique, l’OWASP recommande scrypt avec un coût CPU/mémoire minimal de N égal à 2 puissance 17, un bloc r de 8 et un parallélisme p de 1. Ces réglages consomment plusieurs dizaines de mégaoctets par tentative, ce qui reste très efficace contre les attaques GPU tant que les paramètres ne sont pas rabaissés pour gagner en vitesse.
bcrypt garde sa place dans la recommandation, mais uniquement pour les systèmes existants. Le facteur de coût conseillé est d’au moins 10, avec 12 comme valeur par défaut la plus répandue dans les bibliothèques actuelles. À ce niveau, un hachage prend entre 100 et 250 millisecondes sur un serveur de production standard, ce qui reste acceptable côté utilisateur mais loin d’être suffisant face à un cluster de cartes graphiques dédié au cassage de mots de passe.
Benchmarks : résistance face aux attaques par GPU et par force brute
C’est sur ce terrain que la différence entre les trois algorithmes devient concrète. bcrypt, parce qu’il ne consomme presque pas de mémoire, se prête très bien au calcul massivement parallèle : une carte graphique haut de gamme peut aligner des dizaines de milliers de tentatives par seconde à un facteur de coût de 10, chaque cœur GPU exécutant son propre calcul sans se marcher dessus. C’est exactement le scénario que redoutent les équipes sécurité, puisqu’une fuite de base de données hachée en bcrypt à faible coût tombe bien plus vite qu’une base en Argon2id.
scrypt change la donne en forçant chaque tentative à réserver plusieurs dizaines de mégaoctets de mémoire vive. Un GPU dispose certes de plusieurs gigaoctets de VRAM au total, mais cette mémoire doit être partagée entre tous les cœurs qui tentent de casser le hachage en parallèle. Résultat : le débit s’effondre à quelques centaines, voire quelques milliers de tentatives par seconde selon les réglages, contre des dizaines de milliers pour bcrypt à coût équivalent en temps de calcul côté serveur légitime.
Argon2id pousse ce principe plus loin encore. À 64 Mio de mémoire et 3 itérations, une configuration jugée robuste en 2026, le débit de cassage sur GPU tombe généralement à quelques dizaines voire quelques centaines de tentatives par seconde par carte. La mémoire vive devient le facteur limitant bien avant la puissance de calcul brute, ce qui rend l’attaque par dictionnaire ou par force brute économiquement dissuasive à grande échelle. C’est cette combinaison de dureté mémoire réglable et de résistance aux canaux auxiliaires qui a poussé l’OWASP, la Password Hashing Competition et la RFC 9106 à converger sur Argon2id comme référence.
Trois sources indépendantes confirment cette hiérarchie de résistance. La Password Hashing Competition, qui a évalué 24 candidats entre 2013 et 2015, a désigné Argon2 vainqueur précisément sur ce critère de résistance aux compromis temps-mémoire. La Cheat Sheet Series de l’OWASP classe la résistance GPU/ASIC de bcrypt comme modérée, celle de scrypt comme élevée et celle d’Argon2id comme très élevée. Enfin, le NIST, dans sa directive SP 800-63B sur l’authentification numérique, recommande explicitement des fonctions à coût mémoire réglable pour tout stockage de secret d’authentification, une description qui exclut de fait bcrypt sous sa forme classique.
Tableau des coûts : combien coûte le cassage d’une base de mots de passe
Pour un responsable sécurité, la vraie question n’est pas seulement technique mais économique : combien un attaquant doit-il dépenser en location de puissance de calcul pour casser une base de données volée ? Le tableau suivant résume les ordres de grandeur relatifs entre les trois algorithmes à paramètres recommandés par l’OWASP, en fonction du budget de location de cartes graphiques dans le cloud.
| Scénario de coût | bcrypt (coût 12) | scrypt (N=2^17) | Argon2id (64 Mio, t=3) |
|---|---|---|---|
| Consommation mémoire par tentative | ~4 Ko | ~16-32 Mo | ~64 Mo |
| Débit relatif sur GPU haut de gamme | Élevé (référence) | Réduit d’un ou deux ordres de grandeur | Réduit de deux à trois ordres de grandeur |
| Coût de location cloud pour un dictionnaire de taille moyenne | Le moins cher des trois | Nettement plus cher que bcrypt | Le plus cher des trois, souvent d’un ordre de grandeur |
| Effet d’un mot de passe faible malgré le hachage | Cassable rapidement même haché | Ralenti mais pas bloqué | Fortement ralenti, dissuasif pour l’attaquant opportuniste |
| Recommandation pour budget de sécurité limité | Non recommandé pour un nouveau projet | Acceptable si Argon2id indisponible | Meilleur rapport coût de défense / coût d’attaque |
Cette asymétrie coût de défense contre coût d’attaque est l’argument central en faveur d’Argon2id. Faire hacher un mot de passe légitime prend, côté serveur, quelques centaines de millisecondes de plus qu’avec bcrypt. Mais côté attaquant qui doit répéter l’opération des milliards de fois pour un dictionnaire complet, cette même contrainte mémoire multiplie la facture de location de cartes graphiques dans des proportions bien plus importantes, rendant l’attaque économiquement irrationnelle pour la majorité des adversaires opportunistes.
Tarification : le coût d’infrastructure réel de chaque algorithme
Les trois algorithmes sont open source et gratuits à l’usage, aucune licence ne bloque leur adoption. Le vrai coût se situe côté infrastructure serveur, puisque chaque connexion utilisateur déclenche un calcul de vérification qui consomme du CPU et, pour scrypt et Argon2id, de la mémoire vive dédiée. Ce tableau donne un ordre de grandeur du surcoût d’hébergement à budgétiser selon l’algorithme choisi, pour un service qui traite un volume de connexions important.
| Poste de coût | bcrypt (coût 12) | scrypt (N=2^17) | Argon2id (64 Mio, t=3) |
|---|---|---|---|
| Licence / coût logiciel | Gratuit, open source | Gratuit, open source | Gratuit, open source |
| Latence typique par connexion | ~100-250 ms | ~150-300 ms selon réglage | ~200-400 ms selon réglage |
| Mémoire vive réservée par connexion simultanée | Négligeable (~4 Ko) | 16 à 32 Mo | 32 à 64 Mo |
| Impact sur le dimensionnement serveur à fort trafic | Minime | Modéré, prévoir de la RAM supplémentaire | Notable, dimensionner la RAM en priorité sur le CPU |
| Coût de migration depuis un système existant | Nul (déjà en place sur la plupart des systèmes legacy) | Faible à modéré | Modéré, nécessite une stratégie de re-hachage progressif |
| Coût relatif pour un attaquant qui loue des GPU cloud | Le plus faible des trois | Intermédiaire | Le plus élevé des trois |
Ce tableau met en évidence un point souvent négligé lors du choix d’un algorithme : le coût d’infrastructure supplémentaire d’Argon2id, de l’ordre de quelques dizaines de mégaoctets de RAM par connexion simultanée, reste marginal comparé au coût qu’il impose à un attaquant qui doit répéter ce même calcul des milliards de fois. Pour un service qui gère quelques centaines de connexions par seconde en pointe, l’investissement supplémentaire en mémoire serveur se chiffre en dizaines d’euros mensuels sur un hébergement cloud classique, un montant sans commune mesure avec le coût qu’aurait une fuite de base de données mal protégée en termes d’image et de conformité réglementaire.
Limite des 72 octets : le piège de bcrypt encore actif en 2026
Un défaut de bcrypt reste largement méconnu des équipes de développement en 2026 : l’algorithme tronque silencieusement toute entrée au-delà de 72 octets. Concrètement, un utilisateur qui saisit une phrase de passe de 100 caractères verra les 28 derniers caractères purement et simplement ignorés lors du hachage. Deux mots de passe différents au-delà de ce seuil, mais identiques sur les 72 premiers octets, produisent alors le même hachage, ce qui réduit l’entropie effective sans que l’utilisateur ni le développeur ne s’en rendent compte.
Ce comportement date de la conception originale de l’algorithme en 1999, à une époque où les phrases de passe longues n’étaient pas la norme. Certaines implémentations modernes de bcrypt ajoutent une étape de pré-hachage en SHA-256 avant l’appel à bcrypt pour contourner cette limite, mais cette pratique n’est pas universelle et introduit sa propre surface de risque si elle est mal implémentée. Ni scrypt ni Argon2id ne souffrent de cette limitation documentée : les deux acceptent des entrées bien plus longues sans troncature silencieuse, ce qui en fait un argument supplémentaire en faveur d’une migration pour toute application qui encourage les phrases de passe longues plutôt que les mots de passe courts et complexes.
Adoption par langage et framework : ce qu’utilisent Django, Rails, Laravel et Node.js en 2026
La théorie et la pratique divergent nettement quand on regarde les valeurs par défaut des frameworks les plus utilisés. Django continue de hacher les mots de passe avec PBKDF2-HMAC-SHA256 par défaut, un choix hérité qui reste sécurisé s’il est bien paramétré, mais qui n’offre pas la même dureté mémoire qu’Argon2id. Le framework propose Argon2 comme option activable via le paquet django[argon2], mais ce n’est toujours pas le réglage de sortie de boîte.
Ruby on Rails, via Devise et la méthode has_secure_password, s’appuie historiquement sur bcrypt comme algorithme par défaut. C’est également le cas de Laravel, dont la façade Hash utilise bcrypt de série, même si le framework PHP permet de basculer vers Argon2i ou Argon2id via un simple changement de configuration. Ce choix de compatibilité descendante explique pourquoi bcrypt reste si présent en production malgré les recommandations OWASP : changer l’algorithme par défaut d’un framework aussi installé casserait la compatibilité avec des millions de bases existantes.
Côté Node.js, il n’existe pas de framework unique qui impose un choix, mais l’écosystème s’est largement construit autour des paquets npm bcrypt et bcryptjs, aujourd’hui concurrencés par le paquet argon2 en croissance rapide. PHP, de son côté, propose Argon2i et Argon2id nativement via la fonction password_hash() depuis la version 7.2, ce qui facilite grandement la migration pour les projets qui veulent adopter le standard recommandé sans dépendance externe.
Exemples concrets : cinq cas d’usage et l’algorithme adapté
Le choix entre les trois algorithmes dépend fortement du contexte technique et du budget serveur disponible. Voici cinq scénarios représentatifs rencontrés par les équipes qui migrent leur système d’authentification.
- Nouvelle application SaaS B2B : Argon2id à 32 ou 64 Mio de mémoire est le choix par défaut. Le budget serveur est généralement suffisant pour absorber le coût de calcul supplémentaire, et l’application n’a aucune dette technique à gérer avec un algorithme legacy.
- API embarquée sur matériel contraint en mémoire : scrypt avec des paramètres N réduits, ou bcrypt à coût 12 si la mémoire disponible est vraiment insuffisante pour tenir les réglages OWASP d’Argon2id. Ce compromis reste défendable tant que d’autres couches de protection existent, comme la limitation de tentatives.
- Migration d’une base héritée en bcrypt vers Argon2id : stratégie de migration paresseuse. Le système détecte le préfixe bcrypt existant, vérifie la connexion avec la bibliothèque bcrypt, puis re-hache le mot de passe en clair avec Argon2id et écrase l’ancienne valeur, sans jamais forcer une réinitialisation de masse.
- Système soumis à des exigences de conformité FIPS : PBKDF2 reste parfois imposé par des contraintes réglementaires strictes aux États-Unis, mais pour les entreprises européennes non soumises à ce cadre, Argon2id est privilégié dès que la conformité le permet.
- Coffre-fort de mots de passe ou gestionnaire d’identifiants : Argon2id à des paramètres agressifs, souvent au-delà de 64 Mio de mémoire, car l’opération de déverrouillage n’a lieu qu’une fois par session et peut se permettre un coût de calcul plus élevé sans nuire à l’expérience utilisateur.
Guide de migration : passer de bcrypt ou scrypt à Argon2id sans casser la production
Migrer un système d’authentification en production sans interrompre le service ni forcer tous les utilisateurs à réinitialiser leur mot de passe demande une approche progressive plutôt qu’un basculement brutal.
- Auditer l’algorithme actuel. Identifier précisément quel algorithme et quels paramètres sont utilisés aujourd’hui, en examinant le préfixe des hachages stockés en base.
- Installer la bibliothèque Argon2 adaptée au langage. Le paquet npm argon2 pour Node.js, le module argon2-cffi pour Python, ou l’extension native de PHP selon la pile technique en place.
- Définir les paramètres cibles. Partir du minimum OWASP de 19 Mio, 2 itérations, parallélisme 1, puis ajuster à la hausse en fonction de la charge CPU mesurée en environnement de test.
- Implémenter la vérification dual-algorithme. Le code de connexion doit détecter le format du hachage stocké et appeler la bonne bibliothèque de vérification selon qu’il s’agit d’un ancien hachage bcrypt/scrypt ou d’un nouveau hachage Argon2id.
- Activer le re-hachage paresseux. Dès qu’un utilisateur se connecte avec succès via l’ancien algorithme, re-hacher immédiatement son mot de passe en clair avec Argon2id et écraser la valeur stockée.
- Ne jamais convertir un hachage existant sans le mot de passe en clair. Un hachage bcrypt ne peut pas être transformé mathématiquement en hachage Argon2id : la seule voie de migration passe par la re-saisie du mot de passe lors d’une connexion réussie.
- Fixer une politique d’expiration pour les comptes inactifs. Les comptes qui ne se sont jamais reconnectés après un délai défini, par exemple 12 à 18 mois, peuvent être forcés à une réinitialisation de mot de passe pour terminer la migration.
- Surveiller la charge CPU serveur après déploiement. Argon2id consomme davantage de ressources par connexion que bcrypt ; un pic de trafic de connexion peut nécessiter un ajustement des paramètres ou une mise à l’échelle horizontale.
- Documenter la politique de hachage dans le code. Consigner les paramètres choisis et la date de dernière révision pour faciliter les audits de sécurité futurs et les prochaines montées en puissance des paramètres.
- Retirer le support de l’ancien algorithme après un délai raisonnable. Une fois la grande majorité des comptes actifs migrés, désactiver la vérification bcrypt/scrypt pour réduire la surface de code à maintenir.
Avantages et inconvénients de chaque algorithme
bcrypt
Avantages : éprouvé depuis plus de 25 ans sans faille structurelle majeure documentée, support natif quasi universel dans tous les langages et frameworks, simplicité d’implémentation avec un seul paramètre à régler, large compatibilité avec les systèmes legacy.
Inconvénients : aucune dureté mémoire réelle, résistance GPU seulement modérée, troncature silencieuse à 72 octets, absence de protection native contre les attaques par canal auxiliaire, considéré comme insuffisant par l’OWASP pour tout nouveau projet en 2026.
scrypt
Avantages : dureté mémoire réglable qui ralentit sérieusement les attaques GPU, disponible nativement dans le module crypto de Node.js depuis la version 10, alternative crédible reconnue par l’OWASP quand Argon2id n’est pas disponible.
Inconvénients : réglage des trois paramètres N, r et p nettement plus délicat que pour bcrypt, moins étudié par la communauté cryptographique académique qu’Argon2, absence de résistance native aux attaques par canal auxiliaire, support moins répandu dans les bibliothèques tierces.
Argon2id
Avantages : vainqueur d’une compétition académique ouverte de deux ans, normalisé par la RFC 9106 de l’IETF, meilleure résistance combinée aux attaques GPU/ASIC et aux canaux auxiliaires, trois paramètres indépendants pour un réglage fin, recommandation numéro un de l’OWASP et implicitement alignée avec les directives NIST SP 800-63B.
Inconvénients : consommation mémoire plus élevée qui peut peser sur des serveurs sous contrainte de ressources, pas encore le défaut de sortie de boîte dans Django, Rails ou Laravel, adoption encore partielle dans certains environnements legacy où la migration demande du temps d’ingénierie.
Salage et poivre : ce que le hachage seul ne couvre pas
Les trois algorithmes intègrent nativement un sel aléatoire, une valeur unique générée pour chaque mot de passe qui empêche deux utilisateurs partageant le même mot de passe de produire le même hachage en base. C’est une protection indispensable contre les tables arc-en-ciel, ces bases précalculées de hachages qui permettaient autrefois de retrouver instantanément un mot de passe courant. Sans sel, un attaquant qui compromet une base de données peut précalculer une seule fois le hachage de chaque mot de passe du dictionnaire et le comparer à toutes les entrées volées d’un coup ; avec un sel unique par utilisateur, il doit refaire ce calcul individuellement pour chaque compte, ce qui multiplie son effort par le nombre de comptes ciblés.
Le sel ne remplace toutefois pas la dureté mémoire : il protège contre le précalcul en masse, pas contre la vitesse de calcul unitaire. C’est pourquoi bcrypt, qui sale nativement chaque hachage depuis sa création, reste malgré tout dépassé face à un GPU moderne pour un mot de passe individuel ciblé. Certaines architectures ajoutent une couche supplémentaire appelée poivre, une clé secrète globale stockée séparément de la base de données, par exemple dans un gestionnaire de secrets ou un module matériel de sécurité. Le poivre protège spécifiquement contre le scénario où seule la base de hachages fuite, sans que le secret applicatif ne soit compromis en même temps, une défense en profondeur complémentaire quel que soit l’algorithme de hachage retenu.
Cas réels : incidents liés à un hachage de mots de passe insuffisant
Les leçons tirées d’incidents passés continuent d’alimenter les recommandations actuelles. Les fuites historiques les plus citées dans le secteur, comme celles ayant touché LinkedIn et Adobe il y a plusieurs années, partageaient un point commun : des fonctions de hachage rapides et non conçues pour les mots de passe, ou des paramètres de coût trop faibles, avaient permis aux attaquants de récupérer une part massive des identifiants après le vol des bases de données. C’est directement ce type de scénario que la dureté mémoire d’Argon2id et de scrypt cherche à neutraliser en 2026.
Plus récemment, des forums de cybercriminalité ont mis en vente des bases de comptes hachées en Argon2 après des compromissions de plateformes, illustrant qu’aucun algorithme ne rend une fuite de données anodine. La dureté mémoire ralentit considérablement le cassage hors ligne, mais elle ne dispense jamais d’une politique de mots de passe robuste côté utilisateur, ni d’une authentification à deux facteurs en couche complémentaire. Le hachage protège contre l’exploitation d’une base volée, pas contre le vol lui-même.
Verdict : quel algorithme choisir en 2026
Pour tout système lancé aujourd’hui, Argon2id à des paramètres égaux ou supérieurs au minimum OWASP (19 Mio, 2 itérations, parallélisme 1) doit être le point de départ par défaut. C’est l’algorithme le plus récent, le mieux documenté par la recherche académique, et le seul des trois à combiner dureté mémoire réglable et résistance native aux attaques par canal auxiliaire. La RFC 9106 lui donne un cadre de référence stable, et la convergence entre OWASP, la Password Hashing Competition et les orientations NIST laisse peu de place au doute sur la direction à suivre.
scrypt reste une alternative défendable, en particulier pour les équipes qui travaillent sur des piles techniques où Argon2id n’est pas encore disponible nativement, à condition de régler correctement les paramètres N, r et p et de ne jamais céder à la tentation de les réduire pour gagner en latence. bcrypt, de son côté, n’est plus recommandé pour un nouveau déploiement en 2026, mais son ancienneté et sa simplicité justifient qu’il reste en place sur des systèmes existants, à condition d’engager une migration progressive vers Argon2id dès que les ressources d’ingénierie le permettent. La règle qui résume la position de l’ensemble du secteur en 2026 tient en une phrase : Argon2id par défaut, scrypt en repli, bcrypt en maintenance uniquement.
Ce verdict n’est pas figé pour l’éternité. La cryptographie évolue par cycles, et Argon2id a lui-même remplacé bcrypt après quinze ans de domination quasi incontestée. Les équipes sécurité qui adoptent Argon2id aujourd’hui devraient prévoir, dès la conception, une architecture capable d’absorber un futur changement d’algorithme sans réécriture complète, via un champ qui encode l’algorithme utilisé et une routine de re-hachage paresseuse déjà en place. C’est cette anticipation, plus que le choix d’un algorithme précis, qui distingue une architecture d’authentification réellement pérenne d’une simple conformité de façade aux recommandations du moment.
Questions fréquentes
bcrypt est-il encore sûr à utiliser en 2026 ?
Oui, dans le sens où aucune faille cryptographique majeure ne le rend cassable directement. Mais sa résistance aux attaques GPU reste bien plus faible que celle d’Argon2id ou de scrypt, ce qui en fait un choix acceptable uniquement pour maintenir un système existant, pas pour un nouveau projet.
Pourquoi Argon2id plutôt qu’Argon2i ou Argon2d ?
Argon2d optimise la résistance aux attaques par compromis temps-mémoire mais reste vulnérable aux attaques par canal auxiliaire à cause de son accès mémoire dépendant des données. Argon2i corrige ce point mais perd en résistance pure. Argon2id combine les deux approches et constitue la variante hybride recommandée par défaut par l’OWASP et par la RFC 9106.
Peut-on migrer directement un hachage bcrypt existant vers Argon2id sans le mot de passe en clair ?
Non. Un hachage est une fonction à sens unique : il n’existe aucun moyen mathématique de transformer un hachage bcrypt en hachage Argon2id sans repasser par le mot de passe en clair. La seule méthode viable est le re-hachage paresseux lors d’une connexion réussie de l’utilisateur.
Quelle est la limite des 72 octets de bcrypt et pourquoi pose-t-elle problème ?
bcrypt tronque silencieusement toute entrée au-delà de 72 octets. Un utilisateur qui utilise une phrase de passe longue verra sa sécurité effective réduite sans avertissement, puisque tous les caractères au-delà de cette limite sont ignorés lors du calcul du hachage.
scrypt est-il plus sûr que bcrypt ?
Oui, sur le plan de la résistance aux attaques GPU, grâce à sa dureté mémoire réglable. Mais son réglage correct est plus complexe que celui de bcrypt, et il n’a pas bénéficié du même niveau d’analyse académique qu’Argon2, ce qui explique pourquoi l’OWASP le positionne en solution de repli plutôt qu’en premier choix.
Quels paramètres Argon2id utiliser en production ?
Le minimum recommandé par l’OWASP est une mémoire de 19 Mio, un coût temporel de 2 itérations et un parallélisme de 1. De nombreuses équipes montent à 32 ou 64 Mio avec 2 à 3 itérations dès que la capacité serveur le permet, pour renforcer la marge de sécurité.
Le hachage de mot de passe suffit-il à protéger un compte utilisateur ?
Non. Un bon algorithme de hachage protège la base de données en cas de fuite, mais il ne remplace ni une politique de mots de passe robuste côté utilisateur, ni l’authentification à deux facteurs, ni la détection d’anomalies de connexion. Ce sont des couches de défense complémentaires, pas interchangeables.
Django, Rails et Laravel utilisent-ils Argon2id par défaut ?
Non, en 2026, aucun des trois ne l’active par défaut. Django utilise PBKDF2-HMAC-SHA256, tandis que Rails et Laravel s’appuient sur bcrypt. Les trois frameworks permettent d’activer Argon2id via configuration, mais cela reste une démarche volontaire de l’équipe de développement.
