IDX10720: Unable to create KeyedHashAlgorithm for algorithm 'HS256', the key size must be greater than: '256' bits, key has '128' bits.

L’algorithme et les nombres de bits reflètent votre configuration ; malgré « must be greater than », une clé de la taille exactement requise est acceptée. Vérifié sur plusieurs versions : 6.8.0 et les versions antérieures acceptaient les clés HMAC de 128 bits ; les versions 6.x ultérieures (6.36.0) et 7.x/8.x les rejettent avec IDX10720 (6.x ajoute un lien vers « UnsafeRelaxHmacKeySizeValidation »). Les clés de moins de 128 bits échouent plus tôt avec IDX10653 « The encryption algorithm 'HS256' requires a key size of at least '128' bits ».

Microsoft.IdentityModel.Tokens (.NET) — ArgumentOutOfRangeException from SymmetricSignatureProvider

Ce que cela signifie

IdentityModel refuse d’utiliser une clé HMAC plus courte que la sortie de hachage de l’algorithme : HS256 exige au moins 256 bits (32 octets), HS384 384 bits, HS512 512 bits, comme le requiert la RFC 7518 §3.2. La clé du message fait 128 bits, soit 16 octets, une longueur typique pour un secret saisi à la main dans `appsettings.json`. Les secrets HMAC courts peuvent être cassés par force brute hors ligne à partir d’un seul jeton, ce qui permettrait à n’importe qui de fabriquer des jetons que votre API accepte.

Pourquoi cela se produit

• Un secret court dans la configuration

  fréquente

  Les tutoriels utilisent des valeurs comme `MySecretKey12345` ou `supersecret`. Leurs octets UTF-8 sont loin d’atteindre 32.

• Mise à niveau de Microsoft.IdentityModel au-delà des premières 6.x

  fréquente

  Les versions jusqu’à au moins 6.8.0 signaient avec des clés HMAC de 128 bits ; les versions actuelles 6.x, 7.x et 8.x imposent le minimum de la RFC, si bien qu’une mise à niveau (souvent entraînée par une mise à niveau d’ASP.NET Core) casse les applications aux secrets courts.

• HS512 avec une clé dimensionnée pour HS256

  occasionnelle

  Une clé de 32 octets suffit pour HS256, mais pas pour HS512, qui exige 64 octets.

Comment corriger l’erreur

1. 1.

   Générer une clé aléatoire de la bonne taille

   Utilisez une valeur aléatoire cryptographiquement sûre, stockée dans les secrets utilisateur ou dans un coffre-fort de secrets, et jamais commitée dans le contrôle de code source.

   # 64 random bytes, base64: valid for HS256, HS384 and HS512
   openssl rand -base64 64 | tr -d '\n'
   dotnet user-secrets set "Jwt:KeyBase64" "<the value above>"   # development; use a vault in production

2. 2.

   Décoder la clé en octets

   Construisez la clé à partir des octets décodés, pour que toute l’entropie soit utilisée et que chaque service dérive la même clé.

   var keyBytes = Convert.FromBase64String(builder.Configuration["Jwt:KeyBase64"]!);
   var signingKey = new SymmetricSecurityKey(keyBytes); // 64 bytes

← Parcourir toute la base de données des erreurs de signature