मैं क्रेडिट कार्ड की जानकारी स्टोर करने के लिए PHP/mySQL सेटअप लागू करने जा रहा हूं।मैं अपना MySQL डेटाबेस सुरक्षित कैसे रखूं?
ऐसा लगता है कि AES_ENCRYPT/AES_DECRYPT जाने का रास्ता है लगता है,
लेकिन मैं अभी भी एक बिंदु पर उलझन में हूँ:
मैं कैसे एन्क्रिप्शन कुंजी सुरक्षित रहते हो?
इसे मेरी PHP स्क्रिप्ट्स (जो डीबी के समान सर्वर पर लाइव होगा) में हार्डवायरिंग एक प्रमुख सुरक्षा छेद की तरह लगता है।
यहां "सर्वोत्तम अभ्यास" समाधान क्या है?
आपको सीसी # को रखने की ज़रूरत है या नहीं, इसके बारे में आपको लंबे समय तक और कठिन सोचना चाहिए। यदि आपके पास कोई अच्छा कारण नहीं है, तो मत करो! हर दूसरे सप्ताह में आप कुछ कंपनी के साथ समझौता किया जा रहा है और सीसी # चोरी हो रहा है। इन सभी कंपनियों ने घातक दोष पैदा किया - उन्होंने बहुत अधिक जानकारी रखी। लेनदेन को साफ़ होने तक सीसी # रखें। उसके बाद, इसे हटा दें।
जहां तक सर्वर को सुरक्षित किया जा रहा है, कार्रवाई का सबसे अच्छा तरीका हार्डवेयर को सुरक्षित करना और आंतरिक सिस्टम सॉकेट को MySQL पर उपयोग करना है, और MySQL सर्वर पर किसी भी नेटवर्क पहुंच को अवरुद्ध करना सुनिश्चित करें। सुनिश्चित करें कि आप अपनी सिस्टम अनुमतियों और MySQL अनुमतियों दोनों का उपयोग कर रहे हैं ताकि आवश्यकतानुसार कम पहुंच की अनुमति मिल सके। कुछ स्क्रिप्ट के लिए, आप केवल-लेखन प्रमाणीकरण पर विचार कर सकते हैं। वास्तव में कोई एन्क्रिप्शन विधि नहीं है जो मूर्खतापूर्ण होगी (जैसा कि आपको हमेशा डिक्रिप्ट करने की आवश्यकता होगी, और इस प्रकार कुंजी को स्टोर करना होगा)। यह कहना नहीं है कि आपको नहीं करना चाहिए - आप अपनी कुंजी को एक स्थान पर स्टोर कर सकते हैं और यदि आप सिस्टम समझौता का पता लगाते हैं तो आप फ़ाइल को नष्ट कर सकते हैं और डेटा को बेकार कर सकते हैं।
मैं सहमत हूं, लेकिन अगर आपको इसकी आवश्यकता नहीं है तो सीसी नहीं है। लेकिन यदि आपके पास वास्तव में भी है, तो सुनिश्चित करें कि जिस फ़ाइल में यह है वह वेब पर उपलब्ध नहीं है। आप एक बाइनरी लिख सकते हैं जो कुंजी वापस कर देगा। इस तरह यह स्पष्ट पाठ में स्टोर नहीं है। लेकिन अगर आपका सर्वर समझौता कर रहा है तो इसे प्राप्त करना अभी भी आसान है।
आपको जिस सुरक्षा की आवश्यकता है वह आपके आवेदन पर निर्भर करता है। उदाहरण के लिए, यदि सीसी # का उपयोग किया जाने वाला एकमात्र समय तब होता है जब उपयोगकर्ता लॉग इन होता है (पतली ऑनलाइन स्टोर प्रकार परिदृश्य), तो आप सीसी # को उपयोगकर्ता के सादा-पाठ पासवर्ड के हैश के साथ एन्क्रिप्ट कर सकते हैं, प्रति- उपयोगकर्ता नमक, और एक समर्पित सीसी # नमक। इस मूल्य को स्थायी रूप से स्टोर न करें।
चूंकि आप इस मान को संग्रहीत नहीं कर रहे हैं, केवल एक बार जब आप यह मान प्राप्त कर सकते हैं तो उपयोगकर्ता लॉग इन करने के लिए अपना पासवर्ड दर्ज करता है। बस सुनिश्चित करें कि आपके पास अच्छी सत्र समाप्ति और कचरा संग्रहण नीतियां हैं।
यदि यह स्थिति आपके लिए लागू नहीं होती है, तो कृपया अपनी स्थिति का अधिक विस्तार से वर्णन करें ताकि हम एक और उचित उत्तर प्रदान कर सकें।
MySQL, आपके संवेदनशील डेटा को सुरक्षित करने के लिए आप छह आसान कदम उठा सकते हैं।
चरण 1: अनुदान तालिकाओं में वाइल्डकार्ड निकालें
चरण 2: सुरक्षित पासवर्ड
के उपयोग की आवश्यकतानोट: पुराने के उपयोग को रोकने के लिए MySQL "--secure लेखन" विकल्प का उपयोग, कम सुरक्षित MySQL पासवर्ड प्रारूप।
चरण 3: विन्यास फाइल की अनुमतियों की जाँच करें
चरण 4: एन्क्रिप्ट क्लाइंट-सर्वर प्रसारण
चरण 5: अक्षम दूरदराज के उपयोग
चरण 6: सक्रिय MySQL का उपयोग लॉग
की निगरानीसुरक्षा उपकरण
बिंगो - यदि संभव हो तो क्रेडिट कार्ड डेटा स्टोर न करें। प्रक्रिया और त्यागें, और आवर्ती लेनदेन के साथ पेपैल सौदे जैसी सेवा दें। – ceejayoz
उन मामलों के लिए जब चार्जबैक होता है (यानी सीसी मालिक का दावा है कि लेनदेन गलत था) आप सीसी संख्या के अंतिम चार अंक रखना चाहेंगे। – BlaM
शायद सांख्यिकीय कारणों के लिए पहले 6 अंक भी। पहला 6 जारी करने वाले बैंक की पहचान करता है, ताकि आप देख सकें कि एक बैंक से बहुत सारे धोखेबाज लेनदेन हैं, इसलिए आप खराब मामलों में कई क्रेडिट कार्ड को अवरुद्ध करना शुरू कर सकते हैं। – BlaM