Faut-il choisir bcrypt ou Argon2 ?

Argon2id pour les nouveaux systèmes : il a remporté la Password Hashing Competition et il est memory-hard, ce qui rend le cassage par GPU et ASIC bien plus coûteux. bcrypt reste acceptable et très largement pris en charge, gardez-le donc si votre stack l’utilise déjà.

Pourquoi le hash change-t-il à chaque fois pour le même mot de passe ?

Chaque hash utilise un nouveau sel aléatoire, donc le résultat change à chaque fois. C’est voulu. Pour contrôler un mot de passe, vérifiez-le avec le hash stocké au lieu de comparer deux hashes fraîchement générés.

Peut-on déchiffrer un hash bcrypt ou Argon2 ?

Non. Ce sont des fonctions à sens unique. Le seul moyen de retrouver le mot de passe est d’essayer des candidats et de hacher chacun d’eux, ce que ces algorithmes rendent volontairement lent.

Qu’est-ce que la limite de 72 octets de bcrypt ?

bcrypt n’utilise que les 72 premiers octets du mot de passe. Ce qui suit n’influence pas le hash, donc deux longs mots de passe partageant leurs 72 premiers octets produisent des hashes qui correspondent. Argon2 n’a pas cette limite.

Quel facteur de coût choisir pour bcrypt ?

Au moins 10, et 12 est une valeur par défaut courante. Chaque incrément double le travail. Choisissez la valeur la plus élevée qui garde une connexion suffisamment rapide sur votre serveur.

Les hashes bcrypt $2a$, $2b$ et $2y$ sont-ils compatibles ?

Oui, pour les mots de passe jusqu’à 72 octets, ils produisent le même hash. La plupart des bibliothèques acceptent les trois préfixes, et cet outil les vérifie tous.

Pourquoi la vérification prend-elle autant de temps que le hachage ?

Vérifier consiste à hacher de nouveau le mot de passe avec le sel et les paramètres stockés dans le hash, puis à comparer les résultats : cela coûte exactement le même travail. C’est ce qui rend les tentatives coûteuses.

Le mot de passe est-il envoyé à un serveur ?

Non. bcrypt et Argon2 s’exécutent en WebAssembly dans votre navigateur. Rien de ce que vous saisissez ne quitte la page.

Générateur de hash bcrypt et Argon2 avec vérification

Hachez un mot de passe avec bcrypt ou Argon2, ou comparez-le à un hash stocké

Ce générateur de hash de mots de passe crée des hashes bcrypt (<code>$2b$</code>, coût de 4 à 15) ainsi que des hashes Argon2id, Argon2i et Argon2d au format standard de chaîne PHC, avec la mémoire, les itérations, le parallélisme, le sel et la taille de sortie de votre choix. Passez en mode <strong>Vérifier</strong> pour coller un hash de votre base de données, en reconnaître l’algorithme et les paramètres grâce au préfixe, et tester si un mot de passe correspond. Chaque hash utilise un nouveau sel aléatoire et indique le temps pris sur votre appareil. Le hachage s’exécute en WebAssembly dans votre navigateur ; le mot de passe n’est jamais envoyé.

Comment générer un hash bcrypt ou Argon2

1Choisissez Hacher, puis l’algorithme : Argon2id pour un nouveau système, bcrypt pour correspondre à un système existant.
2Réglez le coût : un facteur de coût bcrypt, ou un préréglage Argon2 comme OWASP 19 MiB, t=2. Ajustez à la main la mémoire, les itérations et le parallélisme si vous devez reproduire une configuration.
3Saisissez le mot de passe et cliquez sur Hacher le mot de passe. Le hash encodé, ses parties et le temps pris s’affichent en dessous.
4Pour contrôler un hash, choisissez Vérifier, collez le hash stocké et le mot de passe, puis cliquez sur Vérifier.

Pourquoi les mots de passe exigent un hachage lent

Un hash rapide comme SHA-256 n’est pas adapté aux mots de passe. Une seule carte graphique calcule des milliards de hashes SHA-256 par seconde, si bien qu’une table de hashes SHA-256 de mots de passe divulguée peut être devinée à ce rythme. Les fonctions de hachage de mots de passe sont conçues pour être lentes et, dans le cas d’Argon2, pour nécessiter beaucoup de mémoire, afin que chaque tentative coûte du temps et du matériel réels. Un réglage qui prend un quart de seconde sur votre serveur coûte à un attaquant ce même quart de seconde pour chaque tentative, pour chaque utilisateur.

Chaque hash porte aussi son propre sel aléatoire : deux utilisateurs ayant le même mot de passe obtiennent des hashes différents et les tables précalculées deviennent inutiles. Le sel et tous les paramètres sont stockés dans la chaîne du hash, c’est pourquoi une bibliothèque peut vérifier un mot de passe à partir du hash seul.

Lire un hash bcrypt

Un hash bcrypt comme $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW comporte quatre parties : la version 2b, le coût 12 (2¹² = 4 096 tours d’expansion de clé), un sel de 22 caractères et un hash de 31 caractères, tous deux dans l’alphabet Base64 propre à bcrypt. Chaque cran de coût supplémentaire double le temps.

$2a$ , $2b$ et $2y$ donnent le même résultat pour les mots de passe jusqu’à 72 octets ; les lettres signalent des corrections de bugs d’anciennes implémentations. bcrypt ne lit que les 72 premiers octets d’un mot de passe et ignore le reste, ce que cet outil signale — une longue phrase de passe, ou un mot de passe dans une écriture non latine où un caractère occupe deux à quatre octets, peut atteindre cette limite plus vite que prévu.

Argon2id, Argon2i et Argon2d

La chaîne PHC contient tout ce qu’il faut pour vérifier : $argon2id$v=19$m=19456,t=2,p=1$<salt>$<hash> signifie version 1.3, 19 456 Kio de mémoire, 2 passes et 1 voie, suivis du sel et du hash en Base64 sans remplissage.

Argon2id: L’hybride des deux variantes ci-dessous, et celle que la RFC 9106 et l’OWASP recommandent pour stocker les mots de passe. Utilisez-la sauf contrainte particulière.
Argon2i: Accès mémoire indépendant du mot de passe, ce qui résiste aux attaques par canal auxiliaire, mais plus faible face au cassage par GPU avec peu de passes.
Argon2d: L’accès mémoire dépend du mot de passe : le plus robuste face aux GPU, mais exposé aux canaux auxiliaires. Adapté à la preuve de travail, pas aux serveurs qui vérifient des connexions.

Réglages recommandés

Argon2id : l’OWASP recommande 19 MiB de mémoire avec 2 itérations et un parallélisme de 1, ou un compromis équivalent comme 47 MiB avec 1 itération ou 12 MiB avec 3. La RFC 9106 suggère 64 MiB, 3 itérations et 4 voies si la mémoire le permet.
bcrypt : un coût d’au moins 10 ; 12 est aujourd’hui une valeur par défaut courante. Choisissez le coût le plus élevé que votre endpoint de connexion peut supporter — environ 250 ms par hash sur le serveur est un objectif raisonnable.
Sel : 16 octets aléatoires. Longueur du hash : 32 octets suffisent largement.
Le temps mesuré ici l’est sur votre appareil, en WebAssembly, généralement plus lent qu’une bibliothèque native sur un serveur. Faites un benchmark sur votre matériel de production avant de fixer un coût.

Quand utiliser cet outil

Utilisez-le pour créer un hash destiné à un utilisateur de seed ou à un fichier de configuration, pour vérifier qu’un hash de votre base de données correspond bien au mot de passe que vous pensez, ou pour savoir avec quels paramètres un hash existant a été créé. Votre application doit hacher les mots de passe avec sa propre bibliothèque à l’inscription ; elle ne doit jamais envoyer des mots de passe en clair à un site web pour les hacher. Pour créer d’abord un mot de passe robuste, utilisez le générateur de mots de passe ; pour des signatures à clé plutôt que du stockage de mots de passe, voyez le générateur HMAC.

Questions fréquentes

Faut-il choisir bcrypt ou Argon2 ?: Argon2id pour les nouveaux systèmes : il a remporté la Password Hashing Competition et il est memory-hard, ce qui rend le cassage par GPU et ASIC bien plus coûteux. bcrypt reste acceptable et très largement pris en charge, gardez-le donc si votre stack l’utilise déjà.
Pourquoi le hash change-t-il à chaque fois pour le même mot de passe ?: Chaque hash utilise un nouveau sel aléatoire, donc le résultat change à chaque fois. C’est voulu. Pour contrôler un mot de passe, vérifiez-le avec le hash stocké au lieu de comparer deux hashes fraîchement générés.
Peut-on déchiffrer un hash bcrypt ou Argon2 ?: Non. Ce sont des fonctions à sens unique. Le seul moyen de retrouver le mot de passe est d’essayer des candidats et de hacher chacun d’eux, ce que ces algorithmes rendent volontairement lent.
Qu’est-ce que la limite de 72 octets de bcrypt ?: bcrypt n’utilise que les 72 premiers octets du mot de passe. Ce qui suit n’influence pas le hash, donc deux longs mots de passe partageant leurs 72 premiers octets produisent des hashes qui correspondent. Argon2 n’a pas cette limite.
Quel facteur de coût choisir pour bcrypt ?: Au moins 10, et 12 est une valeur par défaut courante. Chaque incrément double le travail. Choisissez la valeur la plus élevée qui garde une connexion suffisamment rapide sur votre serveur.
Les hashes bcrypt $2a$, $2b$ et $2y$ sont-ils compatibles ?: Oui, pour les mots de passe jusqu’à 72 octets, ils produisent le même hash. La plupart des bibliothèques acceptent les trois préfixes, et cet outil les vérifie tous.
Pourquoi la vérification prend-elle autant de temps que le hachage ?: Vérifier consiste à hacher de nouveau le mot de passe avec le sel et les paramètres stockés dans le hash, puis à comparer les résultats : cela coûte exactement le même travail. C’est ce qui rend les tentatives coûteuses.
Le mot de passe est-il envoyé à un serveur ?: Non. bcrypt et Argon2 s’exécutent en WebAssembly dans votre navigateur. Rien de ce que vous saisissez ne quitte la page.