कॉन्फ़िगरेशन फ़ाइल में सादे पाठ में mysql पासवर्ड संग्रहीत करने से बेहतर दृष्टिकोण?

Question

यह हमेशा मुझे परेशान करता है कि कई PHP प्रोग्रामों को उपयोगकर्ता को रूट की स्थिति में एक कॉन्फ़िगरेशन फ़ाइल में सादे पाठ (स्ट्रिंग या स्थिर में) में MySQL पासवर्ड संग्रहीत करने की आवश्यकता होती है।

क्या इन सभी वर्षों के बाद इसके लिए कोई बेहतर दृष्टिकोण है?

अब तक मैं दो न्यूनतम सुरक्षा को बूस्ट के साथ आए हैं: (मामले में

1. फ़ाइल वेब .htaccess में नियमों का उपयोग कर के माध्यम से अपठनीय हो जाता php में विफल रहता है या वहाँ एक सुरक्षा भेद्यता php स्रोत को पढ़ने के लिए है)

2. डाटाबेस के बाद स्मृति में पासवर्ड को नष्ट कनेक्ट किया जाता है (सेट नहीं) (स्ट्रिंग एक सुरक्षा भंग, इंजेक्शन, आदि)

से उदासीनता को रोकने के लिए

लेकिन निश्चित रूप से उनमें से कोई भी मूल समस्या को हल नहीं करता है।

किसी अन्य विचार के लिए धन्यवाद!

Answer 1

चूंकि आपके कोड को पासवर्ड की आवश्यकता होगी, इसलिए कोई परिपूर्ण सुरक्षा नहीं है। लेकिन आप इसे ठीक करने में मुश्किल बना सकते हैं।

मैं, मेरी वेब config में कुछ हैश डाल एक वातावरण चर के रूप में कहते हैं कि MYSQL_PASS_HASH

तब मैं md5(getenv('MYSQL_PASS_HASH').'gibberish$qwefsdf') की तरह कुछ जो तब पासवर्ड है। बेशक आपको unsetenv होना चाहिए यदि आप पागल हो।

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

यह वेबूट के बाहर एक फ़ाइल में होता है (.htaccess में अपना पूरा विश्वास न रखें)।

Answer 2

अपनी कॉन्फ़िगरेशन फ़ाइलों को अपने दस्तावेज़ रूट के बाहर रखना कॉन्फ़िगरेशन फ़ाइलों की सुरक्षा में सुधार का एक लोकप्रिय तरीका है।

Answer 3

यह वेबूट में होना आवश्यक नहीं है। आप फ़ाइल को वेबूट के बाहर ले जा सकते हैं और इसे इस तरह से कॉल कर सकते हैं। इसका मतलब यह होगा कि फ़ाइल को सीधे वेब से नहीं कहा जा सकता है।

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

Answer 4

व्यक्तिगत रूप से, मैं अपने वेब फ़ोल्डर की रूट के बाहर config.ini फ़ाइल में डेटाबेस कनेक्शन विवरण जैसे संवेदनशील जानकारी संग्रहीत करता हूं। तब मेरे index.php में मैं कर सकते हैं:

$config = parse_ini_file('../config.ini'); 

इसका मतलब यह है चर दिखाई नहीं देते हैं, तो आपके सर्वर गलती से सादे पाठ के रूप PHP स्क्रिप्ट (जो पहले हुआ है, कुख्यात फेसबुक पर) outputting शुरू होता है; और केवल PHP स्क्रिप्ट्स के चरों तक पहुंच है।

यह भी .htaccess जिसमें कोई आकस्मिक है वहाँ अगर आपके .htaccess फ़ाइल ले जाया गया या नष्ट हो जाता है पर निर्भर नहीं है।

कैविट, 14 फरवरी 2017 जोड़ा गया: अब मैं पर्यावरण चर के रूप में कॉन्फ़िगरेशन पैरामीटर स्टोर करूंगा। मैंने कुछ समय के लिए .ini फ़ाइल दृष्टिकोण का उपयोग नहीं किया है।

Answer 5

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

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

Answer 6

निश्चित रूप से आपको दस्तावेज़ रूट के भीतर एक सादे पाठ फ़ाइल में कभी भी पासवर्ड स्टोर नहीं करना चाहिए। इसे सुरक्षित करने के लिए आप और कदम उठाएंगे जो आपके वेबसर्वर को कॉन्फ़िगर करने के लिए पहुंच के स्तर पर निर्भर करेगा।

आप php.ini में पासवर्ड परिभाषित कर सकते हैं (या अपाचे कॉन्फ़िगरेशन या .htaccess में आईएनआई सेटिंग के माध्यम से)। या जब आप अपना वेबसर्वर शुरू करते हैं तो इसे पर्यावरण में सेट करें।

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

यदि यह एक सस्ता होस्टिंग पैकेज है और आपके पास दस्तावेज़ रूट के बाहर कोई सुलभ संग्रहण नहीं है तो पासवर्ड में पासवर्ड संग्रहीत करना शामिल है, इसमें फ़ाइल को शामिल किया जाना चाहिए (फ़ाइल को डाउनलोड किए गए php intead द्वारा पार्स किया जाएगा)। शुरुआत में बस '.ht' वाली फ़ाइल का नामकरण दूरस्थ पहुंच को रोक सकता है।

नोट करें कि आपका दूसरा विकल्प कुछ हद तक अनावश्यक है - अगर कोई आपके कोड को इतना नुकसान पहुंचा सकता है तो उन्हें चल रहे कोड से पासवर्ड निकालने की आवश्यकता नहीं है।

वास्तव में समस्या का कोई समाधान नहीं है।

सी

Answer 7

इस संवेदनशील डेटा ठीक से भंडारण के अलावा, आप भी create a separate MySQL user कि केवल डेटाबेस/टेबल/विचारों की इस तक पहुंच की जरूरत के लिए आवश्यक है चाहिए privileges and restrict the access। और चूंकि डेटाबेस सर्वर अक्सर वेब सर्वर के समान मशीन पर चलाया जाता है, इसलिए स्थानीय एक्सेस तक पहुंच प्रतिबंधित भी होती है। इसलिए रूट विशेषाधिकारों के साथ उपयोगकर्ता का उपयोग न करें अगर इसे केवल एक डेटाबेस/तालिका से डेटा पढ़ने की आवश्यकता है।