Je gère un site Web où nous marquons certains comptes comme escrocs et "drapeau" leur compte et toutes les cartes de crédit utilisées comme mauvaises. Nous ne stockons pas les valeurs de carte de crédit réelles, mais stockons plutôt un algorithme de somme de contrôle / MD5.
Nous frappons tout le temps des collisions maintenant. Quelle est la meilleure façon de stocker ces valeurs - non réversible, mais capable de faire des comparaisons sur les valeurs futures.
Je pensais que MD5 serait le meilleur, mais nous avons un débat en cours ...
11 Réponses :
Utilisez SHA1, les collisions de hachage doivent encore être trouvées.
"Les collisions de hasch doivent encore être trouvées"? C'est très peu probable. Ce que vous vouliez dire, c'est probablement «aucune attaque de collision» n'est pas encore connu. Les collisions peuvent toujours se produire lorsque vous réduisez de grandes quantités arbitraires de données à une valeur de taille fixe.
Tu as raison, c'est ce que je voulais dire. Désolé, je ne suis pas indigène et je trouve parfois difficile de m'exprimer.
SHA-1 est cassé: Schneier.com/blog/archives/2005/ 02 / SHA1_BRENK.HTML , alors utilisez SHA-256
Si vous trouvez des collisions avec MD5, pourquoi ne pas utiliser un meilleur algorithme tel que SHA1 ou SHA256 ?
Un hachage cryptographiquement sécurisé fonctionnerait. (SHA512 ou SHA256 serait OK)
Cependant, j'utiliserais un sel assez secret qui n'est pas stocké avec les cartes (pour empêcher toute sorte d'attaque de table arc-en-ciel).
PS:
Les attaques de table arc-en-ciel contre des cartes de crédit peuvent être particulièrement efficaces, car la taille totale de l'espace de texte brut est assez faible en raison du jeu de caractères limité, de la taille fixe et des chiffres de contrôle.
Vous ne pouvez pas utiliser de sel aléatoire pour chaque entrée, car vous ne pourriez jamais vérifier de manière gastronomique. Les sels sont utilisés pour prévenir les collisions, alors que nous recherchons spécifiquement une collision dans ce cas.
Il y a des discussions chauffées à ce sujet à ce sujet, mais apparemment, vous pouvez stocker le sel en toute sécurité avec les informations salées, tant que le sel est varié (aurait besoin d'une table arc-en-ciel par sel).
Excusez mon ignorance, mais pourquoi pas simplement utiliser un sel aléatoire, comme cela est fait ici si "NULL" est adopté? EvemiEx.com/samples/hash.aspx Il me manque le point du sel , s'il n'est pas nécessaire de déchiffrer (comme dans le lien posté). N'est-ce pas un bon exemple de classe à utiliser?
Nous n'essayons pas de stocker et de revérifier, nous essayons de faire une correspondance en double. À ce stade, afin de vérifier un duplicata, vous auriez à hacher le numéro CCARD avec chaque sel de la base de données.
@JoHngietzen Will SHA512 / SHA256 garantira un caractère d'unicité? Je veux dire si cela ne le fait pas, alors il pourrait être négatif positif, c'est-à-dire deux différents CC ont le même hachage, mais nous les traitons comme la même carte.
MD5 n'est pas le moyen d'aller depuis qu'il est cassé. Devis Bruce Schneier: "[w] e savait déjà que MD5 est une fonction de hachage brisée" et que "personne ne devrait utiliser plus de MD5."
I.e. Utilisez SHA512 ou SHA256 comme une personne déjà proposée.
SHA1 est également cassé: Schneier.com/blog/archives/2005/02 /sha1_broken.html
L'utilisation du hachage le plus fort possible est généralement bon. La vitesse n'est pas de l'essence et de la lenteur fonctionne réellement contre quiconque essayant une inversion de force brute de vos valeurs hachées.
J'aime Whirlpool, personnellement - si vous utilisez php, consultez les algorithmes pris en charge sur La fonction de hachage docs
Whirlpool retourne une chaîne de 128 caractères de long, mais vous n'avez pas à stocker tout cela nécessairement. Les premiers 32 ou 64 caractères suffiraient. Vous pouvez également envisager SHA512 ou SHA284.
Il n'est pas suffisamment sûr pour simplement utiliser un bon algorithme de hachage. Si votre liste est volée, vos hachages stockés peuvent être utilisés pour récupérer des informations de carte de travail. L'espace de schéma réel pour les numéros de carte de crédit est suffisamment petit qu'un attaquant déterminé peut pré-calculer de nombreux hachages possibles à l'avance, et cela peut avoir d'autres implications pour votre système s'il y a une intrusion ou un emploi à l'intérieur. .
Je vous recommande d'utiliser un sel et de calculer également une 2e valeur à ajouter au sel sur la base d'une formule impliquant chaque chiffre du numéro de carte et de la première valeur de sel. Cela garantit que si vous perdez le contrôle de l'une ou l'autre partie, vous avez toujours un caractère unique raisonnable qui rend la propriété de la liste inutile. La formule ne doit pas être fortement pondérée vers les 6 premiers chiffres de la carte (numéro de bac), cependant, et aucune trace de la formule ne doit être stockée au même endroit que le sel ou le hachage final.
Considérez l'anatomie d'un numéro de carte de crédit à 16 chiffres:
bac à 6 chiffres (numéro d'identification bancaire)
Numéro de compte à 9 chiffres
1 chiffre de checksum Luhn
Les listes bin sont bien connues dans l'industrie de la transformation et ne sont pas trop difficiles à assembler pour ceux qui ont accès à une liste illicite de numéros de cartes. Le nombre de bacs valides est en outre diminué par l'espace attribué pour chaque émetteur.
visa - commence par 4
American Express - commence avec 34/37
MasterCard - commence par 5
Découvrir / Coupe - Commence avec 6
Club de Diner - Début avec 35
c.
Notez que certaines des informations relatives aux bacs attribuées dans chaque catégorie d'émetteurs sont également clairsemées. Si un attaquant est conscient de la mesure où la plupart de vos clients sont situés, cela réduira considérablement l'unicité de manière considérable, car les informations de la corbeille sont attribuées sur une base paragissante. Un attaquant qui a déjà un compte émis par une petite banque dans un quartier riche pouvait simplement obtenir un compte et utiliser le bac comme point de départ sur sa propre carte.
Le chiffre de contrôle est calculé avec une formule bien connue, de sorte que cela soit immédiatement éliminable en tant que source de données uniques.
armé d'une poignée de bacs méritant de cibler, un attaquant doit vérifier 9 chiffres à la fois pour chaque ensemble de bacs. Il s'agit d'un milliard de checksums et d'opérations de hachage par ensemble. Je n'ai pas de points de vue utiles, mais je suis à peu près sûr que 1 million d'opérations de hachage par minute ne sont pas déraisonnables pour MD5 ou toute saveur de SHA sur une machine convenablement puissante. Cela équivaut à moins d'une journée pour craquer toutes les correspondances sous une corbeille donnée.
Enfin, vous pourriez envisager de stocker un chômage horodatage ou un jeton de visiteur (IP / sous-réseau) avec vos hatupes également. Il est agréable d'attraper des numéros de carte en double, mais considérons également les ramifications de quelqu'un qui fourre votre système avec des numéros de carte de faux. À un moment donné, vous devez décider d'un compromis entre les numéros de carte de blocage que vous connaissez, vous savez, et vous donner un mécanisme pour identifier et réparer une mauvaise utilisation.
Par exemple, un employé mécontent pourrait voler des informations de carte à la sienne, puis utilisez votre mécanisme de hachage contre vous en insérant des hachages valides dans la liste noire de votre numéro de carte pour bloquer les activités de répétition. Il est assez coûteux de l'annuler si vous stockez simplement une hachage, tout est opaque une fois qu'elle a été convertie en hachage. Dans cet esprit, donnez-vous une méthode pour identifier également la source du hachage.
Peut-être que je suis naïf mais sans l'information du nom sur la carte ou la date d'expiration, que peut-on faire avec seulement le numéro de la carte?
Le nom du titulaire de la carte n'est pas utilisé au moment de la vente par les processeurs pour décider de rejeter ou d'approuver une transaction. Il peut être utilisé ensuite par n'importe quel nombre de parties dans la chaîne de traitement ou par le logiciel qui l'a transmis. Il n'est donc pas utilisable comme une barrière ou une protection au moment d'une tentative de transaction. La date d'expiration importe, mais certains ISOS / processeurs fournissent des recherches en direct pour les transactions de test. Cela permet de brute la force des mois d'avant 120 mois pour une date d'expiration d'une carte donnée si vous avez accès à un tel compte de test.
Peut-être que vous pouvez stocker deux différents hachages du numéro de carte. Les chances que les deux hachages entraîneront des collisions sont pratiquement zéro.
C'est une idée vraiment intéressante. Merci de le partager.
Ne vous inquiétez pas de faire des sels, utilisez simplement des hmacs. Je sais que c'est une sorte d'abus, mais vous obtenez alors un hachage clé décent, vous pouvez donc empêcher les collisions et les attaques de table arc-en-ciel.
La bonne chose ici est que même si la clé fuit, personne ne peut le déchiffrer. La meilleure chose qui fonctionne pour les HMACS est une force brute. En fait, la clé ici est un sel tel que mentionné précédemment. La bonne chose ici est que l'algorithme est un peu mieux que les substances salissantes habituelles effectuées par la plupart des programmeurs non sécurisés.
Comme Henri déjà mentionné ci-dessus (+1), la bonne solution consiste à utiliser le code d'authentification de message tel que HMAC avec une clé secrète. C'est exactement le "sel secret" qui a mentionné auparavant. (BTW. Les sels sont toujours publics).
Utilisez une construction standard telle que HMAC-SHA-256 (RFC2104, FIPS-198A), conservez le secret de la clé et stockez les résultats (Tags d'authentification) dans une base de données.
La taille de la plus grande taille (256 bits) de SHA-256 devrait empêcher toute collision de se produire, SHA-256 est une assez bonne fonction de hachage et une probabilité de collisions aléatoires est de 2 ^ -128, donc si vous rencontrez une collision dans votre système, s'il vous plaît, faites-moi savoir! :)
Les gens soulignent qu'un hachage est «brisé» manquait le point, peut-être régurgiter quelque chose qu'ils ont entendu sans comprendre ce que cela signifie. Lorsque les gens parlent de hashes étant «cassé», ils signifient généralement qu'il est possible de générer facilement une charge utile alternative qui a calculé au même hachage.
Ceci "casse" le hachage, mais uniquement dans le but spécifique d'utiliser un hachage pour vérifier que les données sont censées être.
Ce n'est pas l'important ici, c'est-à-dire que quelqu'un gère de créer une alternance de données de données sur la même valeur que l'une des cartes de crédit n'atteint rien de significatif ou utile en termes de vecteur d'attaque. < / p>
Le risque avec les hachages ici est que l'espace problématique des numéros de carte de crédit est assez bas et les tables arc-en-ciel pour eux seraient assez bon marché et faciles à générer.
L'ajout d'un sel ajouterait un peu de protection contre les tables arc-en-ciel déjà générées pour les numéros de carte pure, mais la mesure dans laquelle elle offre une protection réelle dépend de la manière dont le sel resterait "secret" dans le cas où vous êtes compromis. Si le sel est exposé, les nouvelles tables arc-en-ciel peuvent alors être produites à moindre coût et tout est fini.
Étant donné que le sel doit être disponible pour que l'application soit disponible pour effectuer des chèques contre la liste noire, une bonne chance que quelqu'un compromette les données de la liste noire sera également en mesure d'accéder au sel. Si vous avez plusieurs serveurs, vous pouvez atténuer cela à une certaine mesure en garantissant à la fois le sel et que les données ne sont pas dans le même «endroit», une exposition d'un serveur ne donnera pas à une personne toutes les pièces dont elles ont besoin. (De même pour les sauvegardes ne stockez pas les données et le sel sur le même support où quelqu'un peut partir avec une bande et tout obtenir). Le sel ajoute seulement une certaine protection alors qu'il est secret (dans ce type d'utilisation).
Si vous avez les ressources nécessaires pour le faire de manière sécurisée, je pense que c'est la voie à suivre. Si vous obtenez un nombre important de collisions sur une fonction de hachage raisonnable, vous devez faire beaucoup de volume. (En fait, je suis des collisions très surprises surprises, une fonction de hachage raisonnable devrait fournir diverses résultats sur un petit espace de problème comme celui-ci).
Comme d'autres l'ont dit, HMAC devrait être la voie à suivre.
HMAC-SHA-256 avec une clé appropriée devrait:
C'est avec une bonne raison que vous ne stockez pas les numéros de carte de crédit. Même si vous pouviez être sûr à 100% que vous utilisez un cryptage approprié, vous ne stockez probablement pas les numéros de carte de crédit. Pourquoi? Pour une chose, parce que la clé pourrait être divulguée .
Alors vous stockez les hachages, de sorte que le numéro de carte de crédit ne puisse pas être récupéré. ... Droite?
Eh bien, si vous utilisez un hachage uni, une simple table arc-en-ciel avec des hachages de tous les numéros de carte de crédit possibles donne toutes les données originales que vous n'avez probablement pas stockées. Oups. Mais cela vous connaissez maintenant.
Nous essayons donc de faire mieux. Disons que d'utiliser des sels individuels est meilleur et en utilisant HMAC est la meilleure approche que nous connaissons.
Considérez le scénario suivant:
Cela laisse 5 chiffres pour être forcé brute. c'est un maigre tentatives de 100 000.
Si nous avons utilisé les sels individuels, c'est le jeu. Nous pouvons simplement brut-forcer chaque numéro de carte individuel à une moyenne de 50 000 tentatives.
Si nous avons utilisé HMAC, nous semblons être en sécurité. Mais rappelez-vous ... Nous choisissons de ne pas stocker les numéros de carte cryptés, car même avec un cryptage parfait, la clé pourrait être divulguée . Devinez quoi. Notre clé HMAC peut être divulguée exactement la même chose. Avec la clé, encore une fois, nous pouvons brut-forcer chaque numéro de carte individuel à une moyenne de 50 000 tentatives. Donc, une clé fuite nous donne les numéros de carte de crédit, comme si nous avions stocké des numéros de carte cryptés.
En tant que tel, un peu de perspective:
OK, nous supposons une clé fuite ici. Extrême. Mais à nouveau, PCI dans le cadre de leur raisonnement vous interdire de stocker des numéros de carte de crédit, nous devrions donc le considérer au moins.
True, je n'ai pas pris en compte les suppositions multiples pour trouver la corbeille. Cela devrait être une petite constante, cependant. Ou nous pourrions nous limiter à un bac.
Certainement, un auditeur PCI peut être plus indulgent que moi.
Oui, si vous ne stockez pas le numéro de carte masqué, vous êtes un facteur 10'000 plus sûr. Cela aide beaucoup. Utilisez-le à votre avantage. Néanmoins, si 50k tentatives sont faisables, 500 m peuvent également être faisables. Il ne suffit pas de me faire prendre en compte les données sécurisées, dans le contexte d'une clé compromise.
Conclusion:
Utilisez HMAC-SHA-256. Comprendre le risque. Stocker aussi peu que possible. Protégez vos clés vigilantes. Passez une fortune sur un module de sécurité matérielle: -)