एसएमटीपी को प्रमाणीकरण की आवश्यकता नहीं है, यह इंगित करने वाली टिप्पणियां सही हैं। उस ने कहा, तीनों आपके द्वारा निर्दिष्ट विकल्पों में से असुरक्षित हैं, यह मानते हुए कि सर्वर कमोडिटी हार्डवेयर और सॉफ़्टवेयर का उपयोग करता है। मैं दिखाऊंगा कि प्रत्येक असुरक्षित क्यों है, हालांकि मैं आपके मूल आदेश का पालन नहीं करूंगा।
क्या होगा अगर कोई सर्वर चुरा ले? फिर, वे केवल फ़ाइल या डेटाबेस खोल सकते थे, पासवर्ड पढ़ सकते थे, और तुरंत कंपनी की सभी महत्वपूर्ण सूचनाओं तक पहुँच प्राप्त कर सकते थे। इसलिए जब तक आपके पास दिन-रात सर्वर के आसपास सशस्त्र गार्ड न हों, यह पहले से ही काफी असुरक्षित है।
लेकिन यह बदतर हो जाता है। कोई भी कंप्यूटर सिस्टम हमला करने के लिए पूरी तरह से असुरक्षित नहीं है, और पिछले कुछ वर्षों में कई अच्छी तरह से प्रचारित हमलों (उदाहरण के लिए सोनी के प्लेस्टेशन नेटवर्क) ने दिखाया है कि एक हमलावर भौतिक पहुंच के बिना डिस्क फ़ाइलों और डेटाबेस की सामग्री तक पहुंच सकता है। इसके अलावा, आपके प्रश्न से ऐसा लगता है कि विचाराधीन सर्वर बाहरी दुनिया से पैकेट (HTTP अनुरोध, आने वाले ईमेल, आदि) को स्वीकार करने के लिए है, जो आपके हमले की सतह को बढ़ा देता है।
यह आकर्षक है, लेकिन यह विकल्प 2 या विकल्प 3 से भी अधिक हानिकारक है। एक बात के लिए, एक निजी अंतिम स्ट्रिंग फ़ील्ड जावा कंपाइलर द्वारा उत्पन्न .class फ़ाइल में संग्रहीत है, इसलिए इस विकल्प के साथ आप पहले से ही अनएन्क्रिप्टेड पासवर्ड संग्रहीत कर रहे हैं। सर्वर की हार्ड ड्राइव पर। विकल्प 2 या 3 के अनुसार सर्वर से समझौता करने के बाद, एक हमलावर बस javap चला सकता है .क्लास फ़ाइल से प्लेनटेक्स्ट पासवर्ड प्राप्त करने के लिए।
हालाँकि, यह दृष्टिकोण आपके हमले की सतह को और भी व्यापक बनाता है। यदि पासवर्ड स्रोत कोड के हिस्से के रूप में संग्रहीत है, तो अचानक यह उन सभी डेवलपर्स के लिए उपलब्ध है जो कोड पर काम कर रहे हैं। कम से कम विशेषाधिकार के सिद्धांत के तहत, डेवलपर्स को अतिरिक्त पासवर्ड नहीं जानना चाहिए, और यहां एक बहुत अच्छा कारण है। अगर कोई डेवलपर्स' मशीन चोरी हो गई है या बाहर से छेड़छाड़ की गई है, तो हमलावर समझौता की गई मशीन की हार्ड ड्राइव को देख सकता है और प्लेनटेक्स्ट पासवर्ड प्राप्त कर सकता है। फिर स्रोत नियंत्रण है। स्रोत नियंत्रण के वास्तव में महत्वपूर्ण लाभों में से एक यह है कि यह आपको अपने कोड के किसी भी पूर्व संस्करण का निरीक्षण करने की अनुमति देता है। इसलिए यदि आप भविष्य में किसी सुरक्षित तरीके पर स्विच करते हैं, यदि पासवर्ड ने कभी स्रोत नियंत्रण में प्रवेश किया है तो स्रोत नियंत्रण सर्वर एक संभावित आक्रमण बिंदु है।
ये सभी कारक यह दिखाने के लिए जुड़ते हैं कि, भले ही HTTP/मेल सर्वर की सुरक्षा शीर्ष पर हो, विकल्प 1 हमले की सतह को इतना बढ़ा देता है कि HTTP/मेल सर्वर की सुरक्षा वास्तव में मदद नहीं करती है।
अतिरिक्त विवरण:शुरुआत में मैंने निर्दिष्ट किया "यह मानते हुए कि सर्वर कमोडिटी हार्डवेयर और सॉफ्टवेयर का उपयोग करता है।" यदि आप कमोडिटी हार्डवेयर और सॉफ़्टवेयर का उपयोग नहीं कर रहे हैं, तो आप रीड ओनली स्टोरेज से बूट जैसे काम कर सकते हैं और केवल एक एन्क्रिप्टेड डेटाबेस का उपयोग कर सकते हैं, जिसके लिए प्रत्येक बूट पर एक व्यक्ति को डिक्रिप्शन कुंजी प्रदान करने की आवश्यकता होती है। उसके बाद, डिक्रिप्ट की गई जानकारी केवल मेमोरी में रहती है, और डिस्क पर कभी नहीं लिखी जाती है। इस तरह, यदि सर्वर चोरी हो जाता है, तो एक हमलावर को सर्वर को अनप्लग करना पड़ता है और इसलिए वह सभी डिक्रिप्टेड जानकारी खो देता है जो केवल स्मृति में थी। इस प्रकार के सेटअप को कभी-कभी Kerberos KDC (अतिरिक्त सुरक्षा के लिए लॉक बॉक्स में सर्वर के साथ) के लिए उपयोग किया जाता है, लेकिन शायद ही कभी इसका उपयोग किया जाता है, और स्पष्ट रूप से ओवरकिल होता है जब आपकी समस्या को हल करने का एक आसान तरीका होता है बिना यह सब अतिरिक्त खर्च।
