Existe-t-il un meilleur algorithme .NET pour le chiffrement des cartes de crédit?

Question

L'espace de nommage .NET System.Security.Cryptography possède une collection plutôt ahurissante d'algorithmes que je pourrais utiliser pour le chiffrement des détails de carte de crédit. Quel est le meilleur?

Il est clair qu'il doit être sécurisé pour une chaîne relativement courte.

EDIT: Je suis au Royaume-Uni, où je comprends que nous sommes en train de stocker des informations de carte de crédit cryptées tant que le numéro CVV à trois chiffres n'est jamais stocké. Et merci à tous pour les bonnes réponses.

Answer 1

Pas d'offense, mais la question est un peu "mal orientée". Il n'y a pas de solution miracle. Je recommande de lire sur la cryptographie en général et ensuite faire une modélisation de la menace. Quelques questions (pas une liste complète), vous devriez vous poser:

• Le module est de faire le chiffrement celui qui doit le déchiffrer (dans ce cas, l'utilisation de Crypto symétrique) ou sera envoyer des données à un autre module (sur une autre machine) qui l'utilisera (dans ce cas, vous devriez considérer crypto à clé publique)
• Que voulez-vous protéger contre? Quelqu'un accédant à la base de données mais n'ayant pas le code source (dans ce cas, vous pouvez coder la clé de cryptage directement dans la source)? Quelqu'un reniflant votre réseau local (vous devriez envisager des solutions transparentes comme IPSec)? Quelqu'un vole votre serveur (cela peut arriver même dans les centres de données - dans ce cas, le cryptage complet du disque doit être pris en compte)?
• Avez-vous vraiment besoin de conserver les données? Ne pouvez-vous pas le transmettre directement au processeur de carte de crédit et l'effacer après avoir reçu la confirmation? Vous ne pouvez pas le stocker localement chez le client dans un cookie ou Flash LSO? Si vous le stockez chez le client, assurez-vous de le chiffrer du côté serveur avant de le placer dans un cookie. En outre, si vous utilisez des cookies, assurez-vous de les rendre uniquement http.
• Suffit-il de comparer l'égalité des données (c'est-à-dire que les données que le client m'a données sont les mêmes que celles que j'ai)? Si c'est le cas, pensez à en stocker un hachage. Étant donné que les numéros de carte de crédit sont relativement courts et utilisent un ensemble réduit de symboles, un sel unique doit être généré avant chaque hachage.

modifier plus tard: noter que les algorithmes de chiffrement standard de la même catégorie (par exemple, 3DES et AES - les deux étant Cyphers bloc symétrique) sont de force comparable. La plupart des systèmes (commerciaux) ne sont pas cassés parce que quelqu'un a forcé leur cryptage, mais parce que leur modélisation de la menace n'était pas assez détaillée (ou à plat qu'ils n'en avaient pas). Par exemple, vous pouvez crypter toutes les données, mais s'il vous arrive d'avoir une interface web publique qui est vulnérable à l'injection SQL, cela ne vous aidera pas beaucoup.

Answer 2

3des est assez bon, stockez le sel le long du côté, et gardez une clé standard quelque part pas dans la base de données ou un fichier de configuration. De cette façon, si vous obtenez pwned, ils ne peuvent pas le déchiffrer.

Answer 3

Conformément aux règles de conformité PCI DSS, toute norme de chiffrement leader de l'industrie est suffisante. Donc, un 3DES avec une clé de 256 bits est assez bon (bien que d'autres normes puissent être utilisées). Check this out http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

Answer 4

Ce n'est pas grave.

Les numéros de carte complets ne doivent jamais toucher le disque.

Tout ce qui compte est le code d'autorisation.

Pour les traces, etc, vous utiliserez uniquement les 4 derniers chiffres xxxx xxxx xxxx 1234 et expirer la date.

Si vous souhaitez stocker des numéros de carte, le choix de la cryptographie sera demandé par la banque acquéreur. Sauf si vous êtes l'acquéreur, dans ce cas, il devrait y avoir un ancien programmeur Unix/DB2 que vous devriez demander.

« Tu ne peux pas le stocker localement au client dans un cookie » < - NE JAMAIS

Answer 5

Il y a aussi l'aspect juridique à considérer. Je ne connais pas la situation ailleurs mais en Allemagne vous n'êtes tout simplement pas autorisé à stocker les numéros de cartes de crédit ¹⁾. Période. Peu importe que vous les chiffriez ou non et dans quel format vous les stockez. (Et ici, je me réfère à la mémoire, sans aucune connaissance judiciaire) est de stocker un hachage fort (SHA-256?) Du numéro de carte de crédit, avec les quatre derniers chiffres et le numéro de compte. Et oui, il est trivial de reconstruire le nombre complet de ces informations seul. Les lois ne sont pas toujours logiques.

---

¹⁾ Sauf si vous êtes un institut de carte de crédit fédéral certifié.

Answer 6

Indice: Vous devriez vérifier s'il est légal de stocker les numéros de cartes de crédit. En Suède par exemple, vous devrez être certifié par PCI (Payment Card Industry), où votre sécurité interne et externe sera testée (un long avec beaucoup d'autres choses).

Vous devriez réfléchir à la fois une ou deux fois avant de stocker des informations de carte de crédit, car les frais juridiques de le faire mal pourraient être coûteux.

Answer 7

j'ajouter à la vue que vous ne devriez pas tout simplement les stocker sauf si vous avez vraiment vraiment une bonne raison, et de les stocker dans un cookie est un vraiment mauvaise idée - ils sont juste à too easy obtenir (que se passe-t-il si quelqu'un vole un cookie - alors cela n'aura pas d'importance si c'est crypté). Si vous avez besoin de faire des paiements répétés, la plupart des fournisseurs de CC vous offrent un moyen de le faire en stockant une sorte de jeton du paiement initial, sans conserver le numéro de carte (vous pouvez garder les 4 derniers chiffres à afficher au client pour qu'il sache quelle carte est stockée).

Vraiment, ne le faites pas!

De même, vous ne devriez jamais conserver le code CCV.

Answer 8

Ne pas oublier l'intégrité ici. Il y a des attaques de falsification contre le chiffrement prêt à l'emploi lorsque l'attaquant ne connaît pas la clé, mais peut manipuler le texte chiffré. Ceux-ci peuvent être particulièrement agressif lorsque:

• cryptage des chaînes courtes,
• avec des sous-chaînes connues

C'est exactement le cas pour les cartes de crédit. Donc, en utilisant System.Security.Cryptography AES ou 3DES en mode CBC sans rouler votre propre somme de contrôle peut être dangereux. Lire: il y a une chance qu'un attaquant sans clé secrète puisse remplacer un numéro de carte de crédit par un autre.

Answer 9

Si vous utilisez une passerelle de paiement tierce, vous n'avez pas besoin de stocker les numéros.

Il n'y a pas de point.

Answer 10

Chiffrez la carte de crédit avec une clé publique. Donnez la clé privée à la machine de processeur de paiement seulement. La machine de traitement de paiement peut alors interroger la base de données et faire le travail, et personne d'autre, même la machine qui a ajouté l'entrée, ne pourra la déchiffrer.

Quelque chose comme PHP's openssl_seal, mais si vous voulez peut-être avec un algorithme différent.