पासवर्ड को सुरक्षित रूप से

मुझे अपने एप्लिकेशन को "पासवर्ड सुरक्षित" करने की आवश्यकता है, लेकिन पासवर्ड को सुरक्षित रूप से कहां स्टोर करना है, इस बारे में सलाह चाहिए।पासवर्ड को सुरक्षित रूप से

मैं कैसे यह करने के लिए करना चाहते हैं:

पहली बार कार्यक्रम चलाया जाता है, मैं उपयोगकर्ता एक पासवर्ड बनाने के लिए संकेत देगा। पासवर्ड को नमकीन और SHA-256 में धोया जाएगा, फिर रजिस्ट्री या फ़ाइल में संग्रहीत किया जाएगा।

समस्या:

अगर मैं रजिस्ट्री या फ़ाइल (या दोनों) में टुकड़ों में बंटी पासवर्ड की दुकान तो यह बहुत आसान किसी को सिर्फ रजिस्ट्री में कुंजी या फ़ाइल को हटाने के लिए और के लिए प्रेरित किया के लिए होगा नया पासवर्ड बनाएं ...

मैं सुरक्षित रूप से हैश किए गए पासवर्ड को कैसे स्टोर कर सकता हूं ताकि इसे हटाया जा सके?

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

// मुझे उम्मीद है कि मैंने सही प्रश्न के साथ इस प्रश्न को सही तरीके से पोस्ट किया है - मैं यहां नया हूं इसलिए कृपया आसान हो जाएं! ;)

शुभकामनाएँ

क्रिस (Shamballa)

स्रोत

2010-10-14 Shambhala

आप किसके खिलाफ बचाव कर रहे हैं? – SLaks

आपका उपयोगकर्ता पहले स्थान पर पासवर्ड क्यों दे सकता है और फिर कभी नहीं? – codymanix

स्लाक्स ... मुझे यह सुनिश्चित करने की ज़रूरत है कि कोई व्यक्ति पासवर्ड बनाने वाले व्यक्ति को छोड़कर प्रोग्राम तक पहुंच सके। – Shambhala

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

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

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

स्रोत

2010-10-14 16:25:26

इंटरनेट पर एक बहुत ही सुरक्षित तरीका है, लेकिन फिर आपको यह सुनिश्चित करने में परेशानी है कि आपकी सेवा हमेशा लॉगिन करने की अनुमति देने के लिए है, जैसे कि गेमिंग सेवाओं में से कुछ। यह आपके सर्वर पर प्रबंधित होने के लिए आपकी लाइसेंसिंग संरचना (यदि आपके पास एक है) को भी अनुमति देगा, यदि प्रोग्राम केवल तभी काम करता है जब यह आपकी सेवा से कनेक्ट हो। ऐसा करने के लिए इसमें स्वयं की कमी है। – jimplode

हां। जैसे मैंने कहा, यह अपनी खुद की कीड़े ला सकता है। लेकिन कम से कम यह सैद्धांतिक रूप से संभव है। ओपी क्या चाहता है बस नहीं है। –

मुझे लगता है कि नैतिक मुद्दा दोनों तरीकों से कटौती करता है। जब तक उपयोगकर्ता पासवर्ड को बदल या हटा सकता है _by पहले मौजूदा पासवर्ड की आपूर्ति कर रहा हूं_ मुझे नहीं लगता कि आप उनसे कोई अधिकार ले रहे हैं। समस्या उपयोगकर्ता के लिए है जो एक बार पासवर्ड बनने के बाद अपने आवेदन को लॉक करने के लिए विशिष्ट रूप से इच्छाशक्ति करता है - यह कैसे पूरा किया जा सकता है? –

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

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

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

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

एक अन्य विकल्प एक समय-सीमित महत्वपूर्ण यह है कि आप उपयोगकर्ता को दे एन्कोड करने के लिए OnGuard (latest versions) की तरह कुछ का उपयोग करने के लिए होगा। फिर जब सक्रियण चलाया जाता है तो यह देखने के लिए जांचें कि आपके द्वारा प्रदान की गई कुंजी की समय सीमा समाप्त हो गई है या नहीं और यदि ऐसा है तो सक्रियण की अनुमति न दें। इस तरह आपकी सक्रियण कुंजी केवल सीमित समय के लिए जोखिम पर है।

इस पर बहुत अधिक समय खर्च करते हैं न करें। ऐप तैनात होने के बाद भी कुछ NOP निर्देशों के साथ सबसे अच्छा एल्गोरिदम भी लगाया जा सकता है।

स्रोत

2010-10-14 16:28:17 skamradt

यह एक अच्छा विकल्प है, प्रोग्राम को किसी प्रकार के कुंजी लॉक के साथ रिलीज़ करें। इसलिए एक जेनरेट की गई सीरियल कुंजी प्रोग्राम को अनलॉक कर देगी और इसे इस्तेमाल और चलाने की अनुमति देगी, फिर उपयोगकर्ताओं को अपना पासवर्ड प्रदान करने की अनुमति दें। लाइसेंस देने के लिए इंटरनेट कनेक्शन का उपयोग करने का आग्रह करने की कोशिश करने से यह एक बहुत ही स्वच्छ मॉडल है। यहां एक शेयरवेयर स्टार्टर किट का एक लिंक है, जो आपको कुछ विचार दे सकता है। http://blogs.msdn.com/b/danielfe/archive/2005/07/10/437293.aspx – jimplode

@jimplode - हाँ यह भी काम करता है, लेकिन काम के बाहरी होने तक कुंजी के उपयोग को सीमित नहीं करता है इसके खिलाफ। – skamradt

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

आप सुरक्षित रूप से Windows crypto API का उपयोग कर एक आवेदन के लिए एक पासवर्ड स्टोर कर सकते हैं। इसके का एक उदाहरण CodeGuru में फायदा नहीं है है, लेकिन यह सी ++, नहीं डेल्फी में लिखा है। कोड बहुत चुनौतीपूर्ण नहीं है, इसलिए अपेक्षाकृत आसानी से डेल्फी में परिवर्तित किया जाना चाहिए।

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

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

स्रोत

2010-10-14 16:35:43 Petesh

वहाँ कम से कम 2 तरीके मैं अपने प्रश्न की व्याख्या कर सकते हैं।

(1) आपने पासवर्ड को स्टोर करने के लिए ताकि वे एक दूरदराज के डेटाबेस के लिए लॉग इन करने के लिए बाद में इस्तेमाल किया जा सकता चाहते हैं।

Password encryption in Delphi पर This answer एन्क्रिप्शन हिस्सा बताते हैं।

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

"को नष्ट नहीं" भाग उपयोगकर्ताओं के लिए वास्तव में संवेदनशील है; मैं वह न करता।

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

यह और अधिक कठिन है, के रूप में मूल रूप से आप नहीं कर सकते।

पृष्ठभूमि प्रक्रिया को चालू रखने का सबसे नज़दीकी तरीका फ़ाइल पर लॉक रखता है।
आप ताकि आप पासवर्ड सत्यापित फ़ाइल अनलॉक करने के लिए है कि इस प्रक्रिया के साथ संवाद।

--jeroen

स्रोत

2010-10-14 16:49:32

क्षमा करें - एसओ संख्या को गड़बड़ कर देता है; मैंने टाइप 1 और 2. –

... जब तक कि यह पता लगाने के लिए उपयोगकर्ता प्रोसेस मैनेजर का उपयोग नहीं करता है, यह प्रक्रिया को मारता है, और फ़ाइल को हटा देता है। ;) –

यही कारण है कि वायरस और ट्रोजन लेखकों ने अपनी सामग्री छिपाने में इतना प्रयास किया। और वे नहीं कर सकते। जब तक वे कॉपी की सुरक्षा के लिए सोनी की तरह रूट किट स्थापित नहीं करते हैं: http://en.wikipedia.org/wiki/Sony_BMG_CD_copy_protection_scandal –

आप केवल एक पासवर्ड, एन्क्रिप्ट की जरूरत है और .exe के अंत पर यह हमले हैं। मैंने इसे सफलतापूर्वक कई बार किया है।

स्रोत

2010-10-14 18:07:33 Dennis

यदि उपयोगकर्ता प्रशासक नहीं है या exe को ऊपर नहीं चलाता है तो वहां कोई लेखन अनुमति नहीं हो सकती है। – Remko

यह प्रोग्राम के अंदर पासवर्ड स्टोर करने के लिए दिलचस्प लगता है? क्या यह एंटी वायरस प्रोग्राम द्वारा खराब के रूप में फ़्लैग नहीं किया जाएगा? – Shambhala

ओह - दबाया गया और मैंने टाइपिंग समाप्त करने से पहले सबमिट किया! मैं जोड़ने जा रहा था >> आप यह कैसे किया? इसे रन टाइम के दौरान जोड़ा जाना होगा। – Shambhala

मैं विंडोज़ में प्रमाणीकरण कार्यों का उपयोग करने का सुझाव दूंगा, विशेष रूप से CredWrite और CredRead।आप डेल्फी के लिए हेडर की जरूरत है, वे Jedi Windows Api Library में उपलब्ध हैं: यह भी एन्क्रिप्शन विंडोज़ प्रदान करता है (CryptProtectData/CryptProtectMemory) का उपयोग करें और फिर साख

संपादित को बचाने के लिए संभव हो जाएगा।

स्रोत

2010-10-14 18:11:03 Remko

आपने वास्तव में यह निर्दिष्ट नहीं किया कि यह पासवर्ड किस सुरक्षा की रक्षा कर रहा है। मुझे लगता है कि यह आपके प्रोग्राम द्वारा बनाए गए डेटा की सुरक्षा के लिए उपयोग किया जाता है।

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

यह फ़ाइल हटाने से छेड़छाड़ को रोकता है। वे सभी डेटा भी हटा देंगे। यह सबसे निर्धारित अंत उपयोगकर्ता के अलावा सभी को विफल कर देगा।

स्रोत

2010-10-14 18:11:28

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

पासवर्ड वास्तविक प्रोग्राम तक पहुंच की रक्षा करना है। अर्थात। एक बार स्थापित होने के बाद वास्तव में प्रोग्राम तक पहुंचने में सक्षम होना। मैं जो प्रोग्राम विकसित कर रहा हूं वह एक ईमेल एन्क्रिप्शन प्रोग्राम है। यह 256 बिट सीबीएस मोड में एईएस रिजेंडेल का उपयोग करता है, इसलिए यह पासवर्ड एन्क्रिप्टिंग के समय से पहले चुना जाता है लेकिन कभी संग्रहित नहीं होता है। मैं "कुंजी" प्रारंभ करता हूं जो वे SHA-256 के साथ उपयोग करते हैं जो वास्तविक कुंजी बन जाता है। यह कभी संग्रहित नहीं होता है। समस्या अन्यथा कोई भी पूर्व निर्धारित कुंजी का उपयोग कर डेटा डिक्रिप्ट कर सकता है ... – Shambhala

मेरा मतलब सीबीसी मोड था ... – Shambhala

अपने विवरण से परखने के बाद, आप समझ नहीं है कि अगर सभी सुरक्षा आपके पास

if not SameString(Hash(UserPassword), StoredPassword) then exit;

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

//if not SameString(Hash(UserPassword), StoredPassword) then exit; 
//Check commented out ---malicious user

आप को एहसास है कि भले ही आप अपने एप्लिकेशन संकलन, यह अभी भी सभी स्रोत कोड शामिल है, बस में कोडांतरक। आप अभी भी स्रोत को संपादित कर सकते हैं, यह थोड़ा कठिन है क्योंकि यह अब अलग भाषा में है।

इसलिए, यदि आप अपने अनुप्रयोग में कुछ करने से उपयोगकर्ता को रोकने के लिए चाहते हैं, वहाँ केवल दो तरीके हैं: अपने अनुप्रयोग

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

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

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

स्रोत

2010-10-15 16:06:24 himself

पासवर्ड को सुरक्षित रूप से

उत्तर

संबंधित मुद्दे