2012-06-15 11 views
6

मैंने पहले से ही Saving credit card information in MySQL database? और Storing Credit Card Information पढ़ा है।डेटाबेस में क्रेडिट कार्ड की जानकारी को सुरक्षित रूप से एन्क्रिप्ट कैसे करें

मुझे पता है कि क्रेडिट कार्ड की जानकारी संग्रहीत करने के लिए पीसीआई अनुपालन की आवश्यकता है, जो एक आसान काम नहीं है।

यह सवाल इस बारे में नहीं है। मेरा प्रश्न निम्न है:

उपयोगकर्ता क्रेडिट कार्ड एन्क्रिप्ट करने का एक सुरक्षित तरीका क्या है? दिमाग में आता है सबसे सरल और आसान एक निजी कुंजी का उपयोग कर रहा है और इसके साथ सीसी एन्क्रिप्ट कर रहा है। यह बहुत सुरक्षित प्रतीत नहीं होता है क्योंकि कुंजी को सर्वर पर संग्रहीत किया जाना चाहिए, और यदि कोई हमलावर मेरा डेटाबेस प्राप्त कर सकता है, तो शायद वे भी कुंजी प्राप्त कर सकते हैं।

मैं जो करने में सक्षम होना चाहता हूं वह एन्क्रिप्शन प्रक्रिया के हिस्से के रूप में उस उपयोगकर्ता पासवर्ड का उपयोग करके प्रत्येक सीसी को एन्क्रिप्ट करता है। अगर कोई डेटाबेस प्राप्त करता है, तो वे कुछ भी डिक्रिप्ट नहीं कर सकते हैं क्योंकि पासवर्ड नमकीन हैंश के रूप में संग्रहीत होते हैं। यह लेनदेन की खरीद के लिए बहुत अच्छा काम करेगा - उपयोगकर्ता पुष्टि के रूप में अपने पासवर्ड में "खरीदें," प्रकार क्लिक करता है, मैं अपने सीसी को डिक्रिप्ट करता हूं और चार्ज करता हूं। उनका पासवर्ड केवल अनुरोध की अवधि के लिए स्मृति में है, और डिस्क पर कभी लिखा नहीं जाता है।

दुर्भाग्य से यह जो मैं बनाने की कोशिश कर रहा हूं उसके लिए यह काम नहीं करेगा - एक सेवा जो पुनरावर्ती शुल्क (कहें, एक महीने में एक बार) का शुल्क लेती है, भले ही उपयोगकर्ता को लॉग इन करने की आवश्यकता हो या नहीं चार्ज।

इस परिदृश्य को देखते हुए, क्या उपयोगकर्ता सीसी को स्टोर करने का एक सुरक्षित तरीका है?

+0

क्या सर्वर * सीसी जानकारी * स्टोर करता है * जानकारी को * पढ़ने में सक्षम होना चाहिए? जैसे यदि मासिक शुल्क एक ऑफ़लाइन मशीन द्वारा किया जा सकता है जो एन्क्रिप्टेड डेटा की प्रतिलिपि पढ़ता है, तो आप सार्वजनिक कुंजी विधियों पर विचार करना चाहेंगे ... –

+0

संभवतः सिस्टम हमेशा कनेक्ट होता है, और जब भी कोई उपयोगकर्ता पंजीकृत होता है तो डेटा उसे भेजा जा सकता है । हां, एक विशेष इंटरफेस के साथ सुरक्षित करना आसान है लेकिन बाहरी अनुप्रयोग का तात्पर्य है; और शायद मानक वेब सॉफ़्टवेयर नहीं, अन्यथा यह मूल मेजबान के रूप में कई समान भेद्यताएं प्रदर्शित करता है। तीसरे पक्ष के विशेष ऑफ़साइट समाधान वास्तव में मौजूद हैं जो वास्तव में मौजूद हैं। – shannon

उत्तर

0

आपको कार्ड की जानकारी को विपरीत रूप से एन्क्रिप्टेड होने की आवश्यकता है। डिक्रिप्शन जानकारी कहीं से आनी है। आपने कहा है कि डेटा उपयोगकर्ता से नहीं आ सकता है, और आप इसे सर्वर पर संग्रहीत नहीं करना चाहते हैं, इसलिए यह अलग-अलग उपकरणों पर होना चाहिए जो संभवतः अधिक सुरक्षित है। और यदि आपके पास उस जानकारी को याद करने की क्षमता है, तो ऐसे हमलावर ने आपके सिस्टम से समझौता किया है। तो संभवतः डिक्रिप्शन के दौरान कमजोर मेजबान पर डिक्रिप्शन जानकारी पुनर्प्राप्त नहीं की जाती है।

शायद एक तृतीय-पक्ष सेवा पर विचार करें जिसे आप एन्क्रिप्ट कर सकते हैं और जानकारी भेज सकते हैं, शायद पीसीआई अनुपालन में माहिर हैं। यह क्रेडिट कार्ड की जानकारी को डिक्रिप्ट करने में सक्षम हो सकता है जब आप इसे दूसरी बार भेजते हैं और शुल्क लागू करते हैं, या यह वास्तव में बाद में उपयोग के लिए कार्ड की जानकारी संग्रहीत कर सकता है। यह आपके लिए आवर्ती लेन-देन भी कर सकता है।

http://www.authorize.net/solutions/merchantsolutions/merchantservices/automatedrecurringbilling/

मैं सिर्फ Google पर कि, मैं उन्हें सलाह नहीं देते। लेकिन यह एक उदाहरण है।

+0

@OP: लेनदेन की व्यवस्था के दौरान कार्ड को आयोजित करने के लिए धोखाधड़ी रोकथाम प्रणालियों को सत्यापन कोड की आवश्यकता होती है, लेकिन व्यापारियों को "आवर्ती" के रूप में लेनदेन की पहचान करने की क्षमता प्रदान करते हैं, और सत्यापित स्थिति पुनरावर्ती लेनदेन के माध्यम से बनी रहती है। आवर्ती लेनदेन के लिए कार्ड प्रोसेसिंग एजेंसी अभी भी कार्ड नंबर को सुरक्षित रखती है, लेकिन सीवीवी 2 नहीं। यदि आप अधिक जानना चाहते हैं तो Google क्रेडिट पुनरावर्ती लेन-देन सर्वोत्तम प्रथाओं, लेकिन आम तौर पर मुझे लगता है कि आप किसी और को यह उठाने के लिए करेंगे। – shannon

3

जैसा कि आपको डिक्रिप्ट करने में सक्षम होने की आवश्यकता है, हमेशा यह संभावना है कि एन्क्रिप्शन कुंजी रिसाव हो और आप सब कुछ खो देंगे। तो आप कभी भी पूर्ण सुरक्षा प्राप्त नहीं करेंगे, लेकिन आप डेटा पर पहुंचने के लिए हमलावरों के लिए कठिन बना सकते हैं।

कोई भी नहीं, लेकिन आप वास्तव में यह तय कर सकते हैं कि आपको किस स्तर की सुरक्षा (या अस्पष्टता) होनी चाहिए। यह संभवतः डेटाबेस, दृश्यता इत्यादि के आकार का एक कार्य है।

लीक के लिए, दुर्भाग्यवश आपको यह मानना ​​होगा कि सबकुछ लीक और जल्दी या बाद में (उदाहरण के लिए कमजोर पासवर्ड पर ब्रूट फोर्स हमलों के साथ) आपको प्राप्त नहीं हुआ है जब वे बाहर निकलते हैं तो बहुत अधिक।

अंतिम क्रेडिट कार्ड रिसाव घोटालों को देखते हुए - सबसे खराब लोगों के पास नियमित क्रेडिट कार्ड नंबर से बचाया गया 3-अंकों (सीवीवी) नंबर था, जो क्रेडिट कार्ड कंपनियां स्पष्ट रूप से मना करती हैं (यही कारण है कि आपको हमेशा इसे फिर से देना होगा भले ही किसी के पास फ़ाइल पर आपकी क्रेडिट कार्ड की जानकारी हो)

यदि आप इस तरह के डेटा को धारण करने और संसाधित करने की ज़िम्मेदारी नहीं लेना चाहते हैं, तो जाने का एक अच्छा तरीका बाहरी भुगतान सेवा के साथ है - उन्हें करने दें प्रसंस्करण और सिर्फ आपको दावा है कि भुगतान संसाधित किया गया है। आपको उन्हें अपनी सेवाओं के लिए भुगतान करना होगा, लेकिन आपको अपने स्वयं के समाधान को लागू करने और जोखिम लेने के लिए भी भुगतान करना होगा।

+0

आप और शैनन दोनों ने बाहरी सेवाओं का उल्लेख किया है, जैसे authorize.net। यदि 3 अंकों की संख्या को स्टोर करना अवैध है तो वे सेवाएं आवर्ती बिलिंग को कैसे लागू करती हैं? क्या उनके पास क्रेडिट कार्ड कंपनियों के साथ कुछ प्रकार का सौदा है? –

+0

क्षमा करें, आपकी मदद नहीं कर सकते हैं। मुझे केवल * पता है कि * क्रेडिट कार्ड कंपनियां 3 अंकों को रखने के लिए मना करती हैं। वे अपने आवर्ती में एक तरह का भुगतान के रूप में "पुनरावर्ती भुगतान" की पेशकश कर सकते हैं, लेकिन यह सिर्फ एक जंगली अनुमान है। –

+1

बिल्कुल। "पुनरावर्ती भुगतान" एक ऐसा विकल्प है जिसे लेनदेन के समय स्थापित किया जा सकता है। – starlocke

3

आप सीसी एन्क्रिप्शन के लिए नमक के रूप में पासवर्ड का उपयोग करते हैं, यह जानकारी हासिल करने के एक बहुत प्रभावी तरीका हो सकता है, तथापि, वे कभी नहीं ... उनके पासवर्ड बदलने के लिए इसे बदल गया है, तो सक्षम हो जाएगा तो एन्क्रिप्टेड डेटा खो गया है। एन्क्रिप्शन कुंजी को सुरक्षित करने के लिए नीचे की रेखा को खोजने के लिए जितना संभव हो सके उतना मुश्किल बनाना है ... अनिवार्य रूप से आप कुंजी को छिपाने के लिए जितने अधिक कदम उठाते हैं, उतना कठिन है कि उन्हें ढूंढना ... जिसका अर्थ है कि यह कठिन है आप इसके लिए उपयोग और कार्यक्रम के लिए। सबकुछ बचाने के लिए इस समय कोई जादू बुलेट नहीं है। (कुंजी रखने के लिए एक सुरक्षित तरीका आविष्कार और आप अमीर हो जाएगा)

सीवीवी नंबर के लिए, यह जमा नहीं किया जा सकता है जैसा कि पहले उल्लेख के रूप में। प्रत्येक लेनदेन के साथ सीसी प्रसंस्करण कंपनी व्यापारी को एक संदर्भ संख्या प्रदान करेगी जिसका उपयोग प्रत्येक पुनर्विक्रय भुगतान में किया जाता है। इसका मतलब है कि मूल लेनदेन को सीवीवी नंबर की आवश्यकता होती है, तो तर्क यह निर्देश देगा कि पुनरावर्ती भुगतान उसी उपयोगकर्ता द्वारा भी अधिकृत किया जाएगा जो इसे पहले लेनदेन में डालता है। इसलिए, पुनर्विक्रय भुगतान को समान स्तर की सुरक्षा बनाए रखने के लिए सीवीवी की आवश्यकता नहीं होगी।

0

आप अनिवार्य रूप से एकाधिक सर्वर इस्तेमाल कर सकते हैं। सीसी को एक कुंजी के साथ एन्क्रिप्ट करें, लेकिन उस कुंजी को एक अलग एन्क्रिप्शन सर्वर पर रखें, केवल विंडोज उपयोगकर्ता के लिए एक मास्टर उपयोगकर्ता नाम और पासवर्ड या जो भी ओएस आप उपयोग कर रहे हैं, द्वारा ही पहुंचा जा सकता है। इस तरह आप अपनी कुंजी सुरक्षित कर रहे हैं, एन्क्रिप्शन के माध्यम से कार्ड चलाने के लिए एंटरप्राइज़ सेवा पर एक सेवाएं स्थापित कर रहे हैं और फिर इसे डेटाबेस में जमा कर सकते हैं।

0

उपयोग php के निजी/सार्वजनिक openssl कार्यों जब उपयोगकर्ता कोई ख़रीदी आप स्मृति में डेटा का उपयोग खरीद बनाने के लिए बनाता है तो आप इसके एन्क्रिप्ट करने के लिए एक सार्वजनिक कुंजी का उपयोग कर जानकारी स्टोर।

बिलिंग की प्रक्रिया के लिए मासिक आप निजी कुंजी को मैन्युअल में मुक्का मारा जा सकता है या कोड में संग्रहीत का उपयोग कर डेटा डिक्रिप्ट। यदि आप एसएसएल कुंजी को कोड में स्टोर करना चाहते हैं और इसे याद रखना या इसे हर बार प्राप्त करना नहीं है। मैं कॉन्फ़िगरेशन चर में संग्रहीत नमक का उपयोग करके कुंजी एन्क्रिप्ट करूँगा + एक यूबी कुंजी खरीदें और 32 वर्ण पासवर्ड उत्पन्न करें + इसके ऊपर अपना पासवर्ड। Yubikey को एक सुरक्षित जगह (एक सुरक्षित लॉल) में स्टोर करें। जब आपको क्रेडिट कार्ड को संसाधित करने की आवश्यकता होती है तो इसे एक स्क्रिप्ट के साथ करें जो पृष्ठभूमि में चलता है और एक ही समय में सभी बिलिंग चलाता है। पासवर्ड बदलने के लिए आपको सभी कार्ड डिक्रिप्ट करने और नई निजी/सार्वजनिक कुंजी का उपयोग करके उन्हें फिर से एन्क्रिप्ट करने की आवश्यकता होगी, या आप केवल निजी कुंजी एसएसएल को डिक्रिप्ट और पुनः एन्क्रिप्ट कर सकते हैं।

जादू :)

0

सीसी जानकारी दो बार एन्क्रिप्ट करें। सबसे पहले, उपयोगकर्ता के पासवर्ड (+ नमक) के आधार पर क्रेडिट कार्ड डेटा एन्क्रिप्ट करें। फिर उस के आउटपुट को सर्वर की कुंजी से एन्क्रिप्ट करें।

जानकारी तक पहुंचने के लिए, आपको इस प्रकार उपयोगकर्ता के पासवर्ड की आवश्यकता होती है (यानी सर्वर की कुंजी का उपयोग करके डिक्रिप्ट करें, फिर पासवर्ड के आधार पर डिक्रिप्ट करें)। यदि डेटाबेस और सर्वर कुंजी से समझौता किया गया है, तो जानकारी अभी भी उपयोगकर्ता के पासवर्ड पर हमला किए बिना खुलासा नहीं है।

यह महत्वपूर्ण है कि उपयोगकर्ता का पासवर्ड आंतरिक एन्क्रिप्शन के लिए है - यह आपको सर्वर एन्क्रिप्शन कुंजी बदलने पर पुनः एन्क्रिप्ट करने की अनुमति देता है।

जब उपयोगकर्ता अपना पासवर्ड बदलता है, तो आप डेटा को फिर से एन्क्रिप्ट भी करते हैं। यदि उपयोगकर्ता अपना पासवर्ड रीसेट करता है, तो सीसी जानकारी मिटा दी जानी चाहिए (और वैसे भी खो गया है, क्योंकि इसे अनएन्क्रिप्टेड नहीं किया जा सकता है)।

संबंधित मुद्दे