Certaines attaques demandent un enchaînement astucieux de primitives. Celle-ci demande un grand entier dans un en-tête.
Le mécanisme
La famille PBES2-HS256+A128KW dérive une clé depuis un mot de passe avec PBKDF2. Itérer lentement est l’objectif : cela rend la force brute coûteuse.
Le nombre d’itérations voyage dans le jeton lui-même, dans l’en-tête p2c. Le destinataire le lit et exécute ce nombre de tours.
Vous voyez venir. Un attaquant non authentifié fabrique un unique JWE avec p2c à cent millions, l’envoie, et le serveur se met docilement à calculer. Une requête, un processeur épinglé. Recommencer.
Pourquoi c’est passé inaperçu
Parce que l’implémentation était correcte. Elle faisait exactement ce que la spécification décrit. La faille n’est pas dans l’arithmétique, elle est dans le fait de faire confiance à un paramètre de coût fourni par la partie contre laquelle vous vous défendez.
Le travail a lieu avant toute authentification, ce qui le rend atteignable par quiconque atteint le point de terminaison.
Le correctif
p2c est désormais borné, avec un plafond configurable. Au-delà, le jeton est refusé sans rien calculer. Corrigé en 3.4.10, 4.0.7 et 4.1.7.
Le motif à chercher
Tout paramètre qui dit combien de travail faire, et qui vient de l’extérieur, a besoin d’un plafond. Nombres d’itérations, coûts en mémoire, taux de décompression, dimensions d’images, profondeurs de récursion. La borne appartient à votre configuration, jamais au message.
Et si vous pouvez éviter le chiffrement de clé par mot de passe dans un protocole exposé à Internet, faites-le. La raison qui le rend lent est la raison qui le rend dangereux ici.