Stockez les mots de passe avec Argon2id, configuré avec au moins 19 MiB de mémoire, 2 itérations et un degré de parallélisme de 1, avec un sel unique par mot de passe. C'est la configuration minimale de l'OWASP Password Storage Cheat Sheet. Si votre base contient encore des hash MD5, SHA-1 ou sans sel, vous pouvez corriger la situation sans réinitialisation massive des mots de passe, et sans laisser de hash faibles derrière vous pour les comptes dormants.
Quoi utiliser, et avec quels paramètres minimaux
Le cheat sheet donne les minimums suivants :
| Situation | Algorithme | Paramètres minimaux |
|---|---|---|
| Recommandé | Argon2id | 19 MiB de mémoire, 2 itérations, parallélisme 1 |
| Argon2id indisponible | scrypt | paramètre de coût 2^17, taille de bloc 8, parallélisme 1 |
| Systèmes hérités sous bcrypt | bcrypt | facteur de travail de 10 ou plus, limite de mot de passe de 72 octets |
| Conformité FIPS-140 exigée | PBKDF2 | 600 000 ou plus, HMAC-SHA-256 |
Argon2id est la variante principale de la RFC 9106, et toute implémentation de ce document doit la prendre en charge. Il se comporte comme Argon2i pendant la première moitié du premier passage sur la mémoire, puis comme Argon2d pour le reste.
La limite de 72 octets de bcrypt
Le cheat sheet fixe une limite de 72 octets pour les mots de passe avec bcrypt. Les sources ne précisent pas comment chaque bibliothèque traite une entrée plus longue : testez donc la vôtre. Hachez un mot de passe composé de 72 caractères a suivis d'un b, puis vérifiez 72 caractères a suivis d'un c. Si la vérification réussit, votre bibliothèque tronque silencieusement.
Ensuite, soit vous plafonnez la longueur des mots de passe à 72 octets dans vos formulaires en l'indiquant clairement, soit vous planifiez la migration vers Argon2id. La RFC 9106 autorise des mots de passe allant jusqu'à 2^32-1 octets.
Pourquoi les hash rapides échouent
MD5 et SHA-1 ont été conçus pour être rapides, et SHA-256 est inadapté pour la même raison : il permet à un attaquant de tester un grand nombre de candidats très vite. L'attaquant hache des candidats issus de listes de mots de passe divulguées, de dictionnaires ou d'une attaque par force brute, puis compare les résultats avec vos lignes. Les GPU et les serveurs cloud loués rendent cette opération peu coûteuse.
Un sel unique oblige l'attaquant à casser les hash un par un. Il neutralise aussi les rainbow tables, et deux mots de passe identiques ne produisent plus des hash identiques. La RFC 9106 recommande un sel de 16 octets pour le hachage de mots de passe. Les bibliothèques éprouvées génèrent et stockent le sel à votre place : n'écrivez donc pas cette partie à la main.
Régler le facteur de travail
Il n'existe pas de valeur universelle. Elle dépend de votre serveur et du nombre de vos utilisateurs, et on la trouve par l'expérimentation sur le matériel que vous exploitez. La règle générale est qu'un hash doit prendre moins d'une seconde.
Viser trop haut a un prix. Chaque tentative de connexion consomme du CPU, et un afflux de tentatives peut épuiser le serveur. Faites vos benchmarks avec une concurrence réaliste et choisissez une valeur que vous pouvez vous permettre en pic de charge.
Vérifiez l'unité attendue par votre bibliothèque Argon2. La RFC 9106 définit la taille de mémoire en kibioctets, alors que le cheat sheet cite des MiB. 19 MiB correspondent à 19456 KiB, et si vous passez 19 là où la bibliothèque attend des KiB, vous obtenez 19 KiB de mémoire. Ce réglage fonctionne, mais il est bien plus faible que prévu.
Le facteur de travail est généralement stocké dans la sortie du hash. C'est utile pour la migration : à la connexion, vous voyez avec quels paramètres un hash donné a été créé.
Le pepper comme couche supplémentaire
Un pepper est un secret commun à tous les mots de passe stockés, conservé en dehors de la base de données, dans un coffre-fort de secrets ou un HSM. Il est utile lorsqu'un attaquant n'obtient que la base, par injection SQL ou via une sauvegarde volée. Seul, il n'apporte rien : considérez-le comme de la défense en profondeur.
Le problème, c'est la rotation. Un pepper compromis ne peut pas être changé sans connaître le mot de passe de chaque utilisateur, donc le remplacer impose une réinitialisation à tous ceux qu'il protégeait. Décidez qui est responsable de cette procédure avant d'introduire un pepper.
Mettre à niveau les anciens hash
L'approche du cheat sheet pour relever un facteur de travail consiste à attendre la prochaine authentification de l'utilisateur, puis à re-hacher son mot de passe avec les nouveaux paramètres. Le passage depuis MD5, SHA-1 ou des hash sans sel suit la même logique, bien que cette extension soit de notre fait.
- Marquez chaque hash stocké avec son algorithme, dans une colonne distincte ou via le format du hash. Si vous avez un doute sur le contenu de la table, l'identificateur de hash vous aide à reconnaître les formats.
- À la connexion, vérifiez avec l'algorithme qu'utilise le hash stocké.
- En cas de succès, si le hash est hérité ou inférieur à vos paramètres actuels, calculez un nouveau hash Argon2id à partir du mot de passe soumis, avec un sel neuf.
- Écrasez l'ancienne valeur dans la même opération.
ok = verify(row.scheme, row.hash, submitted)
if ok and (row.scheme != "argon2id" or needs_rehash(row.hash)):
row.hash = argon2id_hash(submitted) # fresh salt, current parameters
row.scheme = "argon2id"
save(row)Comptes dormants
Les utilisateurs qui ne se reconnectent jamais ne sont jamais mis à niveau, et leurs hash faibles restent donc indéfiniment dans la table. Une solution consiste à les envelopper dès maintenant. Appliquez Argon2id à la valeur MD5 ou SHA-1 existante, stockez le résultat avec un marqueur de schéma tel que argon2id(md5), puis supprimez le hash brut.
À la connexion, vous calculez le hash hérité du mot de passe soumis, vous le vérifiez par rapport à l'enveloppe Argon2id et, en cas de succès, vous remplacez l'enveloppe par un hash Argon2id simple. Consignez précisément l'encodage de la valeur héritée (hexadécimal ou octets bruts), car une incohérence casse toutes les connexions de ce schéma. Testez d'abord le chemin enveloppé sur une copie de la table.
L'enveloppe ne rend pas un mot de passe faible plus robuste. Elle empêche seulement qu'une table volée soit attaquée à la vitesse de MD5.
L'alternative consiste à supprimer les anciens hash après une date limite et à exiger une réinitialisation à la prochaine connexion, ce que le cheat sheet décrit comme une option selon l'application. Si la modification touche une base de code que vous ne maîtrisez pas entièrement, notre équipe de développement logiciel sécurisé peut la passer en revue.
Par où commencer
- Auditez la table des utilisateurs : quels algorithmes, présence ou non de sels, et si certains mots de passe sont en clair ou chiffrés de façon réversible. Le chiffrement n'est acceptable que si vous devez pouvoir retrouver le mot de passe d'origine, et le cheat sheet recommande d'éviter ce besoin.
- Choisissez Argon2id avec au moins 19456 KiB, 2 itérations et un parallélisme de 1, et faites un benchmark sur le matériel de production jusqu'à ce qu'un hash prenne moins d'une seconde.
- Si vous utilisez bcrypt, exécutez le test des 72 octets décrit plus haut et choisissez entre un plafond de longueur et une migration vers Argon2id.
- Ajoutez un marqueur d'algorithme au schéma, puis modifiez le code de connexion pour vérifier avec l'ancien schéma et re-hacher en cas de succès.
- Enveloppez les hash hérités restants dans Argon2id, ou fixez une date limite après laquelle ils sont supprimés et une réinitialisation est exigée.
- Si vous ajoutez un pepper, stockez-le dans un coffre-fort de secrets et rédigez d'abord la procédure de rotation et de réinitialisation forcée.
