Hachage de Données à Faible Entropie & Cartes Bancaires en APAC

Voici un fait qui dérange : hacher n’est pas protéger. Vous pouvez stocker une empreinte SHA-256 d’un numéro de carte bancaire, être parfaitement conforme au PCI DSS et n’avoir malgré tout aucune protection effective, parce que la valeur que vous avez hachée ne contient tout simplement pas assez d’entropie pour résister à la force brute.

Cela piège des équipes d’ingénierie pourtant rigoureuses, car le hachage semble sûr. L’empreinte est à sens unique, l’original ne peut être retrouvé en inversant la fonction, donc les données sont forcément protégées. Le défaut n’est pas dans le hachage. Le défaut est dans ce qu’on lui a donné à manger.

Le problème de l’entropie, en chiffres réels #

Un numéro de carte de 16 chiffres n’est pas aléatoire. Sa structure est publique et fixe :

• Les 4 à 6 premiers chiffres sont le numéro d’identification de l’émetteur (IIN) : le préfixe de la banque, entièrement public.
• Le dernier chiffre est une somme de contrôle, calculée par l’algorithme de Luhn, une formule publiée en 1954. Elle n’est pas secrète ; c’est de la détection d’erreur.

Masquez maintenant le PAN comme le PCI DSS le permet habituellement : 4 à 6 premiers chiffres et 4 derniers visibles, les 6 à 8 du milieu cachés :

4532 AAXX XXXX 1234

Avec seulement 4 chiffres connus de l’IIN, il reste 8 chiffres inconnus, soit au plus 100 000 000 valeurs possibles. En appliquant la somme de contrôle de Luhn, seule 1 valeur sur 10 survit. Votre espace de recherche réel est de 10 millions de valeurs. Ce n’est pas un mot de passe. C’est une très petite liste.

À quelle vitesse teste-t-on 10 millions d’empreintes ? #

Là, cela empire. SHA-256 est rapide par conception. Il est construit pour la vérification d’intégrité à débit gigabit, pas pour stocker des secrets. Les benchmarks publics de cassage sur GPU sont reproductibles :

Dix millions d’essais divisés par 8,5 milliards par seconde font environ un millième de seconde. Sur une seule GPU grand public. Un simple ordinateur équipé d’une GPU peut utiliser une table rainbow pour « dé-hacher » un numéro de carte en un battement de cil.

La conclusion est brutale : conforme ne veut pas dire sécurisé. Sur des champs à faible entropie, même SHA-2 (ou SHA-3) n’est pas sécurisé, même s’il est conforme. La fonction est à sens unique ; elle est simplement trivialement épuisable quand l’espace d’entrée est minuscule. Remplacer SHA-256 par SHA-512 ou SHA-3 ne règle rien, car ils sont tout aussi rapides.

Ce que « conforme » autorise vraiment #

Le PCI DSS ne vous dit pas réellement de hacher les PAN avec SHA-256. L’exigence 3.5 dit que vous devez rendre le PAN illisible par cryptographie forte, qui mentionne explicitement les empreintes à clé et le chiffrement, et note qu’un index haché et salé est acceptable quand le sel est secret et l’empreinte n’est pas pratiquement réversible. Le problème est qu’un SHA-256 nu, sans sel, sur un espace de 10 millions de valeurs est, en pratique, réversible par épuisement, si bien qu’il manque l’intention de l’exigence même si la case de la liste passe.

Le masquage (afficher les 4-6 premiers et/ou 4 derniers) est un contrôle distinct : il protège ce qu’un opérateur voit, pas ce que vous stockez. Les deux sont facilement confondus, et cette confusion explique comment des PAN masqués mais hachés nus finissent en production.

Comment protéger correctement ce type de données #

La solution consiste à traiter les champs à faible entropie avec le même respect qu’un mot de passe, car mathématiquement, ils sont tout aussi faibles. Les options, par ordre de préférence :

1. Ne pas les stocker du tout. Tokenisez le PAN et conservez le vrai numéro dans un coffre-fort ou un HSM séparés. Si vous ne stockez jamais la valeur, il n’y a rien à forcer.
2. Hachage à clé (HMAC) avec un pepper secret. Si vous devez indexer par PAN, utilisez un HMAC avec une clé à haute entropie conservée hors de la base de données. Sans la clé, la force brute est computationnellement infaisable quelle que soit l’entropie d’entrée.
3. Hachage de mots de passe intensif en mémoire. Quand vous devez protéger la valeur avec la seule valeur, utilisez Argon2id (RFC 9106) ou scrypt avec un sel aléatoire par valeur et des paramètres ajustés pour que chaque essai coûte du temps et de la mémoire réels. Argon2id avec, disons, 64 Mo de coût mémoire transforme cette recherche exhaustive de 0,001 seconde en mois de temps GPU.
4. Sels et peppers partout. Un sel aléatoire par valeur neutralise les tables rainbow précalculées ; un pepper secret neutralise totalement les attaques hors ligne tant qu’il reste secret.

La OWASP Password Storage Cheat Sheet et NIST SP 800-63B recommandent toutes deux des fonctions intensives en mémoire pour les secrets à faible entropie, précisément pour cette raison.

La leçon au-delà des cartes #

Cela s’applique à tout identifiant à format fixe et entropie limitée : numéros d’identité nationale, numéros de téléphone, dates de naissance, et même clés API mal générées. Si l’espace d’entrée est petit, la vitesse de la fonction de hachage devient votre ennemie, et « conforme » n’est pas synonyme de « sûr ».

Notre Revue de Sécurité des APIs & Applications examine comment votre code stocke et transmet réellement les valeurs sensibles, et nous vous dirons franchement où une case cochée laisse des données réelles exposées.