क्या पासवर्ड को ssl सर्टिफिकेट से हटाना अच्छा है?

Question

मैंने अब कई ब्लॉगों पर पढ़ा है कि अपाचे रिस्टार्ट के दौरान पासवर्ड प्रॉम्प्ट से बचने के लिए एसएसएल सर्टिफिकेट से पासवर्ड हटाना चाहिए।

क्या यह सच है और क्या इससे कोई सुरक्षा जोखिम पैदा होता है?

Comments

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

— Zoredache

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

— MadHatter

Answer 1

हाँ, यह वेब सर्वर शुरू करते समय टर्मिनल पर भेजे जाने वाले संकेतों को रोक देगा।

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

क्या यह आपके लिए एक महत्वपूर्ण सुरक्षा जोखिम रखता है, यह इस बात पर निर्भर करता है कि यदि आपके साथ ऐसा हुआ है और आपको इस तरह से हासिल करने से क्या लाभ होगा।

यदि आपके लिए यह अधिक महत्वपूर्ण है कि एसएसएल प्रणाली की सुरक्षा की तुलना में अप्राप्य होने पर भी सेवाओं को इनायत से पुनः आरंभ करना चाहिए तो यह एक सीधा उत्तर है।

व्यक्तिगत रूप से, मुझे लगता है कि एसएसएल प्रमाणपत्रों की डिक्रिप्टेड प्रतियां कुल मिलाकर मेरे सामान्य कार्यभार के लिए विपक्ष की तुलना में अधिक हैं, यहाँ क्यों है;

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

चीजें जो मुझे एन्क्रिप्ट कर सकती हैं:

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

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

Answer 2

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

व्यावहारिक दृष्टिकोण से, क्या आप वास्तव में चाहते हैं कि हर बार अपाचे को पासवर्ड में डालने के लिए फिर से शुरू करने की आवश्यकता हो?

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

Answer 3

लॉगिन के लिए उपयोग की जाने वाली Cient कुंजियाँ पासवर्ड से सुरक्षित होनी चाहिए।

यदि आप चाहते हैं कि एसएसएल आधारित सेवाएं मैनुअल हस्तक्षेप के बिना फिर से शुरू हों, तो आपके पास दो विकल्प हैं:

1. कुंजी पर एक पासवर्ड न रखें, और इसे सुरक्षित रखें ताकि केवल सेवाओं की आवश्यकता हो जो इसे एक्सेस कर सकें।
2. पासवर्ड को सादा पाठ या सर्वर पर एक सादा पाठ के बराबर रखें ताकि जिन सेवाओं की आवश्यकता हो वे पासवर्ड प्रदान कर सकें। (आप खराब सुरक्षित कॉन्फ़िगरेशन फ़ाइलों में पासवर्ड की कई प्रतियों के साथ समाप्त हो सकते हैं।)

कुंजी की बैकअप प्रतियां पासवर्ड संरक्षित और सुरक्षित होनी चाहिए जैसे कि वे पासवर्ड संरक्षित नहीं थे।