PBKDF2 expliqué : la fonction de dérivation de clé basée sur un mot de passe qui sécurise votre coffre

TL;DR

PBKDF2 (Password‑Based Key Derivation Function 2) est un algorithme d’étirement de clé défini dans la RFC 2898. Il applique une fonction pseudo‑aléatoire (généralement HMAC‑SHA256) un grand nombre de fois à un mot de passe et à un sel, produisant une clé dérivée. Le nombre d’itérations rend les attaques par force brute exponentiellement plus coûteuses. OWASP recommande 600 000 itérations pour SHA‑256 en 2026. AppVault utilise PBKDF2 avec 600 000 itérations, un sel de 128 bits par installation, et enveloppe la sortie avec une clé du Secure Enclave pour une protection matérielle.

Chaque fois que vous déverrouillez votre iPhone, que vous saisissez un mot de passe sur un site Web ou que vous ouvrez un coffre de fichiers, un logiciel transforme votre secret en une clé cryptographique. Cette transformation n’est pas un simple hachage. C’est une fonction soigneusement conçue qui rend les attaques par force brute coûteuses. La plus déployée de ces fonctions est PBKDF2.

PBKDF2 signifie Password‑Based Key Derivation Function 2 (Fonction de dérivation de clé basée sur un mot de passe 2). Elle est définie dans la RFC 2898 (PKCS #5 v2.0) et constitue une norme recommandée par le NIST depuis plus de deux décennies. Elle prend un mot de passe, un sel, un nombre d’itérations et une longueur de clé souhaitée, et produit une clé dérivée utilisable pour le chiffrement, l’authentification ou d’autres opérations cryptographiques.

Cet article explique comment fonctionne PBKDF2, pourquoi le hachage direct est insuffisant, le rôle des sels et du nombre d’itérations, la recommandation OWASP 2026 de 600 000 itérations pour SHA‑256, et comment PBKDF2 se compare aux alternatives modernes comme Argon2id, bcrypt et scrypt. Il décrit également comment AppVault utilise PBKDF2 dans le cadre de sa pile de chiffrement.

Pourquoi le hachage direct échoue

Si vous prenez un mot de passe et calculez son hachage SHA‑256, vous obtenez une valeur de 256 bits. Cette valeur peut être utilisée comme clé. Le problème, c’est la vitesse. Un GPU moderne peut calculer des milliards de hachages SHA‑256 par seconde. Un attaquant équipé d’un seul GPU grand public peut essayer tous les mots de passe de 8 caractères en minuscules en quelques minutes.

Le hachage direct n’offre pas non plus de protection intégrée contre le précalcul. Sans sel, le même mot de passe produit toujours le même hachage. Les attaquants peuvent construire des tables arc‑en‑ciel — des chaînes de hachage précalculées — et retrouver le mot de passe instantanément.

PBKDF2 résout ces deux problèmes. Il répète le hachage des milliers de fois, rendant chaque tentative coûteuse en calcul. Il exige un sel, de sorte que des mots de passe identiques produisent des clés différentes. La combinaison du nombre d’itérations et du sel transforme un hachage rapide en une dérivation lente et unique.

Comment fonctionne PBKDF2

PBKDF2 repose sur une fonction pseudo‑aléatoire (PRF), généralement HMAC‑SHA256 ou HMAC‑SHA1. L’algorithme fonctionne comme suit :

1. Le mot de passe et le sel sont combinés.
2. La PRF est appliquée au sel concaténé avec un compteur de bloc (pour des longueurs de clé supérieures à la sortie de la PRF).
3. La sortie est combinée par XOR avec le résultat de l’itération précédente (pour la première itération, le résultat précédent est la sortie de la PRF elle‑même).
4. Les étapes 2‑3 sont répétées pour le nombre d’itérations spécifié.
5. La sortie finale est la clé dérivée.

Le nombre d’itérations est le paramètre critique. Chaque itération ajoute une quantité fixe de travail. Si un attaquant veut tester un mot de passe, il doit exécuter toute la chaîne d’itérations. Avec 600 000 itérations, une seule tentative de mot de passe prend environ 600 000 fois plus de temps qu’un seul hachage SHA‑256.

Le sel doit être unique par utilisateur ou par instance. Un sel de 128 bits (16 octets) est le minimum recommandé par le NIST. Le sel est stocké à côté de la clé dérivée (ou dans les métadonnées du coffre) afin que la dérivation puisse être répétée lors de l’authentification.

La recommandation OWASP 2026

OWASP publie une antisèche sur le stockage des mots de passe qui fournit des recommandations sur le nombre d’itérations pour diverses fonctions de dérivation de clé. En 2026, la recommandation pour PBKDF2‑HMAC‑SHA256 est de 600 000 itérations. Pour PBKDF2‑HMAC‑SHA1, la recommandation est de 1 300 000 itérations, car SHA1 produit une sortie de 160 bits et est légèrement plus rapide par itération.

Ces chiffres ne sont pas arbitraires. Ils sont calibrés pour qu’une seule tentative de mot de passe prenne environ 0,1 seconde sur du matériel grand public moderne. Ce délai est imperceptible pour un utilisateur légitime mais rend les attaques par force brute prohibitivement lentes. Un attaquant disposant d’un cluster de 100 GPU ne peut tenter que quelques centaines de mots de passe par seconde, pas des milliards.

Le nombre d’itérations doit être augmenté au fil du temps à mesure que le matériel s’améliore. OWASP met à jour ses recommandations périodiquement. AppVault utilise 600 000 itérations pour PBKDF2‑HMAC‑SHA256, conformément à la directive de 2026.

Compromis du nombre d’itérations

Des nombres d’itérations plus élevés rendent les attaques par force brute plus difficiles, mais ils augmentent aussi le temps nécessaire pour dériver la clé sur l’appareil légitime. Sur un iPhone, 600 000 itérations de HMAC‑SHA256 prennent environ 0,2 seconde. C’est acceptable pour un déverrouillage du coffre. Mais si le nombre d’itérations passait à 10 millions, le temps de déverrouillage dépasserait 3 secondes, nuisant à l’expérience utilisateur.

Il y a aussi un compromis sur la consommation d’énergie. Les appareils mobiles ont une batterie limitée. Chaque itération consomme des cycles CPU. AppVault équilibre sécurité et convivialité en choisissant un nombre d’itérations qui offre une protection solide sans vider la batterie ni frustrer l’utilisateur.

Un autre compromis concerne l’utilisation de la mémoire. PBKDF2 n’est pas gourmand en mémoire. Il utilise une petite quantité de mémoire fixe quel que soit le nombre d’itérations. Cela le rend vulnérable aux attaques par GPU et ASIC qui peuvent paralléliser de nombreuses tentatives de mots de passe. Les fonctions gourmandes en mémoire comme Argon2id et scrypt nécessitent une grande quantité de mémoire par tentative, rendant les attaques parallèles beaucoup plus coûteuses. PBKDF2 compense son absence de gourmandise en mémoire par un nombre élevé d’itérations et, dans le cas d’AppVault, par une liaison matérielle via le Secure Enclave.

PBKDF2 vs Argon2id, bcrypt et scrypt

PBKDF2 n’est pas la seule fonction de dérivation de clé basée sur un mot de passe. Trois autres fonctions sont couramment utilisées : bcrypt, scrypt et Argon2id. Chacune a des objectifs de conception et des propriétés de sécurité différents.

Bcrypt a été conçu en 1999 et utilise un calendrier de clés basé sur Blowfish. Il est résistant aux attaques par GPU car il nécessite une quantité fixe de mémoire (4 Ko) et possède un facteur de coût intégré. Bcrypt est largement supporté mais a une longueur maximale de mot de passe de 72 octets. Il n’est pas recommandé pour les nouveaux systèmes car il est plus lent sur CPU qu’Argon2id et ne permet pas d’utiliser une mémoire variable.

Scrypt a été conçu en 2009 et est gourmand en mémoire. Il nécessite une grande quantité de mémoire (configurable) et du temps CPU. Scrypt est résistant aux attaques par ASIC et GPU car la bande passante mémoire devient le goulot d’étranglement. Il est utilisé dans certains portefeuilles de crypto‑monnaies et outils de chiffrement de fichiers. Cependant, scrypt est moins largement implémenté que PBKDF2 et n’a pas de norme NIST.

Argon2id est le gagnant du Password Hashing Competition de 2015. C’est le KDF le plus moderne et recommandé pour les nouveaux systèmes. Argon2id est gourmand en mémoire, gourmand en CPU et résistant aux attaques par canaux auxiliaires. Il existe trois variantes : Argon2d (dépendant des données), Argon2i (indépendant des données) et Argon2id (hybride). OWASP recommande Argon2id pour les nouvelles applications.

PBKDF2 reste le KDF le plus largement déployé car il est simple, normalisé et disponible dans toutes les grandes bibliothèques cryptographiques. C’est la valeur par défaut dans CommonCrypto d’iOS, le KeyStore d’Android et de nombreux systèmes d’entreprise. Pour les applications qui ne peuvent pas utiliser Argon2id en raison de limitations de plateforme ou d’exigences de compatibilité, PBKDF2 avec un nombre élevé d’itérations et une liaison matérielle constitue un choix solide.

Comment AppVault utilise PBKDF2

AppVault utilise PBKDF2‑HMAC‑SHA256 avec 600 000 itérations et un sel de 128 bits par installation. Le sel est généré lors de la configuration initiale et stocké dans le Secure Enclave de l’appareil. La clé dérivée est ensuite enveloppée par une clé générée à l’intérieur du Secure Enclave, qui ne quitte jamais la puce. Cela offre une protection liée au matériel : même si un attaquant extrait la sortie de PBKDF2, il ne peut pas l’utiliser sans la clé du Secure Enclave.

Le verrouillage par motif sur la grille 5×5 d’AppVault est converti en une chaîne de mot de passe. Cette chaîne est introduite dans PBKDF2 avec le sel. La clé dérivée résultante sert à chiffrer le catalogue du coffre et chaque fichier individuellement en utilisant AES‑256‑GCM avec un nonce unique de 96 bits par fichier.

L’architecture zéro connaissance d’AppVault signifie que le mot de passe ne quitte jamais l’appareil. La dérivation PBKDF2 s’effectue entièrement sur l’iPhone. Les serveurs d’AppVault (qui n’existent pas) ne voient jamais le mot de passe ni la clé dérivée. Le modèle de menace suppose qu’un attaquant peut obtenir un accès physique à l’appareil, mais sans le mot de passe et la clé du Secure Enclave, le coffre reste scellé.

D’autres applications de coffre dans cette catégorie adoptent des approches différentes de la dérivation de clé. Les détails architecturaux — nombres d’itérations, gestion des sels, liaison matérielle versus détention de clé uniquement logicielle — se trouvent sur les pages de comparaison dédiées : AppVault vs Vaultaire et AppVault vs Keepsafe. AppVault publie l’intégralité de sa pile cryptographique avec des citations de sources primaires, ce qui est la condition préalable à toute vérification indépendante.

Considérations pratiques pour les développeurs

Si vous implémentez PBKDF2, suivez ces directives :

• Utilisez HMAC‑SHA256 comme PRF. SHA1 est acceptable mais nécessite plus d’itérations.
• Générez un sel aléatoire d’au moins 16 octets par utilisateur ou par instance.
• Fixez le nombre d’itérations à la recommandation actuelle d’OWASP (600 000 pour SHA‑256 en 2026).
• Stockez le sel et le nombre d’itérations à côté de la clé dérivée (ou des métadonnées du coffre) afin que la dérivation puisse être répétée.
• Envisagez une liaison matérielle (par exemple Secure Enclave, TPM) pour protéger la clé dérivée même si l’appareil est compromis.
• N’utilisez pas PBKDF2 pour le stockage de mots de passe dans les systèmes d’authentification si Argon2id est disponible. PBKDF2 est mieux adapté à la dérivation de clé dans les scénarios de chiffrement local.

Conclusion

PBKDF2 est une fonction de dérivation de clé éprouvée qui protège les mots de passe et les clés de chiffrement depuis plus de deux décennies. Ce n’est pas le KDF le plus moderne, mais c’est le plus largement supporté et, lorsqu’il est correctement configuré, il offre une protection solide contre les attaques par force brute. La recommandation OWASP 2026 de 600 000 itérations pour SHA‑256 garantit que chaque tentative de mot de passe est suffisamment coûteuse pour dissuader les attaquants.

AppVault utilise PBKDF2 avec 600 000 itérations, un sel par installation et une enveloppe via le Secure Enclave pour protéger vos fichiers. La combinaison d’un nombre élevé d’itérations et d’une liaison matérielle rend le coffre résistant aux attaques logicielles et physiques. Pas de réinitialisation de mot de passe, pas de porte dérobée, pas de récupération côté serveur. La sécurité de vos données dépend de la robustesse de votre mot de passe et de l’intégrité de la dérivation PBKDF2.

Pour un examen plus approfondi de la mise en œuvre cryptographique d’AppVault, consultez la vue d’ensemble du chiffrement et le modèle de menace.