BreachForums : 324 000 Comptes Argon2 Fuités [2026]

Le 9 janvier 2026, la base d’utilisateurs de BreachForums, l’un des plus grands forums de cybercriminalité au monde, a fuité sur le net. Le détail qui a fait tousser les experts en sécurité n’est pas le nombre de comptes exposés, mais l’algorithme derrière les mots de passe volés : Argon2, le hachage réputé le plus résistant du marché. Sept mois plus tard, une étude publiée en juillet 2026 par Specops montre qu’un simple processeur à 2 100 dollars peut casser des hashs Argon2 plus vite qu’une ferme de huit cartes graphiques. Entre ces deux événements, l’ANSSI a publié le 20 mars 2026 un guide qui rend, de fait, Argon2 quasi obligatoire pour toute organisation française traitant des données personnelles. Le message est clair : l’algorithme tient, mais la marge de manœuvre se réduit.

Qu’est-ce qu’Argon2 et pourquoi il domine le hachage de mots de passe

Argon2 est une fonction de hachage conçue spécifiquement pour protéger des mots de passe, et non des fichiers ou des messages. Contrairement à SHA-256 ou MD5, qui calculent une empreinte en quelques microsecondes, Argon2 est volontairement lent et gourmand en mémoire. Cette lenteur est un choix : elle ralentit un attaquant qui tente de tester des milliards de combinaisons, sans gêner un serveur qui vérifie un seul mot de passe à la connexion.

L’algorithme existe en trois variantes. Argon2d résiste bien aux attaques par GPU mais reste vulnérable aux attaques par canal auxiliaire. Argon2i protège contre ces attaques par canal auxiliaire au prix d’une résistance moindre au calcul parallèle. Argon2id combine les deux approches et constitue, depuis sa standardisation dans la RFC 9106 de l’IETF en 2021, le choix recommandé par défaut pour le stockage de mots de passe. C’est cette variante hybride que ciblent la quasi-totalité des recommandations actuelles, y compris celles de l’OWASP dans son Password Storage Cheat Sheet.

La fuite BreachForums : 324 000 comptes exposés malgré Argon2

Selon l’analyse publiée par eSecurity Planet, la fuite de janvier 2026 a exposé 323 986 enregistrements issus de la base MyBB de BreachForums, chiffre confirmé par la société de renseignement Resecurity. Les données comprennent noms d’utilisateur, adresses e-mail, métadonnées de connexion et mots de passe hachés en Argon2. Une seconde analyse de la même fuite, connue sous le nom de « BreachForums Version 5 », évoque 340 000 adresses e-mail uniques exposées, avec la même signature Argon2 dans la base utilisateurs. Les deux chiffres divergent légèrement selon la méthode de comptage, mais convergent sur un point : l’algorithme employé par le forum était bien Argon2, pas SHA-256 ni MD5.

La répartition géographique des comptes touchés place les États-Unis en tête, suivis par l’Allemagne, les Pays-Bas, la France, la Turquie et le Royaume-Uni. Une partie significative des utilisateurs exposés relève donc directement du RGPD, ce qui transforme un incident de cybercriminalité en cas d’école pour les responsables de la conformité en Europe.

Un CPU à 2 100 dollars plus rapide qu’un rig à 8 GPU

C’est le fait le plus troublant de l’année pour les défenseurs d’Argon2. L’étude publiée par Specops et relayée par Finopotamus en juillet 2026 montre qu’une configuration à base d’un seul processeur haut de gamme, coûtant environ 2 100 dollars, casse des hashs Argon2 plus rapidement qu’une ferme de huit cartes graphiques. La raison tient à la conception même d’Argon2 : sa dépendance à la mémoire vive pénalise les GPU, dont l’architecture privilégie un grand nombre de cœurs simples avec peu de mémoire cache par cœur. Un CPU moderne, avec ses larges caches et son accès rapide à la RAM, s’en sort donc mieux sur ce type de charge que le matériel habituellement associé au cracking de mots de passe.

Dans la foulée de cette étude, Specops a annoncé l’ajout de plus de 60 millions de mots de passe compromis à son service Breached Password Protection. Le signal envoyé aux équipes sécurité est simple : la résistance d’Argon2 au matériel spécialisé n’élimine pas le risque, elle le déplace. Le paramétrage de l’algorithme, et la robustesse des mots de passe eux-mêmes, comptent autant que l’algorithme choisi.

Ce que dit la recherche : 46,99 % de compromissions en moins face à SHA-256

Une étude de simulation d’attaques publiée sur arXiv quantifie l’avantage d’Argon2 configuré selon les recommandations de la RFC 9106, avec 2 048 Mio de mémoire allouée. Face à un budget d’attaque équivalent à 20 unités de calcul, les chercheurs mesurent une réduction de 46,99 % du taux de compromission par rapport à un schéma reposant sur SHA-256. Le gain n’est pas anecdotique : il illustre concrètement pourquoi les autorités de régulation poussent vers des fonctions dédiées au hachage de mots de passe plutôt que vers des fonctions de hachage génériques, plus rapides mais moins adaptées à cet usage précis.

Le paramètre mémoire est celui qui pèse le plus lourd dans cette équation. Plus la mémoire allouée par calcul de hash est élevée, plus il devient coûteux de paralléliser une attaque, puisque chaque tentative de mot de passe mobilise plusieurs centaines de mégaoctets. C’est ce facteur qui explique pourquoi un serveur bien dimensionné reste largement plus difficile à attaquer qu’un forum mal configuré, même si les deux utilisent nominalement le même algorithme.

L’ANSSI rend Argon2 quasi obligatoire dès mars 2026

Le 20 mars 2026, l’ANSSI a publié la version 3.00 de son guide des mécanismes cryptographiques. Le texte précise que, pour le stockage des identifiants et mots de passe, l’usage de fonctions de hachage dédiées, à savoir bcrypt ou Argon2, est requis. Cette exigence s’inscrit dans la continuité de l’article 32 du RGPD sur la sécurité des traitements de données personnelles, et elle vise directement les organismes qui utilisent encore des fonctions de hachage génériques comme SHA-256 pour protéger des mots de passe.

Le guide ne se limite pas à recommander un algorithme. Il met en garde contre les erreurs d’implémentation qui dégradent fortement la sécurité malgré un bon choix théorique : mauvais paramétrage de la mémoire ou du nombre d’itérations, absence de sel unique par utilisateur, ou gestion incorrecte des coûts de calcul. Un déploiement d’Argon2 mal réglé peut, dans les faits, offrir une protection proche de celle d’un simple hachage SHA-256, ce que confirme l’écart de résultats observé entre différentes implémentations en conditions réelles.

Argon2 vs bcrypt vs scrypt vs PBKDF2 : le comparatif

Le paysage des fonctions de hachage de mots de passe compte quatre acteurs principaux encore en usage actif en 2026. Chacun répond à une génération différente de menaces, et chacun garde des cas d’usage légitimes malgré l’avantage général d’Argon2.

Algorithme	Année	Résistance GPU/ASIC	Mémoire configurable	Statut ANSSI/OWASP 2026
Argon2id	2015 (RFC 9106 en 2021)	Élevée	Oui, paramètre dédié	Recommandé par défaut
bcrypt	1999	Moyenne	Non (facteur de coût uniquement)	Accepté
scrypt	2009	Élevée	Oui	Accepté
PBKDF2	2000 (NIST)	Faible	Non	Toléré pour compatibilité
SHA-256 seul	2001 (NIST)	Très faible	Non	Déconseillé pour mots de passe

bcrypt reste largement déployé, notamment dans les frameworks web plus anciens, et il conserve une résistance correcte grâce à son facteur de coût ajustable. Sa limite tient à l’absence de paramètre mémoire, ce qui le rend plus vulnérable au calcul massivement parallèle que Argon2 ou scrypt. PBKDF2, encore présent dans certains standards fédéraux américains, souffre du même défaut structurel : sa dépendance quasi nulle à la mémoire en fait une cible plus abordable pour un attaquant équipé de GPU récents. Quant à SHA-256 utilisé seul, sans dérivation dédiée, il n’a jamais été conçu pour cet usage et son emploi pour du hachage de mots de passe est désormais explicitement déconseillé par la plupart des référentiels de sécurité européens.

Contexte historique : de MD5 à Argon2, une décennie de ruptures

L’histoire du hachage de mots de passe est une suite de corrections après incidents. MD5, conçu en 1992, a été abandonné pour les mots de passe dès les années 2000 face à la puissance croissante des cartes graphiques dédiées au cracking. SHA-1 a suivi un chemin similaire, jusqu’à sa mise à mort symbolique avec la démonstration de collision pratique SHAttered en 2017. bcrypt, sorti dès 1999, a longtemps constitué la référence pragmatique du secteur, avant que scrypt, en 2009, n’introduise la notion de coût mémoire pour contrer le matériel spécialisé.

Argon2 est né d’un concours ouvert, la Password Hashing Competition, lancée en 2013 et remportée par l’algorithme en 2015. Sa standardisation par l’IETF sous la RFC 9106 en 2021 a marqué son passage du statut de recommandation académique à celui de référence normative, reprise ensuite par l’OWASP puis, en 2026, par l’ANSSI dans son guide de mars. Onze ans après le début de la compétition qui l’a fait naître, Argon2 reste non cassé sur le plan cryptographique. Ce que montrent BreachForums et l’étude Specops, en revanche, c’est que la résistance théorique d’un algorithme ne protège rien si son paramétrage ou l’hygiène des mots de passe des utilisateurs est défaillante.

Impact sur les entreprises européennes : un coût de mise en conformité

Pour les entreprises françaises et européennes, le guide ANSSI de mars 2026 transforme une bonne pratique en quasi-obligation documentaire. Les organismes soumis à des audits de sécurité, ou à des contrôles de la CNIL après un incident, devront désormais justifier explicitement leur choix d’algorithme de hachage. Utiliser encore SHA-256 seul ou MD5 pour des mots de passe expose à un risque de qualification de manquement à l’article 32 du RGPD, avec un facteur aggravant en cas de fuite avérée.

Ce mouvement réglementaire crée aussi un argument commercial pour les éditeurs de gestionnaires de mots de passe et de solutions d’authentification basés en Europe. Mettre en avant une conformité RFC 9106 et un paramétrage Argon2id documenté devient un critère de choix pour les acheteurs publics et privés, au même titre que l’hébergement des données sur le sol européen l’est devenu ces dernières années. À l’inverse, les plateformes qui n’ont pas encore migré vers Argon2 ou bcrypt s’exposent à un coût de mise en conformité technique et juridique qui grimpe à mesure que les contrôles se resserrent.

RGPD et responsabilité juridique du choix de hachage

L’article 32 du RGPD impose des mesures techniques et organisationnelles appropriées au risque. Le guide ANSSI vient préciser ce que « approprié » signifie concrètement pour le stockage de mots de passe en 2026 : une fonction dédiée, correctement paramétrée. En cas de fuite de données, pouvoir démontrer l’usage d’Argon2 avec des paramètres conformes aux guides ANSSI ou ENISA peut réduire la gravité perçue de la violation par les autorités de contrôle, notamment sur la question de la proportionnalité des mesures de sécurité mises en œuvre avant l’incident.

L’inverse est également vrai. Une entreprise qui subit une fuite tout en utilisant encore un hachage générique non salé prend un risque juridique direct, indépendamment de l’ampleur technique de l’incident. Le cas BreachForums illustre d’ailleurs un point souvent négligé : même un algorithme conforme aux recommandations ne dispense pas d’une politique de mots de passe robuste, car un mot de passe faible ou réutilisé reste cassable quel que soit l’algorithme employé pour le protéger.

Les erreurs d’implémentation qui annulent les bénéfices d’Argon2

Le guide ANSSI liste plusieurs pièges récurrents. Le premier concerne le paramétrage mémoire trop faible, souvent choisi pour ne pas ralentir des serveurs déjà sous tension, ce qui réduit mécaniquement le coût d’une attaque. Le deuxième touche à l’absence de sel unique par utilisateur, une erreur qui permet à un attaquant de précalculer des tables d’attaque communes à plusieurs comptes. Le troisième concerne la gestion incohérente des coûts de calcul entre environnements de développement et de production, qui aboutit parfois à des configurations de test allégées oubliées en production.

Paramètres Argon2id recommandés selon les cas d’usage

L’OWASP et la RFC 9106 proposent des profils de paramétrage adaptés à différents contextes serveur. Le tableau suivant résume les recommandations les plus citées pour Argon2id.

Cas d’usage	Mémoire	Itérations	Parallélisme	Source
Recommandation minimale OWASP	19 Mio	2	1	OWASP Password Storage Cheat Sheet
Serveur dédié, forte mémoire disponible	2 048 Mio	1	4	RFC 9106 (IETF)
Environnement contraint en mémoire	64 Mio	3	4	RFC 9106 (IETF)

Le choix entre ces profils dépend directement des ressources disponibles côté serveur. Une plateforme qui traite un fort volume de connexions simultanées privilégiera un profil moins gourmand en mémoire mais plus itératif, tandis qu’un service critique avec un trafic d’authentification plus faible pourra se permettre l’allocation mémoire maximale recommandée par la RFC 9106, plus coûteuse à casser.

Implémenter Argon2id correctement en Node.js

La bibliothèque argon2 pour Node.js expose directement les paramètres recommandés par la RFC 9106. Voici un exemple minimal de hachage conforme aux profils décrits plus haut.

const argon2 = require('argon2');

async function hasherMotDePasse(motDePasse) {
  return argon2.hash(motDePasse, {
    type: argon2.argon2id,
    memoryCost: 19456, // 19 Mio, profil OWASP minimal
    timeCost: 2,
    parallelism: 1,
  });
}

async function verifierMotDePasse(hash, motDePasse) {
  return argon2.verify(hash, motDePasse);
}

Le sel est généré automatiquement par la bibliothèque à chaque appel de argon2.hash, ce qui évite l’erreur la plus commune signalée par l’ANSSI : la réutilisation d’un sel fixe entre plusieurs comptes. Les équipes qui migrent depuis bcrypt ou PBKDF2 peuvent conserver les anciens hashs et ne recalculer un hash Argon2id qu’au moment de la prochaine connexion réussie de l’utilisateur, une stratégie de migration progressive qui évite de forcer une réinitialisation massive des mots de passe.

Ce que ça change pour les gestionnaires de mots de passe

Les principaux gestionnaires de mots de passe utilisés en Europe, dont Bitwarden et Proton Pass, s’appuient déjà sur Argon2id ou PBKDF2 à itérations élevées pour dériver la clé de chiffrement du coffre à partir du mot de passe maître. La pression réglementaire de 2026 renforce l’intérêt de ces solutions pour les utilisateurs finaux, puisqu’un mot de passe maître unique et robuste, combiné à un algorithme correctement paramétré côté client, réduit fortement la surface d’attaque par rapport à des mots de passe réutilisés sur plusieurs services.

Ce constat rejoint directement l’incident BreachForums : la robustesse d’Argon2 protège contre le cracking brut, mais elle ne protège pas un utilisateur qui choisit un mot de passe court ou déjà présent dans une base de données compromise. C’est précisément ce que visent les 60 millions de mots de passe ajoutés par Specops à son service de détection, une liste construite à partir de fuites précédentes pour bloquer leur réutilisation avant qu’un attaquant n’ait même besoin de casser un hash.

Prédictions : ce qui attend Argon2 d’ici 2027-2030

D’ici 2027, l’ANSSI pourrait durcir sa position et transformer la recommandation Argon2/bcrypt en obligation stricte pour les organismes soumis à un référentiel de sécurité, suivant la même trajectoire que sa politique de certification post-quantique.
Les outils de cracking open source vont continuer d’optimiser leurs implémentations CPU pour Argon2, ce qui devrait réduire encore l’écart de coût entre attaque CPU et GPU observé par Specops en 2026.
Les éditeurs européens de gestionnaires de mots de passe vont afficher leur conformité RFC 9106 comme argument de vente face à la pression réglementaire croissante sur le traitement des données personnelles.
D’autres fuites du type BreachForums vont continuer de démontrer qu’un bon algorithme ne compense pas des mots de passe faibles, accélérant l’adoption des passkeys comme alternative à l’authentification par mot de passe seul.
Les autorités de contrôle nationales pourraient commencer à citer explicitement l’usage d’algorithmes génériques comme SHA-256 ou MD5 pour des mots de passe comme facteur aggravant lors de la notification de violations de données.

FAQ : les questions les plus posées sur Argon2

Argon2 est-il cassé après la fuite BreachForums ?

Non. L’algorithme lui-même n’a fait l’objet d’aucune faille cryptographique publiée. La fuite expose des hashs Argon2, pas une rupture de l’algorithme, et le cracking effectif dépend ensuite de la robustesse des mots de passe sous-jacents et du paramétrage choisi par l’exploitant du service.

Argon2 ou bcrypt pour un nouveau projet en 2026 ?

Argon2id est le choix recommandé par défaut par l’OWASP et désormais cité en premier par l’ANSSI. bcrypt reste acceptable, notamment pour des raisons de compatibilité avec un écosystème existant, mais il n’offre pas de paramètre mémoire configurable.

Pourquoi un CPU peut-il casser Argon2 plus vite qu’un GPU ?

Argon2 est conçu pour consommer beaucoup de mémoire à chaque calcul de hash. Les GPU, optimisés pour le calcul parallèle avec peu de mémoire cache par cœur, sont pénalisés par cette contrainte, tandis qu’un CPU haut de gamme avec un grand cache peut traiter ces calculs plus efficacement, selon l’étude Specops de juillet 2026.

Le RGPD impose-t-il Argon2 explicitement ?

Le texte du RGPD ne cite aucun algorithme par son nom. C’est le guide ANSSI du 20 mars 2026 qui précise, pour la France, que les fonctions dédiées comme Argon2 ou bcrypt répondent à l’exigence de mesures appropriées de l’article 32.

Faut-il migrer immédiatement de SHA-256 vers Argon2 ?

Oui, si SHA-256 est utilisé seul pour hacher des mots de passe sans dérivation dédiée. Une migration progressive, qui recalcule le hash Argon2 à la prochaine connexion réussie de chaque utilisateur, évite de forcer une réinitialisation massive tout en réduisant le risque.

Quels paramètres Argon2 choisir pour un site à fort trafic ?

Un profil proche du minimum OWASP, avec 19 Mio de mémoire, deux itérations et un parallélisme de un, offre un bon compromis entre sécurité et charge serveur. Les sites avec moins de trafic d’authentification peuvent monter jusqu’au profil RFC 9106 à 2 048 Mio.

Argon2 protège-t-il contre la réutilisation de mots de passe ?

Non. Argon2 protège contre le cracking d’un hash volé, pas contre la réutilisation d’un mot de passe déjà compromis ailleurs. C’est pour cette raison que des services comme Specops Breached Password Protection croisent les mots de passe choisis avec des bases de fuites connues.

Les entreprises françaises risquent-elles une sanction CNIL pour un mauvais choix de hachage ?

En cas de fuite de données, l’usage d’un algorithme jugé inapproprié au regard des recommandations ANSSI peut constituer un facteur aggravant dans l’évaluation d’un manquement à l’article 32 du RGPD, même si la CNIL statue au cas par cas selon le contexte de chaque incident.