D'accord, donc s'il s'agit d'une exigence commerciale que vous devez respecter (vérifiez si une carte existe déjà dans le système), voici comment je procéderais.

Premièrement, PCI-DSS permet de stocker un PAN (le numéro de compte principal ou le numéro de carte de crédit) sous forme hachée en utilisant une "cryptographie forte" et ils recommandent (mais ne nécessitent pas) qu'un le sel doit également être utilisé. PCI-DSS v3 § 3.4 (lien PDF) La raison est d'empêcher la capacité d'une partie malveillante qui récupère le hachage de déterminer le PAN qui a été utilisé comme entrée pour le hachage.

Deuxièmement, votre projet de stocker ceci dans un système séparé et sécurisé et de l'exposer uniquement via une API est une bonne mesure de défense en profondeur. Si je mettais en œuvre cela, je ne lui demanderais pas de renvoyer un hachage au système principal, je prendrais simplement le hachage comme paramètre pour l'appel d'API et ferais en sorte que l'API renvoie «true» ou «false» selon que le hachage existe déjà dans le système ou non.

Pour la fonction de hachage, la clé pour empêcher la récupération des entrées (comme requis par PCI-DSS) est de choisir un algorithme qui vous permet de faire le processus difficile en termes de calcul, donc la tâche de forcer brutalement l'espace d'entrée relativement petit des PAN valides est raisonnablement lente. SHA-512, suggéré par une autre réponse, n'est pas cet algorithme. En regardant la matrice de test pour le hachage de hachage fournie par hashcat.net, la machine la plus rapide de leur matrice peut calculer près de 2 milliards de hachages SHA-512 par seconde. Avec un espace d'entrée estimé à environ 30000000000000 de cartes **, cela signifie que non salées, vous pouvez calculer le SHA-512 de chacun de ces PAN en un peu plus de 4 heures et avoir les numéros de carte pour toujours dans la base de données, si jamais être volé.

Nous avons donc besoin d'une fonction de hachage lente, mais la définition de la lenteur change tout le temps à mesure que les ordinateurs deviennent plus rapides et que la technologie évolue. Cela signifie qu'une fonction de hachage sécurisée sera une fonction avec un facteur de travail réglable, de sorte qu'au fil du temps, vous pouvez augmenter l'effort de calcul requis pour calculer le hachage d'une entrée donnée. Il existe plusieurs algorithmes candidats qui répondent à ces critères, notamment PBKDF2, bcrypt et scrypt. Le consensus général pour le hachage de mot de passe est bcrypt, et c'est ce que je suggérerais ici. Pour le coût, définissez-le aussi haut que votre application le permet. Ce n'est probablement pas quelque chose que vous calculerez très fréquemment (j'imagine que, en fonction de votre application, vous allez regarder x hachages par minute ou heure ou jour plutôt que par seconde) et le plus élevé le coût, plus ce sera difficile pour un adversaire qui capture le hachage à la force brute.

** Mon estimation est basée sur un numéro de compte à 9 chiffres, un chiffre de contrôle calculable qui n'augmente pas la complexité et un WAG de 30000 numéros d'identification bancaire actifs (les 6 premiers chiffres de la carte) basé sur une liste que j'ai trouvée.

Je ne peux pas commenter la façon dont Stripe fait cela, mais je peux vous dire exactement comment Braintree le fait (car c'est là que je travaille). Si je devais deviner, Stripe utilise probablement une méthode similaire.

Dans l'API Braintree, nous proposons un identifiant de numéro unique pour une carte de crédit. Cet identifiant est un jeton opaque aléatoire qui sera toujours le même pour le numéro de carte stocké dans notre système. La valeur de départ de ce numéro est différente selon les marchands dans notre système, vous ne pouvez donc pas les comparer entre les marchands.

Lorsqu'une nouvelle carte arrive, nous la recherchons en la comparant à une colonne hachée + salée. S'il correspond à cette colonne existante, nous savons que nous pouvons renvoyer le même identifiant de numéro unique. S'il ne correspond à aucun enregistrement existant, nous utilisons un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé pour créer un nouvel identifiant de numéro unique et nous assurer qu'il n'est pas en conflit avec un existant.

De cette façon, le hachage + La valeur salée ne quitte jamais notre backend, mais nous pouvons toujours fournir un moyen pour un marchand d'identifier de manière unique les cartes de crédit stockées.

Le hachage des numéros de carte de crédit ne remplace pas la sécurisation des données. Si votre système n'est pas suffisamment sécurisé pour stocker les numéros de carte de crédit bruts, il n'est pas suffisamment sécurisé pour stocker les hachages CC.

Même chose pour tout ce qui est d'une taille fixe et d'un jeu de caractères limité: date de naissance, numéro de téléphone , zip, etc.

Les cartes de crédit sont toutes à 16 chiffres et bien que 10 ^ 16 semble être un grand nombre, c'est assez simple pour les ressources de calcul. Si j'ai votre table de hachages CC #, je peux facilement l'attaquer avec une table arc-en-ciel et obtenir une liste complète des cartes de crédit. Le salage des valeurs avant le hachage rend la recherche impossible.

Toutes les valeurs CC possibles: quelque chose de moins de 10 ^ 16.

À titre de comparaison, imaginez que vos utilisateurs ont utilisé un mot de passe raisonnable de 8 caractères avec un Sel de 20 octets: 62 ^ 28.

(Si j'étais votre auditeur PCI, je considérerais que le hachage des cartes de crédit équivaut à stocker les numéros de carte eux-mêmes.)

La réponse vous décevra: si un service / oracle / hash peut vous dire si un numéro d'entrée est dans le fichier, il peut être brisé par une très petite quantité de force brute.

Considérez que dans une grande partie du pays, les cartes de crédit sont émises par relativement peu de banques dans leur région géographique. Vous pouvez facilement connaître les numéros BIN de la plus populaire de ces banques. Supposons que vous ayez un reçu d'un magasin de Memphis et qu'il indique VISA **** 1234. Il y a environ 20% de chances que ce soit l'un des dix BIN différents appartenant aux plus grandes banques de la région de Memphis. C'est 10 ^ 1 suppositions pour les six premiers chiffres. Ensuite, vous connaissez les 4 derniers, car ils sont imprimés sur le reçu. Cela fait maintenant seulement 10 ^ 1 suppositions qui couvrent 10 des 16 chiffres. Sur les six chiffres restants, itérez sur 5 et calculez le dernier en utilisant Luhn. C'est 10 ^ 6 tests qui donneront un numéro de compte valide 20% du temps.

Tout ce que vous avez à faire pour tester un nombre est de parcourir le service 100 000 fois. Peu importe si le service utilise un hachage ou un cryptage ou une baguette magique pour protéger les numéros de compte, du moment qu'il vous indique si votre entrée correspond ou non.

Vous pouvez noter que cela ne fonctionne qu'environ 20% du temps. Considérez que le gars qui a volé Target a pris 40 millions de numéros de compte, et il ne pouvait pas les vendre tous, car il n'y avait pas assez d'escrocs dans le monde pour en acheter autant. 20% de ce montant est de 8 millions, et il n'en a probablement pas vendu autant non plus. Donc 20%, c'est assez bon pour un attaquant.

tl; dr:
Il n'est pas possible de faire une telle chose de manière vraiment sécurisée, mais cela peut être fait d'une manière "probablement assez bonne" pour être utilisable et acceptable .

Vos options sont essentiellement une forme de stockage crypté (avec le risque que les clés de cryptage soient volées, car elles doivent être présentes pour le décryptage), ou quelque chose impliquant du hachage, avec les problèmes bien connus du hachage mots de passe (un numéro de carte de crédit est fondamentalement un «mot de passe»).

Je mettrais en œuvre cela comme un système à deux niveaux où le premier niveau serait un simple CRC32 et le second serait plusieurs fois fonction de hachage sécurisée itérée. Oui, CRC32 n'est pas un hachage cryptographiquement sécurisé, mais cela n'a pas d'importance dans ce cas particulier, puisque le CRC n'est pas le maillon faible.
Si l'idée d'utiliser un non-cryptographiquement- L'algorithme sécurisé vous fait trop peur, vous pouvez toujours remplacer le CRC par un algorithme cryptographique secore et n'utiliser que par exemple les 32 bits les moins significatifs (ou 16, pour une plus grande marge) du hachage résultant.

La raison de cette approche est que la plage d'entrées possibles ne couvre que 39 bits environ ^{[1] . Il est pratiquement impossible de hacher cet espace de clés de manière vraiment sécurisée tout en gardant le système opérationnel pour l'utilisation prévue.
Une attaque par force brute sur un espace de clés de 39 bits est non seulement théoriquement faisable, mais en fait assez trivial - à moins que chaque opération est extrêmement coûteuse.}

La principale menace contre laquelle vous devez vous défendre est le vol de votre base de données, suivi de forcer brutalement vos hachages pour récupérer des numéros de carte valides. La prochaine meilleure chose qu'un attaquant pourrait faire serait d'interroger en ligne si un numéro inconnu qui hache de manière identique à un numéro soumis aléatoirement a déjà été utilisé, ou de demander si un numéro valide déjà connu a été utilisé (ni l'un ni l'autre n'est très utile, cependant!).

Les cartes de crédit sont généralement valables 5 ans, donc pour que le système soit sécurisé, il doit supporter au moins 5 ans de force brute. En d'autres termes, le travail effectué pour une seule vérification doit être si complexe sur le plan informatique qu'une machine de craquage multi-GPU dédiée ne peut pas effectuer plus de 2 ^ 39 / (5 * 365 * 86400) = 3486,5 vérifications par seconde.

Si l'on prend le chiffre bien connu de 348 milliards par seconde de 2012, la seule approche vraiment sécurisée devrait donc stocker la valeur d'avoir haché au moins 100 millions de fois. En tenant compte de la loi de Moore, ce serait 200 millions maintenant, et nous n'envisageons même pas la possibilité que quelqu'un possède 2 ou 3 de ces machines (ou peut-être 10).

Cependant, ceci encore ne prend pas en compte le fait que les banques sont par nature stupides et vont simplement incrémenter l'avant-dernier chiffre pour un nouveau numéro valide (et mettre à jour le chiffre de contrôle). Toutes mes cartes de crédit émises au cours des 20 dernières années ont eu le même numéro à l'exception de l'avant-dernier chiffre incrémenté de 0, 1, 2, 3, ...
Ce qui signifie que la planification sur 5 ans toujours ne suffit pas . Une personne connaissant un numéro de carte de crédit expiré peut dériver le numéro valide de la carte d'abonné. Il faut donc plutôt prévoir quelque chose comme 30 ans, pas 5 ans. Je vais laisser extrapoler la loi de Moore à 20-30 ans supplémentaires pour faire mes devoirs.

En conclusion, pour que le système soit vraiment, vraiment sécurisé , votre serveur devrait effectuer le l'équivalent d'un billion de hachages (ou plus) par vérification, ce qui à un taux de, disons 10 millions par seconde pour une implémentation CPU typique, prendrait plus d'une journée. En d'autres termes, le système est complètement inutilisable pour son objectif désigné .

Quelque chose de plusieurs ordres de grandeur plus rapide est nécessaire. La plupart des requêtes seront des requêtes négatives, et un hachage simple et rapide pourrait être utilisé pour éliminer 99,9% de tous les négatifs, si seulement cela ne rend pas la sécurité déjà faible encore plus faible. C'est là que CRC32 entre en jeu.

Si les CRC32 de deux numéros de carte de crédit ne correspondent pas , il est garanti que les numéros ne sont pas les mêmes. La plupart du temps, ce sera le cas, et vous pouvez immédiatement retourner "Non!". Vous pouvez sauter 99,9% du travail sans rien dévoiler.
Si les CRC correspondent , cela peut être un succès, mais il y a un risque de collision de hachage. Maintenant, le hachage cryptographique sécurisé (qui aurait au moins 160, mieux 256 bits) est calculé et comparé. La probabilité d'une collision est désormais négligeable. Si le hachage correspond, il est certain que le nombre correspond.

CRC32 contient 32 bits d'informations. Il est impossible de restaurer 39 bits d’information à partir de 32 bits, quelles que soient les ressources de calcul dont vous disposez. Par conséquent, le CRC est sûr à utiliser dans ce cas (ou du moins, il n'est pas moins sûr que toute autre chose).

Comme l'a souligné Ben Voigt, il est de bien sûr encore possible de deviner les informations qui ne peuvent pas être restaurées, et 7 bits à deviner ne sont pas terrible (concaténer la date d'expiration fera 15 bits). C'est vrai, mais vous ne pouvez pas faire grand-chose à ce sujet.

Qu'en est-il du CRC et de la sécurité de toute façon? Le CRC n'est pas sécurisé sur le plan cryptographique. Il est relativement facile de falsifier les bits pour obtenir la sortie souhaitée (pas de problème ici, ce serait avec les connexions), et la fonction peut être inversée de manière triviale (4 recherches de table, plus quelques décalages et xor) vers une entrée 32 bits, un problème un peu plus important. Heureusement, mais ce modèle de bits n'a pratiquement aucune valeur car ce n'est pas un nombre valide, ni un sous-ensemble d'un modèle de 39 bits qui pourrait être un nombre valide (autrement que par pure coïncidence).

Forcer brutalement l'espace de touches complet de 39 bits est plus simple que d'essayer de jouer des tours sur le CRC, car, malheureusement, c'est assez facile et rapide: une implémentation SSE4.2 utilise environ un demi-cycle par octet (donc, 2 cycles par hachage), ce qui signifie qu’un ordinateur de bureau pourrait faire l’espace de clés complet en une seconde ou deux (en supposant que les clés sont à comparer avec toutes les tailles en L1).

La recherche exhaustive révélerait tous les 39 bits modèles qui ont le même CRC, ce qui signifie qu'ils pourraient éventuellement être des numéros de carte de crédit, et en utilisant l'algorithme de Luhn, l'attaquant peut immédiatement rejeter 9 numéros sur 10 qui ne peuvent pas être valides. C'est mauvais, certes, mais c'est vraiment juste une conséquence de ne pas avoir trop de choix d'entrée et d'avoir un chiffre de contrôle implanté sur le dessus!

Pourtant, le CRC est en fait plus fort dans ce scénario plutôt qu'un algorithme cryptographiquement sécurisé: compte tenu de 2 à 3 milliards de cartes de crédit en circulation dans le monde, le risque de collision avec un hachage de 160 bits se situe entre 1 et 10 ²⁰ , et même pas pensez aux chances d'utiliser un hachage de 256 bits. Ce qui signifie que tout résultat lors de votre recherche exhaustive de l'espace de clés 39 bits vous donnera immédiatement le seul et unique numéro de carte valide garanti. Un hit sur le CRC32 ne vous donnera qu'un des nombreux numéros possibles.

Une chose que vous pourriez faire pour échanger un peu de vitesse contre la sécurité serait de jeter davantage d'informations sur le CRC, par exemple, vous pouvez simplement supprimer les 8 ou 16 bits les plus significatifs du CRC, ce qui les ajouterait aux bits qu'un attaquant devra deviner. Bien sûr, cela réduira quelque peu l'efficacité de la taille, mais pas trop drastiquement. Au lieu d'élaguer 99,99% du travail, vous pourriez finir par élaguer 99% ou 98%, ce qui est tout de même très bien.

Le deuxième niveau de vérification, comme indiqué ci-dessus, doit être un hachage cryptographiquement sécurisé qui exécute au moins un million d'itérations, un peu comme il est fait dans un schéma d'étirement de clé (en fait, il a besoin de beaucoup plus que cela , mais le système doit également rester pratiquement utilisable).
Le réalisateur doit ici échanger le risque contre l'utilisabilité, un serveur devrait au moins être capable de traiter quelques dizaines de requêtes par seconde. Les clients / commerçants ne consentiront pas si la recherche d'un numéro prend plusieurs minutes (ou plus), quelles que soient les implications de sécurité. Il n’est pas non plus pratique d’avoir plus ou moins un serveur dédié dédié par marchand.

Comme la correspondance n’est intéressante que sur une base par marchand, on peut utiliser une constante par marchand et stocker les numéros de carte de manière redondante avec un index sur l'identifiant du marchand, qui devrait être dans les pouvoirs de tout système de base de données raisonnable.

Je recommanderais de concaténer la date d'expiration avec le nombre, car cela rendra cette situation un peu moins misérable. Mes cartes de crédit sont toujours valables 5 ans (je ne sais pas si c'est la règle universelle, mais je suppose que oui), donc l'ajout de la date d'expiration ajouterait 5 * 12 possibilités, ou 5,9 bits (celles-ci sont à peu près gratuites, puisque vous avez de toute façon besoin des données d'expiration dans une transaction!).

En complément des suggestions précédentes. Que diriez-vous d'utiliser SHA-3 (qui n'était apparemment pas officiel jusqu'en 2015, après cette discussion) en ajoutant au numéro de carte une clé secrète spécifique au marchand afin de rendre les hachages spécifiques au marchand.

Le simple fait d'ajouter une clé secrète au message n'était pas sûr pour SHA-1 et SHA-2 en raison de leur faiblesse d'extension de longueur. Ce n'est pas le cas avec SHA-3, qui résiste aux attaques d'extension de longueur par conception. Comme expliqué ici, on pourrait même utiliser SHA-3 pour le calcul MAC en ajoutant simplement la clé au début du message.

Bien sûr, le problème de la façon de stocker en toute sécurité les clés secrètes demeure . Je n'ai aucune expérience de l'industrie des cartes de paiement. Je viens de tomber sur cette question et je l'ai trouvée intéressante. J'aimerais recevoir des commentaires d'utilisateurs plus expérimentés sur les problèmes spécifiques au traitement des numéros de cartes (et de leur espace de recherche relativement petit) en utilisant cette approche.

Vous ne devez pas le stocker selon les normes PA-DSS définies ici: https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf

Il déclare :

1.1 Ne pas stocker de données d'authentification sensibles après autorisation (même si elles sont cryptées): les données d'authentification sensibles incluent les données citées dans les exigences 1.1.1 à 1.1.3 suivantes.

Dans la colonne adjacente, il indique:

Si cette application de paiement stocke des données d'authentification sensibles, vérifiez que l'application est destinée uniquement aux émetteurs et / ou aux entreprises prenant en charge les services d'émission

Je suppose que vous n'êtes pas un émetteur ou une entreprise qui prend en charge les services d'émission. Gardez à l'esprit que Target Corporation a récemment été piraté et que les informations de carte de crédit ont été volées en temps réel et à des serveurs qui n'ont pas chiffré les données de bout en bout. Je crois comprendre qu'il est en train d'être rectifié et rendu plus sûr. Franchement, ne stockez pas la période. Même si vous utilisez le hachage SHA512, votre implémentation peut être défectueuse. Avec les meilleures contre-mesures, je ne voudrais pas être au bout d'un procès.

Edit:

C'est techniquement autorisé dans la section 2.3 de PA-DSS v2.0. Mais ne le faites pas.

Si vous voulez le faire, ajoutez une sorte d'obscurcissement. Je me suis juste assuré des votes négatifs, mais l'obscurcissement n'est pas sans valeur comme certains insisteront.

Si vous supposez que le système est connu, alors il n'y a aucune valeur. Mais si le système n'est pas connu, il y a une valeur absolue. Un IV utilisé pour «poivrer», comme Xander l'a dit, serait une forme d'obscurcissement, sans augmenter les collisions, et en maintenant la capacité d'interroger.

Un poivre ne serait cependant pas une obfuscation très efficace , sauf si le poivre est assez gros pour ne pas être deviné brutforce dans un laps de temps raisonnable. 100 octets aléatoires seraient peut-être exagérés, mais il n'y a aucune raison de ne pas aller trop loin.

Une autre chose qui pourrait être une dissimulation efficace serait de ne pas supposer que le poivre et le message sont atteints en même temps, donc que si vous répétez périodiquement les hachages dans un lot de nuit (en gardant une trace du nombre de tours), ils auraient besoin d'une autre information - combien de tours, ou comment les tours sont calculés.

Gardez à l'esprit que je ne pense pas que ce soit une bonne idée, je pense juste à haute voix ici. Si votre environnement est suffisamment sécurisé pour les cartes de crédit, non seulement je ne les hacherais pas, mais je les stockais dans une table conçue pour les performances de recherche les plus rapides.