नेट एन्क्रिप्शन

Question

जो मैं जानना चाहता हूं वह कॉन्फ़िगरेशन फ़ाइल में कनेक्शन स्ट्रिंग को एन्क्रिप्ट करने का निश्चित दृष्टिकोण है। यहाँ मेरी प्रश्न हैं:

1. मशीन स्तर एन्क्रिप्शन का उपयोग करना, किसी ने मेरे सर्वर कनेक्शन तार की सामग्री पढ़ने की एक छोटी सी नेट प्रोग्राम लिखने तक पहुँचने नहीं कर सकते?

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

3. क्या मेरे पास सार्वजनिक और निजी कुंजी हो सकती है, मेरे ऐप पर हस्ताक्षर करें, कॉन्फ़िगरेशन फ़ाइल को कुंजी के साथ एन्क्रिप्ट करें, और जब उपयोगकर्ता इसे निष्पादित करता है, तो डिक्रिप्शन केवल हस्ताक्षरित एप्लिकेशन से ही संभव होगा?

4. चूंकि मैं क्लिकऑन का उपयोग कर रहा हूं, इसलिए मुझे कोड में एन्क्रिप्टेड संवेदनशील जानकारी हो सकती है या एम्बेडेड किया जा सकता है, क्योंकि क्लिकऑन एक बदलाव का पता नहीं लगाएगा जब तक संस्करण # परिवर्तन नहीं होता है। इसलिए, अगर मैं अपनी कनेक्शन स्ट्रिंग को बदलता हूं तो मुझे पुन: संकलित करने की आवश्यकता है, तो app.config का बिंदु म्यूट हो गया है। सर्वर, क्लाइंट और बीच में कनेक्शन स्ट्रिंग की सुरक्षा प्राप्त करने के लिए, कॉन्फ़िगरेशन फ़ाइल का उपयोग करके, मैं किन अन्य दृष्टिकोण ले सकता हूं?

Answer 1

1. हां। मशीन कुंजी के साथ एन्क्रिप्टेड रहस्य मशीन कुंजी तक पहुंच के साथ किसी भी प्रक्रिया द्वारा डिक्रिप्ट किया जा सकता है।उपयोगकर्ता कुंजी के साथ एन्क्रिप्टेड रहस्य उसी उपयोगकर्ता द्वारा शुरू की गई किसी भी प्रक्रिया द्वारा डिक्रिप्ट किया जा सकता है।
2. यह संभव नहीं है। सभी विपरीत दावे सांप के तेल हैं। आपको एप्लिकेशन को कुछ डिक्रिप्ट करने के लिए एक रहस्य की आवश्यकता है। किसी एप्लिकेशन के अंदर एक रहस्य छिपाने के लिए कोई ज्ञात योजना नहीं है। विभिन्न obfuscation योजनाएं हैं, लेकिन बुलेटप्रूफ कुछ नहीं। बार को बढ़ाने के लिए आप सबसे अच्छा कर सकते हैं।
3. नहीं। या तो एप्लिकेशन में कुछ डिक्रिप्ट करने के लिए गुप्त कुंजी है, इस मामले में आप 2 बिंदु पर वापस जाते हैं, या आपके एप्लिकेशन में सार्वजनिक कुंजी है, इस स्थिति में कोई भी एक ही रहस्य को डिक्रिप्ट कर सकता है, इसलिए आप मूल रूप से सत्यापन करते हैं कॉन्फ़िगरेशन (के साथ छेड़छाड़ नहीं किया गया था), लेकिन विन्यास गुप्त नहीं है।
4. आप एक एप्लिकेशन में एम्बेडेड रहस्यों को सुरक्षित रूप से तैनात नहीं कर सकते हैं। क्या सिर्फ कीमत है कि कीमत कितनी अधिक है, अगर आपकी संरक्षित संपत्ति (गुप्त) इसके लायक है, तो एक हैकर इसे प्राप्त करेगा।

एन्क्रिप्शन इंफ्रास्ट्रक्चर को अन्य उपयोगकर्ताओं से वर्तमान उपयोगकर्ता के रहस्यों की सुरक्षा के लिए डिज़ाइन किया गया है। यह उपयोगकर्ता का उपयोग कर किसी एप्लिकेशन के रहस्यों की सुरक्षा के लिए डिज़ाइन नहीं किया गया है। आप जो पूछते हैं वह एन्क्रिप्शन नहीं है, डीआरएम है, और आपको उत्तर के लिए डीआरएम बुनियादी ढांचे को देखने की जरूरत है। मुझे DRM API के आस-पास एक प्रबंधित लाइब्रेरी से अवगत नहीं है।

Answer 2

अच्छा प्रश्न वास्तव में,

आप नहीं हो सकता यकीन है कि कोई भी अपने कनेक्शन स्ट्रिंग (या पासवर्ड) डिक्रिप्ट जाएगा। बेशक आप इसे एन्क्रिप्ट कर सकते हैं, लेकिन लोग आपके एप्लिकेशन को डीकंपाइल कर पाएंगे और देखेंगे कि आप किस एन्क्रिप्शन एल्गोरिदम का उपयोग करते हैं और आप अपनी कनेक्शन स्ट्रिंग/पासवर्ड को डिक्रिप्ट करने के लिए किस कुंजी का उपयोग करते हैं। शायद यह चरम परिदृश्य की तरह है लेकिन यह संभव है (मैं छात्र वर्षों में एक बुरा क्रैकर था :))। तो यदि आप इस तरह के परिदृश्य से डरते हैं तो आपको अपने आवेदन की रक्षा करनी होगी, इसे अलग करना मुश्किल हो जाएगा। यह एक और चर्चा के लिए एक विषय है, लेकिन उदाहरण के लिए आप Dotfuscator या अन्य अच्छे obfuscator का उपयोग कर सकते हैं - यह आपके आवेदन के अंदर क्या हो रहा है यह समझने के लिए एक क्रैकर के लिए कठिन बना देगा।
तो, एक संभावित समाधान "कनेक्शन स्ट्रिंग एन्क्रिप्ट करें + obfuscator का उपयोग करें" हो सकता है, लेकिन जैसा कि मैंने कहा, यह आपको 100% सुरक्षा नहीं देगा।

Answer 3

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

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

Answer 4

गुस्तावो आप इसे लागू करने में सक्षम हो सकते हैं, (यह मेरे आवेदन के लिए मेरी योजना है जो लॉगिन आधारित है)।

उपयोगकर्ता इनपुट प्रमाण पत्र .NET ऐप में। प्रमाण पत्र एक .php सर्वर-साइड एप्लिकेशन पर पारित हो जाते हैं जो उन्हें डेटाबेस में लॉग इन करने के लिए उपयोग करता है और एक कुंजी पुनर्प्राप्त करता है और उसे .Net ऐप पर वापस भेजता है। तब कुंजी को पूर्ण डेटाबेस पहुंच की अनुमति देने के लिए .Net ऐप में हार्डकोड किए गए एन्क्रिप्टेड कनेक्शन स्ट्रिंग पर उपयोग किया जाता है।