MySQL

Question

में एन्क्रिप्शन कुंजी का उपयोग/स्टोर करने का सबसे अच्छा तरीका क्या है, मैं कुछ तालिकाओं में कुछ कॉलम एन्क्रिप्ट/डिक्रिप्ट करने के लिए MySQL और इसकी अंतर्निहित एन्क्रिप्शन कार्यक्षमता का उपयोग करने की योजना बना रहा हूं। मेरी चिंता यह है कि मुझे कहीं और कुंजी स्टोर करने की ज़रूरत है। मैं निश्चित रूप से एक फ़ाइल में कुंजी संग्रहीत कर सकता हूं और उस फ़ाइल की अनुमतियों और उस एप्लिकेशन की अनुमतियों को नियंत्रित कर सकता हूं जो इसे एक्सेस करता है, लेकिन क्या वह पर्याप्त है? मैं कुंजी या कुछ पाने के लिए एक वेब सेवा भी बना सकता हूं।

मैं एक छोटी सी दुकान में हूं जहां मैं एकमात्र ऐसा (संभवतः एक अन्य व्यक्ति) होगा जिस पर एप्लिकेशन की मशीन पर पहुंच होगी। संपादित करें: मुझे यह जोड़ना चाहिए कि इस एप्लिकेशन का एक वेब सामना करने वाला हिस्सा है जिसे डेटा को डिक्रिप्ट करने की आवश्यकता होगी जब तक कि मैंने कोई स्तरीय जोड़ा न हो।

मैंने विज्ञापन मतली देखी है, लेकिन किसी को भी बुलेटप्रूफ उत्तर नहीं लगता है।

क्या यह उन समस्याओं में से एक है जहां आपको पर्याप्त अच्छी तरह से निपटना है? यह देखते हुए कि मैं MySQL और PHP (संभवतः पायथन) का उपयोग कर रहा हूं, क्या इसका दृष्टिकोण बेहतर तरीका है?

Answer 1

मुझे यकीन नहीं है कि अगर एन्क्रिप्शन में MySQL बिल्ड का उपयोग करना आपकी समस्या का सबसे अच्छा समाधान होगा।

PHP का M_CRYPT पैकेज काफी अच्छा माना जाता है और यह आपको एल्गोरिदम चुनने की लचीलापन देता है जो आपकी आवश्यकताओं के लिए सबसे उपयुक्त है।

किसी अन्य सर्वर पर अपनी कुंजी संग्रहीत करने का एक बड़ा फायदा है: कुंजी एन्क्रिप्टेड डेटा ^*) जैसी मशीन पर नहीं है।इसलिए जब तक हमलावर के पास समझौता मशीन पर पर्याप्त नियंत्रण नहीं होता है, तब तक वे कुंजी तक नहीं पहुंच सकते हैं।
यदि हमलावर मशीन पर पूर्ण नियंत्रण प्राप्त करता है तो डेटा संग्रहीत होता है, तो संभवतः वे कुंजी के लिए वेब-सेवा से पूछने में सक्षम होंगे।

हालांकि, एक मशीन से दूसरे में कुंजी को प्रेषित करने से एक नया नया क्षेत्र खुलता है जिसे सुरक्षित करने की आवश्यकता होती है। शायद अधिक कुंजी और अधिक एन्क्रिप्शन परतें शामिल हैं, जिससे गलतियों के मौके को बढ़ाया जा सकता है।

^*) दूसरा विकल्प वेबसर्वर पर पासवर्ड दर्ज करना है और इसे केवल स्मृति में रखना है।

संभव समाधान
तो एक समाधान कार्यरत निम्नलिखित विधि का इस्तेमाल किया है कि वेब का उपयोग के साथ उपयोगकर्ताओं के लिए फ़ाइलों को एनक्रिप्ट करने के लिए (मैं अपने वातावरण के बारे में सुनिश्चित नहीं कर रहा हूँ, लेकिन यह उपयोगी हो सकता है) देखी गई:

• उपयोगकर्ता निर्माण पर, नए उपयोगकर्ता को एक लंबी यादृच्छिक कुंजी असाइन की जाती है।
• यह यादृच्छिक कुंजी उपयोगकर्ता रिकॉर्ड में एन्क्रिप्टेड कॉलम में संग्रहीत है।
  (के रूप में रिकॉर्ड के बाकी के प्रदर्शन को प्रभावित नहीं करने के लिए केवल इस स्तंभ एन्क्रिप्टेड है!)
• यादृच्छिक कुंजी स्तंभ के एन्क्रिप्शन, 1 मास्टर पासवर्ड के साथ किया जाता है एक फ़ाइल में या स्मृति में संग्रहीत।
  
  (एक और दृष्टिकोण उपयोगकर्ता को पासवर्ड डालने जाने और प्रयोग है कि एन्क्रिप्ट/random- डिक्रिप्ट करने के लिए किया जाएगा (बेहतर विकल्प अपने वेबसर्वर घूर पर पासवर्ड डालने के लिए और केवल स्मृति में संग्रहीत है।) कुंजी कॉलम, लेकिन मुझे यकीन नहीं है कि इससे सुरक्षा)
• प्रत्येक दस्तावेज़ जिसे एन्क्रिप्ट किया जाना आवश्यक है उस उपयोगकर्ता के लिए यादृच्छिक कुंजी के साथ एन्क्रिप्ट किया गया है और फिर डिस्क पर संग्रहीत किया गया है।
• दस्तावेज़ फ़ाइल-सिस्टम में न्यूनतम अनुमतियों के साथ संग्रहीत किए जाते हैं।

इस दृष्टिकोण का लाभ हैं:
1. यादृच्छिक कुंजी डेटाबेस में एन्क्रिप्टेड है। इसलिए आपके पास अभी भी एन्क्रिप्टेड कॉलम के संयोजन में डेटाबेस-सर्वर की अतिरिक्त सुरक्षा है। 2. दस्तावेजों को विभिन्न कुंजी के साथ संग्रहीत किया जाता है, अगर हमलावर को कुंजी पकड़ लेती है, तो दस्तावेज़ों का केवल एक हिस्सा समझौता किया जाता है।

हालांकि:
हमलावर मास्टर पासवर्ड की पकड़ हो जाता है और उपयोगकर्ता के टेबल तक पढ़ने की पहुंच गया है, तो पूरे सिस्टम, एक बार फिर, टूटी हुई है।

Answer 2

ऐसा लगता है कि आप 'AES_ENCRYPT' और 'AES_DECRYPT' के साथ उपयोग करने के लिए 'कॉलम-विशिष्ट' कुंजी के उपयोग पर विचार कर रहे हैं। जैसा कि टिप्पणीकार ने कहा, यह एक बुरा विचार है, क्योंकि किसी भी घुसपैठ के पास सभी डेटा तक पहुंच होगी।

यदि आप नमक के साथ/बिना 'उपयोगकर्ता द्वारा आपूर्ति' पासवर्ड का उपयोग करते हैं, तो आप अधिक सुरक्षित होते जा रहे हैं।

उस ने कहा, अगर एन्क्रिप्शन कुंजी केवल इसका उपयोग करके एप्लिकेशन द्वारा पठनीय है, तो आप शायद 'पर्याप्त पर्याप्त' हैं। यदि मशीन टूटी हुई है, तो वे आपके डेटा को एक ही कुंजी के साथ तेजी से प्राप्त करने जा रहे हैं।

Answer 3

मैं शायद इसे एक फ़ाइल में संग्रहीत करता हूं जो एक गैर-वेब-सुलभ निर्देशिका में है और जितना संभव हो सके फ़ाइल सिस्टम अनुमतियों के साथ बंद कर दिया गया है।

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

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

यदि आप और एक अन्य व्यक्ति केवल वे हैं जिनके पास मशीन तक भौतिक पहुंच है, तो यह शायद ठीक है। अगर कोई बॉक्स में तोड़ता है और चोरी करता है, तो, उन्हें आपके सारे डेटा को वैसे भी मिला है ताकि गेम खत्म हो जाए।