स्टोर करने के लिए कहां है। मैं नेट फ्रेमवर्क में एईएस एन्क्रिप्शन कक्षाओं का उपयोग कर डेटा (स्वास्थ्य देखभाल उद्योग) एन्क्रिप्ट कर रहा हूं। कुंजी को सुरक्षित रूप से संग्रहीत करने के लिए कुछ अनुशंसित स्थान क्या हैं? मेरे पास विकास के लिए web.config में है, लेकिन कम से कम कहने के लिए उत्पादन योग्य नहीं लगता है।एन्क्रिप्शन कुंजी
यदि एप्लिकेशन को आपकी चाबियों का उपयोग करके प्रमाणीकरण की आवश्यकता है तो
यूनिक्स मशीनों पर सामान्य दृष्टिकोण हैश फॉर्म में पासवर्ड स्टोर करना है।
आप शा -512 + नमक का उपयोग कर सकते हैं।
तब उपयोगकर्ता हैश की गणना कर सकता है जब उपयोगकर्ता पासवर्ड इनपुट करता है और आपके खिलाफ जांच करता है।
पासवर्ड/कुंजी स्वयं को धोए जाने पर कहीं भी संग्रहीत किया जा सकता है। यदि इसे तकनीकी उपयोगकर्ता निर्देशिका में संग्रहीत नहीं किया गया है, जहां किसी के पास पहुंच नहीं है। उन जो उपयोग के मामले जो मैं प्रस्तुत किया है
जॉनी को समझने में बहुत ज्यादा मेहनत नहीं करना चाहते हैं के लिए
संपादित कुछ एईएस एन्क्रिप्टेड डेटा है।
वह अपनी चाबियाँ सिर में रखता है।
वह इस पीसी को कहीं भी अपने पीसी पर एक्सेस को स्वचालित करने के लिए स्टोर करना चाहता है।
वह इसे web.config में ASCII के रूप में स्टोर कर सकता है।
लेकिन वह हैश है कि अब एएससीआईआई नहीं है लेकिन हैश।
प्रमाणीकरण आवेदन के दौरान हैश चेक की गणना उचित कुंजी है, फिर इस कुंजी का उपयोग करता है ....
उचित एल्गोरिदम के साथ टकराव का शायद कम।
ps। बस विषय पर मेरे दृष्टिकोण को पोस्ट करना।
आप "हैश" शब्द के लिए इतने संवेदनशील क्यों हैं ???
संपादित 2
मुझे पता है कि हैश है,
मुझे पता है कि इतना 2 तरह एन्क्रिप्शन ....
आप एन्क्रिप्ट कर सकते हैं अपने web.config मूल्यों में तरीकों में बनाया का उपयोग कर कहा जाता है ढांचा:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
यह शायद अपने प्रमुख स्टोर करने के लिए एक उचित जगह है - यदि किसी इन विवरणों को प्राप्त करने के लिए अपने सर्वर तक पहुँचने में कामयाब रहा है, तो आप शायद द्वि है गजर चिंताएं।
सच है। क्या डीपीएपीआई अधिक "सुरक्षित" है? – Saraz
@ साराज़ - क्षमा करें, उसको जवाब नहीं पता ... – Paddy
@ साराज़: क्या से अधिक सुरक्षित? यह समझ में अधिक सुरक्षित है "उस विशिष्ट मशीन * पर व्यवस्थापक-स्तर पहुंच * के बिना पुनर्प्राप्त करने के लिए अक्षम है * (क्योंकि एन्क्रिप्शन अलगो मशीन पर अद्वितीय डेटा पर निर्भर है)। दूसरे शब्दों में, अगर कोई आपका web.config प्राप्त करने में कामयाब रहा, तो वे अभी भी एक अलग मशीन पर डिक्रिप्ट नहीं कर सके। – Piskvor
आपको यह कुंजी कहीं और छिपाने की ज़रूरत है, और एक सुरक्षित स्थान डेटाबेस के अंदर होगा। वरीयता से एक अलग डेटाबेस जो आपके डेटा को शामिल करता है। चूंकि डेटा को खोलने के लिए उपयोगकर्ता नाम/पासवर्ड संयोजन की आवश्यकता होती है, इसलिए आप अपने आवेदन में दूसरी सुरक्षा परत जोड़ते हैं। आपके ऐप को कुंजी डेटाबेस में लॉग इन करने की आवश्यकता होगी, एप्लिकेशन वाई के लिए कुंजी एक्स पुनर्प्राप्त करें और फिर इसका उपयोग करने में सक्षम हो। हालांकि, आपको कहीं भी इस डेटाबेस के लिए कनेक्शन स्ट्रिंग को स्टोर करना होगा।
भले ही आप एक कुंजी डेटाबेस में केवल एक ही कुंजी स्टोर करेंगे, यह मुसीबत के लायक होगा। यह एक हैकर को डेटा तक पहुंचने से पहले कुंजी खोजने के लिए इस डेटाबेस को खोलने के लिए थोड़ा और परेशानी लेने के लिए मजबूर करता है। चूंकि कोई पूर्ण सुरक्षा नहीं है, इसलिए आपके विकल्प केवल एक हैकर को पहुंच प्राप्त करने में कितना समय लगेगा, इस अवधि में देरी से सीमित हैं।
वेब.कॉन्फिग फ़ाइल या उसके भीतर डेटा को एन्क्रिप्ट करने से हैकर में देरी करने में भी मदद मिलेगी, लेकिन अगर कुंजी कॉन्फ़िगरेशन फ़ाइल के अंदर है, तो उसे फिर से डिक्रिप्ट करना होगा।
यह कॉन्फ़िगरेशन फ़ाइल में कोई कुंजी संग्रहीत करने के लिए वास्तव में कोई अलग नहीं है - आपको कनेक्शन स्ट्रिंग को कहीं भी अपने कुंजी डेटाबेस में स्टोर करने की आवश्यकता है, और यदि आपके हैकर को आपकी कॉन्फ़िगरेशन फ़ाइल प्राप्त करने के लिए पर्याप्त पहुंच है, तो वह शायद प्राप्त करने में सक्षम होगा यह ... – Paddy
सच है। लेकिन यह एक दूसरी परत जोड़ता है। कुंजी प्राप्त करने के लिए आपको डेटाबेस तक पहुंचने की आवश्यकता है और सामान्य रूप से, डेटाबेस एक अलग सिस्टम पर संग्रहीत होते हैं। यदि डेटाबेस सर्वर केवल वेब सर्वर स्थान से कॉल स्वीकार करने के लिए सेट है, तो आप दूरस्थ हैकर के लिए कुंजी तक पहुंच प्राप्त करना अधिक कठिन बनाते हैं। और यदि डेटाबेस कुछ सैकड़ों (डमी!) कुंजी संग्रहीत करता है तो हैकर अभी भी नहीं जानता कि किस का उपयोग करना है। –
एक दृष्टिकोण है जो अच्छा सुरक्षा करता है, तो केवल लोग हैं, जो किसी भी उद्देश्य के लिए कुंजी का उपयोग करने की आवश्यकता होगी इसके साथ बिल्कुल भरोसा किया जा सकता प्रदान करेगा कुंजी एक अन्य प्रमुख के साथ एन्क्रिप्टेड स्टोर करने के लिए है, जो की एक प्रति प्रत्येक उपयोगकर्ता के लिए भंडारित किया जाता है , उस उपयोगकर्ता के पासवर्ड के हैश से एन्क्रिप्ट किया गया (पासवर्ड सत्यापन के लिए संग्रहीत एक से अलग नमकीन!)। ब्रह्मांड में कहीं भी, डेटा के हर बिट तक पहुंचने वाले एक बुरे व्यक्ति, डेटाबेस की कुंजी से जुड़े, कम से कम एक पासवर्ड के विपरीत डेटाबेस के बिना डेटाबेस तक पहुंचने में असमर्थ होंगे।
ध्यान दें कि यदि सभी वैध खातों के लिए पासवर्ड कभी खो गए थे या भूल, डेटा असाध्य होगा। यह वास्तविक सुरक्षा की प्रकृति का हिस्सा है। यदि कोई डेटा खोने की संभावना से बचना चाहता है, तो किसी को यह सुनिश्चित करना होगा कि आवश्यक कुंजी और/या पासवर्ड की बैकअप प्रतियां सुरक्षित रूप से संग्रहीत हों।
आप के बजाय प्रमाणपत्र-आधारित एन्क्रिप्शन का उपयोग कर सकते हैं। Http://en.wikipedia.org/wiki/Certificate-based_encryption और http://msdn.microsoft.com/en-us/library/ms867080.aspx और http://msdn.microsoft.com/en-us देखें /library/ms229744.aspx –