मैं MySQL उपयोगकर्ता नाम और पासवर्ड को डीकंपलिंग से कैसे बचा सकता हूं?

अपने कोड में कभी भी हार्ड-कोड पासवर्ड न डालें। इसे हाल ही में शीर्ष 25 सबसे खतरनाक प्रोग्रामिंग गलतियों में लाया गया था :

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

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

import java.util.prefs.Preferences;

public class DemoApplication {
  Preferences preferences = 
      Preferences.userNodeForPackage(DemoApplication.class);

  public void setCredentials(String username, String password) {
    preferences.put("db_username", username);
    preferences.put("db_password", password);
  }

  public String getUsername() {
    return preferences.get("db_username", null);
  }

  public String getPassword() {
    return preferences.get("db_password", null);
  }

  // your code here
}

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

महत्वपूर्ण नोट: वरीयता फ़ाइलें केवल सादा पाठ XML फ़ाइलें हैं। सुनिश्चित करें कि आप अनधिकृत उपयोगकर्ताओं को कच्ची फ़ाइलें (UNIX अनुमतियाँ, Windows अनुमतियाँ, वगैरह) देखने से रोकने के लिए उचित कदम उठाते हैं। कम से कम Linux में, यह कोई समस्या नहीं है, क्योंकि Preferences.userNodeForPackage को कॉल करना वर्तमान उपयोगकर्ता की होम निर्देशिका में XML फ़ाइल बनाएगा, जो कि अन्य उपयोगकर्ताओं द्वारा वैसे भी पढ़ने योग्य नहीं है। विंडोज़ में, स्थिति भिन्न हो सकती है।

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

पहला मामला:उपयोगकर्ता डेटाबेस लॉगिन क्रेडेंशियल जानने के लिए अधिकृत है

इस मामले में, मैंने ऊपर वर्णित समाधान काम करेगा। जावा Preference वर्ग उपयोगकर्ता नाम और पासवर्ड को सादे पाठ में संग्रहीत करेगा, लेकिन वरीयता फ़ाइल केवल अधिकृत उपयोगकर्ता द्वारा ही पढ़ने योग्य होगी। उपयोगकर्ता केवल वरीयता एक्सएमएल फ़ाइल खोल सकता है और लॉगिन प्रमाण-पत्र पढ़ सकता है, लेकिन यह सुरक्षा जोखिम नहीं है क्योंकि उपयोगकर्ता क्रेडेंशियल्स को शुरू करने के बारे में जानता था।

दूसरा मामला:उपयोगकर्ता से लॉगिन क्रेडेंशियल छिपाने की कोशिश कर रहा है

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

सही मामला:बहु-स्तरीय वास्तुकला का उपयोग करना

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

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

संचालन का मूल क्रम है:

1. ग्राहक उपयोगकर्ता के व्यक्तिगत उपयोगकर्ता नाम/पासवर्ड का उपयोग करके व्यावसायिक तर्क स्तर के साथ प्रमाणित करता है। उपयोगकर्ता नाम और पासवर्ड उपयोगकर्ता के लिए जाना जाता है और किसी भी तरह से डेटाबेस लॉगिन क्रेडेंशियल से संबंधित नहीं हैं।
2. यदि प्रमाणीकरण सफल होता है, तो क्लाइंट डेटाबेस से कुछ जानकारी मांगने के लिए व्यावसायिक तर्क स्तर से अनुरोध करता है। उदाहरण के लिए, उत्पादों की एक सूची। ध्यान दें कि क्लाइंट का अनुरोध SQL क्वेरी नहीं है; यह एक दूरस्थ प्रक्रिया कॉल है जैसे getInventoryList ।
3. व्यावसायिक तर्क स्तर डेटाबेस से जुड़ता है और अनुरोधित जानकारी को पुनः प्राप्त करता है। व्यावसायिक तर्क स्तर उपयोगकर्ता के अनुरोध के आधार पर एक सुरक्षित SQL क्वेरी बनाने का प्रभारी है। SQL इंजेक्शन हमलों को रोकने के लिए SQL क्वेरी के किसी भी पैरामीटर को साफ किया जाना चाहिए।
4. बिजनेस लॉजिक टियर इन्वेंट्री सूची को क्लाइंट एप्लिकेशन को वापस भेजता है।
5. क्लाइंट उपयोगकर्ता को सूची सूची प्रदर्शित करता है।

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