DB पासवर्ड सुरक्षित करना

Question

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

Comments

स्पष्ट करने के लिए - आप वेबसाइट से डेटाबेस में प्रवेश करने के लिए क्रेडेंशियल्स को संग्रहीत करने के बारे में पूछ रहे हैं, न कि कैसे डेटाबेस के भीतर वेबसाइट के उपयोगकर्ताओं के लिए पासवर्ड को ठीक से स्टोर करने के लिए, सही?

— जो

सही बात; मुझे यही मिल रहा है।

— काजी

Answer 1

पासवर्ड के भंडारण के बारे में सीधा जवाब नहीं है, लेकिन मैं आमतौर पर वेबएप का निर्माण करते समय कम से कम दो डेटाबेस कनेक्शन का उपयोग करता हूं - किसी ने उपयोगकर्ता से संबंधित गतिविधियों के लिए 99% का उपयोग किया, प्रतिबंधित विशेषाधिकारों के साथ, और दूसरे का उपयोग 'व्यवस्थापक' कार्यक्षमता के लिए किया गया (उपयोगकर्ताओं को हटाएं, आदि)।

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

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

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

Comments

हम भी कुछ ऐसा ही करते हैं। हालाँकि, हम आम तौर पर प्रत्येक उपयोगकर्ता / डेटाबेस के अनुप्रयोग के लिए एक नया खाता बनाते हैं बजाय इसे कार्यक्षमता के। यह हमारे लिए दो समस्याओं को हल करता है - 1) हम डेटाबेस जैसे OEM (यानी, हम दानेदारता के साथ डेटाबेस को कौन हथौड़ा कर रहे हैं) में उपयोग के अंतर को अलग कर सकते हैं) और 2) हम व्यक्तिगत रूप से दर्जी कर सकते हैं जो प्रत्येक उपयोगकर्ता देखता है और उसके भीतर पहुंचता है डेटाबेस।

— स्कॉटकर

Answer 2

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

Answer 3

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

जहां डेटाबेस और वेब सर्वर दो अलग-अलग मशीनों पर हैं, मैं SSL पर एमडी 5 पासवर्ड का उपयोग करता हूं: यदि मेरे शत्रु सर्वर पर किसी शत्रुतापूर्ण पहुंच है, तो यह केवल कुछ समय पहले की बात है जब वह यह पता लगाता है कि यह डेटाबेस के साथ कैसे संवाद करता है।

Answer 4

यदि आप .NET फ्रेमवर्क का उपयोग कर रहे हैं, तो आप एन्क्रिप्टेड कनेक्शन स्ट्रिंग्स का उपयोग करके देख सकते हैं। मैं नहीं जानता कि क्या किसी अन्य भाषाओं / रूपरेखाओं में ऐसा संभव है, लेकिन यह सुनिश्चित करने के लिए एक अन्य सुरक्षा उपाय होगा कि आपके कनेक्शनों से समझौता नहीं किया जाए।

एन्क्रिप्टेड कनेक्शन स्ट्रिंग्स का उपयोग करने के बाहर, LDAP / Kerberos / Active Directory का उपयोग करना आपके लिए सबसे सुरक्षित विकल्प होने जा रहा है।

Answer 5

यदि आपके पासवर्ड सादे-पाठ में संग्रहीत हैं, तो हैश (MD5, SHA), ल्यूक का उपयोग करें!

Comments

ओपी उपयोगकर्ता पासवर्ड को संग्रहीत करने के बारे में नहीं पूछ रहा है। लेकिन हाँ, निश्चित रूप से अपने उपयोगकर्ता पासवर्ड हैश, लेकिन यह करने के लिए उपयोगकर्ता MD5 या SHA परिवार कभी नहीं! Bcrypt या PBKDF2 का उपयोग करें । अन्यथा आप जल्द ही खुद को इन कंपनियों की तरह खबरों में पाएंगे जिन्होंने MD5 और SHA1 का इस्तेमाल किया और इस तरह अपने उपयोगकर्ताओं को सरल पाशविक बल के हमलों से अवगत कराया।

— निक चामास

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

— यासिर अरसानुकेव

Answer 6

अपनी प्रोग्रामिंग भाषा के आधार पर आप लॉगिन क्रेडेंशियल को एन्क्रिप्ट कर सकते हैं, लेकिन यदि आप एक व्याख्या की गई भाषा चला रहे हैं, तो यह सुनिश्चित करने का कोई तरीका नहीं है कि कोई व्यक्ति क्रेडेंशियल्स का पता नहीं लगा सकता है यदि वे सिस्टम तक पहुंच प्राप्त करते हैं।

यदि आप C ++ या इस तरह चल रहे हैं, तो मैं आपको एक नमकीन एन्क्रिप्ट / डिक्रिप्ट फ़ंक्शन बनाने / खोजने और उसके माध्यम से क्रेडेंशियल्स चलाने और सिस्टम पर फ़ाइल के रूप में परिणामी हैश स्टोर करने की सलाह दूंगा।

यदि आप PHP या इस तरह से चल रहे हैं, तो मैं आपको सलाह दूंगा mcrypt_encrypt()कि आप क्रेडेंशियल्स के लिए एक रैपर लिखें और किसी भी हैकर को धीमा करने के लिए कुछ कोड अवरोधों को चलाएं यदि वे सिस्टम तक पहुंच प्राप्त करते हैं।

Comments

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

— पीटर आईसेंट्राट