Argon2 vs bcrypt vs scrypt : choisir un KDF de mots de passe en 2026

Si vous choisissez comment stocker des mots de passe, la décision se résume à une propriété que la plupart des tableaux comparatifs enterrent : la dureté mémoire. Le nombre d'itérations ralentit un CPU. La dureté mémoire, elle, déjoue le matériel que l'attaquant possède réellement. Posez bien ce cadre et le reste du choix en découle presque mécaniquement.

Pourquoi la dureté mémoire fait tout le jeu

Un attaquant qui casse votre base de mots de passe ne la fait pas tourner sur un portable. Il la fait tourner sur un rack de GPU, ou pour une cible de grande valeur, des ASIC sur mesure. Ces machines ont une puissance parallèle stupéfiante et très peu de mémoire rapide par cœur. Un schéma de pure itération joue directement sur cette force : des milliers de cœurs qui moulinent chacun la même boucle bon marché.

Une fonction dure en mémoire casse cela. Elle force chaque essai à allouer et parcourir un grand bloc de RAM. Soudain, le goulot de l'attaquant n'est plus le calcul, c'est la bande passante et la capacité mémoire, la seule ressource qui ne se réplique pas à bas coût sur des milliers de cœurs parallèles. C'est pourquoi un hash dur en mémoire bien paramétré est la seule chose de cette liste qui pousse un attaquant sérieux à simplement renoncer.

argon2id et ses trois boutons

Argon2 a remporté la Password Hashing Competition pour de bonnes raisons, et argon2id est la variante à choisir (elle mêle la résistance aux canaux auxiliaires d'argon2i et la résistance GPU d'argon2d). Elle expose trois paramètres, et il faut comprendre les trois :

• m est la mémoire en Kio. C'est le paramètre important. Plus de mémoire, plus de douleur pour l'attaquant. 64 Mio à 128 Mio par hash est une cible serveur raisonnable.
• t est le coût en temps, le nombre de passes sur la mémoire. Relevez-le quand vous ne pouvez pas vous offrir plus de mémoire.
• p est le parallélisme, le nombre de voies. Ajustez-le grossièrement aux cœurs que vous pouvez consacrer par authentification.

Le hash encodé porte tout cela, donc vous lisez les paramètres directement dans la valeur stockée et vous pouvez les relever plus tard sans casser les anciens hash.

bcrypt : vieux, toujours bon, un seul bouton

bcrypt date de 1999 et il a remarquablement bien vieilli. Il a un unique facteur de coût, le facteur de travail dans le préfixe $2b$12$, où 12 signifie 2^12 itérations de sa cédule de clé. Il n'est pas formellement dur en mémoire, mais sa conception est volontairement hostile au cache, raison pratique pour laquelle bcrypt résiste aux GPU bien mieux que son âge ne le laisse croire. Sa vraie limite est la troncature du mot de passe à 72 octets, qui compte si vous autorisez des phrases de passe très longues ou si vous pré-hachez les entrées sans soin. Pour la plupart des applications, bcrypt au coût 12 ou plus est parfaitement correct. Ne l'arrachez pas juste parce qu'argon2 existe.

scrypt : dur en mémoire, capricieux à régler

scrypt est arrivé avant Argon2 et il est dur en mémoire par conception. Il a trois paramètres qui interagissent d'une manière souvent mal comprise : N est le coût CPU/mémoire (une puissance de deux, c'est lui qui pilote l'usage mémoire), r est la taille de bloc, et p le parallélisme. Le piège, c'est que le réglage est moins intuitif qu'argon2id, et beaucoup de déploiements choisissent des N trop faibles et perdent en silence la dureté mémoire qu'ils croyaient avoir. scrypt convient si vous l'utilisez déjà correctement. Si vous partez de zéro, argon2id est plus facile à régler juste.

PBKDF2 : le plus faible des quatre

PBKDF2-SHA256 n'est qu'un HMAC itéré. Aucun coût mémoire, rien. Cela en fait, et de loin, le schéma le plus favorable au GPU de cette liste, et un attaquant casse PBKDF2 nettement plus vite que les trois autres à effort égal. Il survit parce qu'il est partout : approuvé FIPS, ancré dans d'innombrables normes et schémas de chiffrement de disque. Si un régime de conformité vous impose PBKDF2, poussez très haut le nombre d'itérations (des centaines de milliers d'itérations SHA-256, davantage si possible) et sachez que vous achetez du temps, pas de la force.

Réglez pour 250 à 500 millisecondes

Quel que soit votre choix, la cible de calibration est la même : chaque hash doit prendre environ 250 à 500 millisecondes sur votre matériel de production. C'est imperceptible pour l'utilisateur qui se connecte et brutal pour l'attaquant qui le fait des milliards de fois. Mesurez sur la vraie machine, pas sur votre portable, et remesurez à chaque montée de matériel. Avec argon2id, dépensez d'abord le budget sur m avant t. Avec bcrypt, relevez le facteur de coût jusqu'à atteindre la latence cible. Le but est de consommer tout votre budget de latence, car chaque milliseconde laissée de côté est une milliseconde d'accélération offerte à l'attaquant.

La réalité du cassage, et que choisir

Voici la partie qui devrait rassurer les défenseurs. Ces quatre fonctions sont lentes à dessein, ce qui veut dire que l'arithmétique des hash rapides contre lents joue entièrement en votre faveur. Contre un argon2id bien paramétré, un attaquant obtient une poignée d'essais par seconde et par GPU. Une vraie session de cassage là-dessus n'est pas un passage de dictionnaire, c'est la décision de renoncer à tout sauf aux mots de passe vraiment faibles, et même ceux-là tombent lentement.

Donc la recommandation, dite franchement : prenez argon2id pour tout ce qui est nouveau, réglé à 64 Mio ou plus et une latence de 250 à 500 ms. Gardez bcrypt au coût 12 et plus si vous l'avez déjà, rien ne presse de migrer. N'utilisez scrypt que si vous le faites déjà tourner avec des paramètres sains. Ne recourez à PBKDF2 que lorsqu'une contrainte externe vous y force. De toute façon, le coup le plus fort que vous puissiez jouer n'est pas l'algorithme, c'est de bien le paramétrer et de laisser les mots de passe être longs.