Stocker des Numéros de Carte de Crédit en SESSION - des moyens autour d'elle?
Je suis bien conscient de la Conformité PCI, donc n'ont pas besoin d'une bonne dose sur le stockage des numéros de CC (et surtout CVV nums) au sein de notre entreprise de base de données lors du processus de commande.
Cependant, je veux être sûr que possible lors de la manipulation des consommateurs sensibles à l'information et je suis curieux de voir comment la contourner en passant CC les numéros de page en page SANS l'aide des variables de SESSION, si possible.
Mon site est construit de cette façon:
- Étape 1) recueillir de Carte de Crédit
l'information de la clientèle - lorsque
client hits soumettre, le
l'information est d'abord exécuté par JS
la validation, puis exécuter par le biais de PHP
la validation, si toutes les passes qu'il se déplace
à l'étape 2. - Étape 2) l'Information est affichée sur
une page de révision pour le client à faire
assurez-vous que les détails de leur prochain
des transactions sont affichés. Seul le
les 6 premiers et les 4 derniers de la CC sont
montré sur cette page, mais le type de la carte,
et exp date sont shwon entièrement. Si il
clique sur continuer, - Étape 3) L'information est envoyée à
une autre page php qui s'exécute une dernière
validation, envoie des informations
par le biais de la passerelle de paiement sécurisé, et
la chaîne renvoyée est avec des détails. - Étape 4) Si tout est bon et bien, le
l'information des consommateurs (personnel, pas
CC) est stocké dans la bd et la redirection
pour une page de fin. Si quelque chose est
mauvais, il est informé et a dit à
revoir le CC et la page de traitement de
essayez à nouveau (avec un maximum de 3 fois).
Des suggestions?
MODIFIER
J'ai reçu beaucoup de très bonne réponse sur cette question à la majorité semblent être d'accord sur les points suivants:
- prendre variables POST après
l'exécution de la validation - chiffrement ccnum et le cryptogramme de sécurité (pas sûr
vous êtes autorisé à stocker des cvv en DB
à tous cependant) - Le stockage temporaire de la DB
- Accès DB immédiatement après la "révision"
la page est OK avais - déchiffrer les détails de DB
- envoyer des informations à processeur
- recevoir de réponse
- résilier DB
Je pense que cela a un sens global. Quelqu'un at-il une bonne méthode pour le chiffrement/déchiffrement avec la meilleure façon de créer de la temp DB info qui est automatiquement supprimé au plus tard à l'appel?
Je suis à la programmation en PHP et MySQL DB
EDIT #2
Je suis tombé sur des Paquets Générale, ce qui semble être une solution idéale, mais VRAIMENT ne voulez pas payer pour une autre licence de logiciel pour atteindre cet objectif.
http://www.packetgeneral.com/pcigeneralformysql.html
EDIT #3 - Exemple de Code
Maintenant j'ai posté un exemple de code que j'ai mis ensemble à essayer de faire sens de chiffrement/déchiffrement et de stockage mentionné dans ce post. J'espère que, déjà utile contributeurs peuvent valider et d'autres sont en mesure d'utiliser des fonctionnalités similaires. Pour des raisons de longueur, je ne vais pas entrer dans les méthodes de validation utilisée pour la CC num lui-même.
Formulaire De Saisie
<form action="<?php $_SERVER['PHP_SELF']; ?>" method="POST">
<input type="text" name="CC" />
<input type="text" name="CVV" />
<input type="text" name="CardType" />
<input type="text" name="NameOnCard" />
<input type="submit" name="submit" value="submit" />
</form>PHP Chiffrer et Stocker des Données
<?php
$ivs = mcrypt_get_iv_size(MCRYPT_DES,MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($ivs,MCRYPT_RAND);
$key = "1234"; //not sure what best way to generate this is!
$_SESSION['key'] = $key;
$ccnum = $_POST['CC'];
$cvv = $_POST['CVV'];
$cctype = $_POST['CardType'];
$ccname = $_POST['NameOnCard'];
$enc_cc = mcrypt_encrypt(MCRYPT_DES, $key, $ccnum, MCRYPT_MODE_CBC, $iv);
$enc_cvv = mcrypt_encrypt(MCRYPT_DES, $key, $cvv, MCRYPT_MODE_CBC, $iv);
$enc_cctype = mcrypt_encrypt(MCRYPT_DES, $key, $cctype, MCRYPT_MODE_CBC, $iv);
$enc_ccname = mcrypt_encrypt(MCRYPT_DES, $key, $ccname, MCRYPT_MODE_CBC, $iv);
//if we want to change BIN info to HEXIDECIMAL
//bin2hex($enc_cc)
$conn = mysql_connect("localhost", "username", "password");
mysql_select_db("DBName",$conn);
$enc_cc = mysql_real_escape_string($enc_cc);
$enc_cvv = mysql_real_escape_string($enc_cvv);
$enc_cctype = mysql_real_escape_string($enc_cctype);
$enc_ccname = mysql_real_escape_string($enc_ccname);
$sql = "INSERT INTO tablename VALUES ('$enc_cc', '$enc_cvv', '$enc_cctype', '$enc_ccname');
$result = mysql_query($sql, $conn) or die(mysql_error());
mysql_close($conn);
Header ("Location: review_page.php");
?>PHP décryptage des données et l'envoi de la passerelle
$conn = mysql_connect("localhost", "username", "password");
mysql_select_db("DBName",$conn);
$result = mysql_query("SELECT * FROM tablename");
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_ccnum, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_cvv, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_cctype, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_ccname, MCRYPT_MODE_CBC, $iv);
mysql_close($con);
?>alors procéder à prendre les données qui viennent d'être envoyé dans la chaîne et de l'utilisation de la Passerelle de présentation. Semble juste?
- Appelez-moi fou, mais je pense que c'est plus facile pour enregistrer le chiffrés numéro de CC en session. Si elle n'est pas supprimée pour quelque raison que ce soit, il va disparaître lors de la session expire.
- HOMME VOUS TELLEMENT FOU! En toute sincérité, est-il semblable à la menace TC affichés ci-dessous? Ma compréhension est que si une SESSION est détourné alors vous avez maintenant la clé et le numéro de la carte exposés.
- Hrm... je suppose que ça dépend de l'endroit où vous gardez la touche. Je voudrais utiliser deux clés de toute façon. Une codé en dur, une clé et une clé qui change avec le client/la session. Pourrait être généré de façon aléatoire pour chaque session, plus basé sur l'agent utilisateur (adresses IP de soi-disant ne sont pas bons parce qu'ils peuvent changer en raison de l'itinérance). De cette façon, si la clé aléatoire est détourné, ils ont encore besoin d'accéder à votre code pour voler la clé, ou si ils l'ont fait, j'espère qu'ils ne sont pas assez rapides pour choper la clé aléatoire.
- ...de toute façon, je pense que l'idée est de garder la clé et le numéro de CC séparé. Je pense qu'il y a essentiellement 4 endroits pour stocker des choses. 1) codée en dur, 2) dans la DB, 3) dans la session, 4) sur le client. 1) ne peut pas être changé, il est seulement bon pour l'enregistrement d'une clé constante. Si 3) est compromise, je dirais que 2) pourrait être contraint de céder sa info, à moins que vous n'avez pas de 3). Et 4) doivent absolument être utilisés pour s'assurer que vous êtes toujours en parler à la même client et non pas un hacker qui essaie de voler sa place.
- ...en supposant que vous êtes l'exécution de ce sur SSL et vous avez sécurisé activé les cookies, vous ne devriez pas être en mesure de détourner la session, donc je ne pense pas qu'3) est presque aussi mauvais que les gens font dehors pour être. Profitez de tous les 4 si vous pouvez trouver un moyen.
- ne pas utiliser <form action="<?php $_SERVER['PHP_SELF']; ?>" method="POST"> utiliser <form action="" method="POST"> au lieu que le premier type est sensible à l'injection.
- Détournement de Session se réfère à voler le cookie de session (stocké sur le client), pas la session de données (stockées sur le serveur). Si vous voler le cookie de session, il n'est pas n'importe où sur le serveur de stockage des données.
- Aussi, s'il vous plaît ne pas utiliser DES. Il a été fissuré à plusieurs reprises.
- merci pour les conseils. J'ai été vraiment à l'aide de l'exemple de code pour montrer l'ensemble du processus. Avez-vous de cryptage vous le recommande?
- J'aimerais savoir pourquoi cette question a été downvoted un an après le fait?
Vous devez vous connecter pour publier un commentaire.
Envisager de modifier votre processus de commande, de se débarrasser de la nécessité de stocker des informations de carte de crédit.
Page 1: l'Utilisateur entre les non-cartes de crédit, les informations de commande, à l'instar de livraison et adresse de facturation
Page 2: l'Utilisateur vérifie non de la carte de crédit, les informations de commande, entre informations de carte de crédit, et clique sur "Payer Maintenant" (ou "Modifier l'Ordre" s'ils veulent changer les choses)
Étape 3: l'Info est transmis via un $_POST demande à un SSL page, ce qui achève de serverside contrôles, soumet des données de carte de crédit pour le processeur, et oriente l'utilisateur vers un succès ou d'erreur de la page en fonction de la réponse.
De cette façon, vous éviterez une brume de problèmes techniques et des problèmes de conformité. Le stockage de données de carte de crédit dans une base de données ou un cookie, même pour une courte période de temps, même si elle est cryptée, signifie que vous êtes responsable d'un niveau plus élevé de conformité à la norme PCI. La seule différence est que vous ne serez pas en mesure de montrer une "vérifier la commande" à la page avec les détails de carte de crédit. Et quelle grande différence est que, étant donné que votre "vérifier la commande" page peut même pas montrer l'intégralité de numéro de carte de crédit?
Stocker les détails de la carte à tout persistance moyenne (base de données, peu importe), mais de crypter le numéro de carte unique et aléatoire clé que vous stockez dans la session. De cette façon, si la session est perdue, la clé est trop - ce qui vous donne suffisamment de temps pour nettoyer à fond expiré/abandonné données.
Assurez-vous également que vos séances sont protégées contre le piratage. Il y a des solutions matérielles pour cela, mais un simple code de façon de faire est de prendre l'ID de session à un hachage du premier octet de l'adresse IP, plus l'agent de l'utilisateur. Pas infaillible, mais ça aide.
Modifier:
La clé de bits pour la réduction des risques est de s'assurer que vous vous débarrasser de cette info dès que possible. Juste après la transaction passe par, suppression de l'enregistrement de la base de données. Vous avez également besoin d'un rouleau d'emploi (tous les 5 minutes) qui supprime tous les enregistrements de plus de votre délai d'expiration de session (habituellement 20 minutes). Aussi, si vous utilisez une base de données pour cette très temporaire de données, assurez-vous qu'il n'est pas sur un système automatisé système de sauvegarde.
Encore une fois, cette solution n'est pas infaillible et je ne suis même pas sûr à 100%, il est compatible avec la CC exigences en matière de sécurité. Cependant, il devrait exiger un attaquant total d'exécution le contrôle de votre environnement activement décrypter client CC info, et si un instantané de votre base de données est compromise (beaucoup plus probable/commun), un seul CC peut être brute forcé à un moment, qui est sur le mieux que vous puissiez espérer.
Je sais que vous avez mentionné que vous êtes conscient de la conformité PCI, mais en utilisant l'une des méthodes déjà décrites (par exemple, la persistance de la carte, le numéro de disque de n'importe où) va tomber sous le coup de PCI et de dire que vous avez un cauchemar de la conformité des maux de tête à l'avance de vous. Si vous avez vraiment insister sur la persistance de la carte numéro de disque, alors vous pourriez aussi bien obtenir un PCI maintenant pour vous aider à travers le processus et de vous offrir des conseils. Finalement, ils vont avoir besoin de valider la méthode que vous avez pris est approprié.
Comme un exemple, un grand nombre de réponses ici en parler à l'aide du chiffrement. C'est le plus difficile restait à faire. Ils n'ont pas parlé de gestion de clés qui est de manière significative plus difficile
Je pense donc qu'il serait préférable de soumettre les détails de la carte à la passerelle de paiement dès qu'elles sont collectées. Un bon nombre de passerelles de paiement vous permettra d'effectuer un magasin seulement le style de la transaction, qui sera la base de la validation des détails de carte et de stocker le numéro de la carte à leur (déjà conforme aux normes PCI) du serveur, et vous renvoie un id de jeton à la place. Cette méthode signifie que vous NE pas stocker le numéro de la carte/cvv2 n'importe où sur vos serveurs, et la conformité PCI devient un énorme montant plus facile.
Plus tard dans le processus de commande, vous utilisez l'id de jeton de présenter une autorisation et de règlement.
PCI vous permet de stocker les six premiers/les quatre derniers chiffres (et date d'expiration) de la cardnumber en clair, de sorte que vous pouvez capturer en toute sécurité ceux où vous êtes à l'aise, de sorte qu'ils peuvent être réaffiché juste avant la dernière étape.
Est-il une raison vous ne pouvez pas sauter l'étape de confirmation et il vous suffit de soumettre immédiatement la transaction?
Je ne vois pas pourquoi le garder dans une base de données est un plus sûr que de le garder dans une variable de session serveur compromis sera toujours donner le numéro de carte de crédit, mais si vous le gardez dans la session, il est beaucoup moins susceptibles d'être écrites sur le disque. Vous pouvez crypter si vous le souhaitez, mais l'utilité de ce qui est douteux (ça va encore être échangés sur le disque). L'ajout d'une autre machine pour faire de stockage crypté n'aide pas non plus, puisque la machine compromise pouvez simplement demander à l'autre de faire le décryptage.
EDIT: Viens de penser à ceci:
Un attaquant a besoin de compromettre à la fois le client et le serveur pour obtenir le numéro de carte de crédit (par exemple un attaquant aurait probablement le nombre déjà de toute façon). Un serveur en ligne compromis sera toujours obtenir les numéros de carte de crédit de transactions futures, mais vous ne pouvez pas vraiment un arrêt.
EDIT: Et j'ai oublié les détails. Pour l'ensemble de ces régimes (pas que le mien), vous avez également besoin d'un MAC pour prévenir les attaques de relecture (ou Eve distrait Alice, modifie le panier et l'adresse de facturation, puis cliquez sur "valider" de la page...). En général, vous voulez avoir un MAC sur toutes les données de transaction que vous avez (CC, le CRYPTOGRAMME de sécurité, ID de transaction, le montant de la transaction, adresse de facturation...).
Vous êtes de droite, à l'aide de sessions est très précaire, pour le stockage de données sensibles, il existe des moyens de percer dans les sessions avec ce qui est connu comme:
Détournement de Session
Fixation de Session
La manière la plus sûre qui me vient à l'esprit est que stocker les infos dans la base de données (temporaire temps), puis lire la valeur sur la page où vous en avez besoin. Une fois que vous avez fini de le faire, vous pouvez le supprimer en arrière.
Noter que:
Vous pouvez trouver cette reflectively utile 🙂
Il semble que de toute façon vous le touchez, vous aurez besoin de fournir pour sécuriser le numéro de carte de crédit de capacités de stockage. Si le serveur est compromis, à tout moment, il va contenir suffisamment d'informations pour décrypter actuellement stockés numéros de carte de crédit (c'est à dire les touches et chiffrée des nombres). Solution possible est d'utiliser un serveur interne, qui agit comme un "encryptor/decryptor" service et rien d'autre. Cette façon de compromettre une machine n'expose pas les numéros de carte de crédit.
Il y a une autre façon, mais elle exige de l'Ajax. Pas de stockage de numéros de carte de crédit ET une page de révision.
Page 1: Formulaire de capture d'expédition, la facturation et les informations de carte de crédit. S'assurer que le "corps" de la page, y compris la forme, est dans un DIV avec un ID unique pour vous permettre de référence avec JavaScript.
Page 2: Un fichier sur le serveur qui va accepter un GET/POST demande avec les champs du formulaire et le retourner correctement formaté "examen" de la page à votre goût.
Processus de commande:
C'est un peu un hack, mais quand c'est fait correctement, il est 100% transparente pour l'utilisateur et permet une transmission unique de la carte de données sans avoir à assumer les risques associés avec le temp DB stockage, etc.
C'est ce qu'une base de données. Je ne suis pas sûr de les ramifications légales ici (qui varient en fonction du pays et de la région), mais une approche pourrait être de crypter le numéro de CC et de les stocker dans la base de données dès que vous la recevez de l'utilisateur. Vous pouvez stocker les 4 derniers chiffres dans un champ distinct de sorte que vous pouvez montrer à l'utilisateur si nécessaire. Lorsque vous avez besoin d'interagir avec le processeur de la carte sur le serveur, de récupérer et de déchiffrer le numéro de la carte à partir de votre base de données.
Voici comment j'ai l'intention de le faire - tout sur https à l'aide de ssl de cours.
L'étape 1. L'utilisateur entre les CC info et appuie sur le bouton suivant. Le CC info est enregistré immédiatement à la CC du processeur DB, et non votre propre DB ou si vous voulez rompre la Conformité PCI. Le CC n'est pas réellement facturé cette étape. Mais vous devriez recevoir certaines ID unique à partir du processeur de l'identification de la CC info. (stocker l'id unique de votre base de données si vous le souhaitez)
L'étape 2. Sur la page de confirmation, de récupérer la CC des informations à partir de la CC du processeur à l'aide de l'identifiant unique que l'on te donne. Mon processeur ne permettez-moi de récupérer les 4 derniers chiffres de la CC de toute façon.
L'étape 3. Après ils confirmer l'achat et appuyez sur le achetez bouton, la charge de la carte de crédit en utilisant l'id unique.
L'étape 4. Rediriger vers une page de remerciement contenant la facture/réception qui a seulement les 4 derniers chiffres de la CC (bien sûr, vous n'avez pas à afficher les 4 derniers de la CC, mais je pense que c'est une belle chose à montrer).
Vous pouvez stocker une table de hachage de la carte n ° dans la séance et le même hachage et le nombre réel et de l'utilisateur, l'id de session dans une base de données. Ensuite, pour chaque page, vous pouvez vérifier le hachage et la session des informations pour obtenir la carte nr.
À un certain point plus tard dans le traitement des paiements (dernière partie de l'étape 3), vous aurez besoin de chiffrer le CC# (et CVC) pour être en mesure de l'envoyer au processeur de paiement (je suppose)
Pourquoi ne pas faire de chiffrement à droite quand vous recevez l'information, à côté de la dissimulation nécessaire pour que la page de confirmation. (c'est la dernière partie de l'étape 1)
À partir de maintenant, ne fonctionnent qu'avec cette chiffré ou dissimulé des données, faire des CC-compagnie de la seule personne qui peut réellement décrypter les données complètes.
Il n'est pas nécessaire pour les sessions ou de la base de données pour conserver les informations.
Chaque page est un formulaire qui affiche les données. Sur chaque page les variables post de la page précédente sont ajoutés les champs de formulaire masqué de sorte que le lendemain de l'envoi de formulaire postes à nouveau les données. De cette façon, rien n'est jamais stockée, mais l'information est effectuée à partir de la page à page. Cette force également à l'utilisateur de compléter le processus du début à la fin, sans essayer de sauter les étapes.
Tant que le formulaire est soumis par le protocole HTTPS, les données sont cryptées automatiquement et la charge de la sécurité est à votre fournisseur de certificats SSL.
De nombreux sites de commerce en œuvre. Par exemple OSCommerce.
Utilisation De La Segmentation. Son PCI DSS complient.
Plus peut être fouhd ici,
https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf