सॉफ़्टवेयर सुरक्षा प्रयोजन के लिए सुरक्षा परीक्षण जानकारी को स्टोर करने के लिए कहां

Question

यह अन्य प्रश्नों के साथ डुप्लिकेट हो सकता है, लेकिन मैं कसम खाता हूं कि मैंने बहुत कुछ googled और StackOverflow.com पर बहुत कुछ खोजा है, और मुझे अपने प्रश्न का उत्तर नहीं मिल रहा है:

एक सी # नेट एप्लिकेशन में, सुरक्षा परीक्षण जानकारी, जैसे कि समाप्ति तिथि, प्रयुक्त टाइम्स की संख्या कहां स्टोर करें?

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

ठीक है, सबूत के लिए आदेश है कि मैं googled और StackOverflow.com पर एक बहुत खोज की है में, मैं सभी संभव रणनीतियों लिस्टिंग कर रहा हूँ मुझे मिल गया:

1. रजिस्ट्री प्रविष्टि

सबसे पहले, कुछ उपयोगकर्ताओं रजिस्ट्री तालिका को पढ़ने के लिए भी पहुंच नहीं हो सकती है।

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

ठीक है, आप कह सकते हैं कि हमें सुरक्षा परीक्षण जानकारी एन्क्रिप्ट करना चाहिए, हां हम ऐसा कर सकते हैं। लेकिन क्या होगा यदि उपयोगकर्ता बस स्थापित करने से पहले अपनी सिस्टम तिथि बदल जाए?

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

मुझे इस बात से कोई जानकारी नहीं है कि इससे कैसे निपटें। कृपया मदद करे।

• 2.a) सॉफ़्टवेयर स्थापना पथ
• 2.b) विन्यास फाइल के नीचे एक सरल एक्सएमएल फ़ाइल:

  एक सादे फ़ाइल

  सबसे पहले, वहाँ कुछ स्थानों सादे फ़ाइल डाल करने के लिए कर रहे हैं

फिर से, उपयोगकर्ता सॉफ़्टवेयर को अनइंस्टॉल कर सकता है और इन सादे फ़ाइल को हटा सकता है, और सॉफ़्टवेयर को पुनर्स्थापित कर सकता है।

- सॉफ्टवेयर अपने आप में सॉफ्टवेयर में ही

अगर हम सुरक्षा परीक्षण की जानकारी डाल (समाप्ति दिनांक, हम संख्या नहीं डाल सकते प्रयुक्त टाइम्स के), यह अभी भी मामलों मैं उपर्युक्त लिए अतिसंवेदनशील है। इसके अलावा, ऐसा करने के लिए भी अच्छा नहीं है।

- एक परीक्षण उत्पाद कुंजी

यह एक लाइसेंस प्रक्रिया की तरह काम करता है, कि हम एक आरएसए-हस्ताक्षरित स्ट्रिंग में ट्रायल की जानकारी डाल दिया, है। हालांकि, यह एक उपयोगकर्ता के लिए भी कई चरण होते हैं सॉफ्टवेयर का उपयोग कर के एक कोशिश है करने के लिए (वे धैर्य खो सकता है):

• 4. a) उपयोगकर्ता सॉफ़्टवेयर डाउनलोड कर;
• 4।बी) उपयोगकर्ता उपयोगकर्ता नाम (या ईमेल) या हार्डवेयर जानकारी प्रदान करके परीक्षण उत्पाद-कुंजी का अनुरोध करने के लिए एक ईमेल भेजता है;
• 4. सी) सर्वर अनुरोध प्राप्त करता है, आरएसए-इसे संकेत देता है और उपयोगकर्ता को वापस भेजता है;
• 4. डी) उपयोगकर्ता अब इस स्थिति के तहत उपयोग कर सकते हैं (समाप्ति दिनांक & प्रयुक्त टाइम्स की संख्या)।

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

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

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

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

Answer 1

या तो विकल्प 1 (सादा रजिस्ट्री कुंजी) या 2 (सादा फ़ाइल) ठीक है। यहां मेरा तर्क है:

• मानक-विशेषाधिकार प्राप्त उपयोगकर्ताओं को रजिस्ट्री के लिए अनुमतियां पढ़ने हैं। अगर वे आपकी कुंजी नहीं पढ़ सकते हैं, तो कुछ और गलत है। मानक-विशेषाधिकार प्राप्त उपयोगकर्ताओं के पास रजिस्ट्री के लिए लेखन अनुमति नहीं है, लेकिन इससे कोई फर्क नहीं पड़ता क्योंकि उन्हें पहले स्थान पर सॉफ़्टवेयर इंस्टॉल करने की अनुमति नहीं है। दूसरे शब्दों में, उपयोगकर्ता को इंस्टॉल समय पर अपनी रजिस्ट्री कुंजी बनाने की अनुमति होगी, या उन्हें किसी भी तरह से इंस्टॉल करने में सहायता की आवश्यकता होगी। इसलिए रजिस्ट्री कुंजी के लिए आपके द्वारा उठाए गए बुनियादी तकनीकी मुद्दे वास्तव में एक कारक नहीं हैं।
• बस उन उपयोगकर्ताओं के बारे में चिंता न करें जो अपनी सिस्टम घड़ी को वापस सेट करते हैं या अपनी कुंजी को तोड़ने के लिए मैन्युअल रूप से रजिस्ट्री हैक करते हैं। मुझे फिर से कहो करते हैं: बस जो अतीत अपने परीक्षण सीमाओं — हो और कोई गलती बनाने के लिए, सिस्टम घड़ी वापस स्थापित करने या संपादन रजिस्ट्री कर रहे हैं एक महत्वपूर्ण तरीके से अपने सिस्टम को बदलने के लिए एक सचेत निर्णय करने के उपयोगकर्ताओं के बारे में चिंता मत करो महत्वपूर्ण संशोधन कारण है कि आप इन उपयोगकर्ताओं के बारे में चिंता नहीं करनी चाहिए कि वे संभावित आय में वास्तव में $ 0 का प्रतिनिधित्व करते है। एक उपयोगकर्ता जो आपके सॉफ़्टवेयर को समुद्री डाकू के बारे में इस प्रकार की सचेत पसंद लेने के इच्छुक है, वह सिर्फ हारने वाला नहीं है और यदि यह काम नहीं करता है तो अपने उत्पाद के लिए भुगतान करने का फैसला नहीं कर रहा है। यदि वे आपके सॉफ़्टवेयर को मुफ्त में नहीं प्राप्त कर सकते हैं, तो वे या तो प्रतिस्पर्धी के साथ जाएंगे या बिना करेंगे। आप पैसे बनाने के लिए इस हैं - अपनी समय और संसाधन खर्च करने के लिए बिक्री आप जीत नहीं सकते हड़पने के लिए या कोशिश कर एक प्रतियोगी के लिए उपयोगकर्ताओं को भेजने नहीं करना चाहती।इसलिए, किसी भी विकल्प के लिए आपके द्वारा उठाए गए बुनियादी सुरक्षा मुद्दे एक कारक नहीं हैं।

Answer 2

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

Answer 3

क्या आपको परीक्षण करने वाले उपयोगकर्ताओं को इंटरनेट से कनेक्ट करने की आवश्यकता हो सकती है? यदि ऐसा है तो परीक्षण संस्करण स्टार्टअप के दौरान सर्वर से संपर्क करें और आप सभी प्रकार की चीजों की जांच कर सकते हैं। आपको उपयोगकर्ताओं के कंप्यूटर पर सामान संग्रहीत करने या डेटा या सिस्टम समय के साथ छेड़छाड़ करने की चिंता करने की आवश्यकता नहीं है।

Answer 4

मैं थोड़ा अलग व्यवहार करने का सुझाव दूंगा।

अपने सॉफ़्टवेयर का "लाइट" संस्करण दें। कोई परीक्षण नहीं, बस वास्तव में सीमित कार्यक्षमता।

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

तिथि का परीक्षण करें और तदनुसार कार्य करें। यदि यह अस्तित्व में नहीं है तो बस लाइट संस्करण के रूप में चलाएं।

परीक्षण कुंजी प्राप्त करने के लिए, आप उन्हें अपने ऐप में एक बॉक्स में एक ईमेल पता और कुछ अन्य जानकारी दर्ज कर सकते हैं। यह पूछना अनुचित नहीं है कि इस सीमित हिस्से के लिए मशीन इंटरनेट से कनेक्ट हो। यहां तक ​​कि एमएस ऑफिस के लिए आपको कुंजी को सत्यापित करने के लिए संक्षेप में इंटरनेट से कनेक्ट करने की आवश्यकता है। ऐप को मुख्य अनुरोध के साथ अपने सर्वर से संपर्क करें। उन्हें कुंजी वापस ईमेल करें।

बोनस अंक के लिए मशीन के कुछ मीट्रिक के लिए परीक्षण कुंजी को बांधें। यहां तक ​​कि अगर यह सिर्फ बॉक्स का नाम है। वे शायद ही कभी बदलते हैं और यह वैसे भी एक परीक्षण है।

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

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

अब, कुंजी प्रबंधन आप जिस बुराई से लड़ रहे हैं उसका केवल एक पहलू है।

अगला चरण यह है कि आपको अपने ऐप को इस तरह से खराब करने की आवश्यकता है कि वे इसे आसानी से अपनाने और अपनी कुंजी जांच को बाईपास नहीं कर सकते हैं। यह महत्वपूर्ण फाइलों के चारों ओर गुजरने से कहीं अधिक आम है।

आपके पास ऐप में कई विधियां भी हो सकती हैं जो विभिन्न तरीकों से कुंजी के लिए परीक्षण करती हैं .. लेकिन यह एक अलग सवाल है।

---

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

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