सौर डिजाइनर फिर भी एक और सम्मेलन 2012

हमारे लिए निवर्तमान वर्ष का एक आकर्षण अभी तक एक और सम्मेलन 2012 था । इसके प्रतिभागियों में अलेक्जेंडर पेस्लीक थे , जिन्हें सौर डिजाइनर के रूप में जाना जाता था।

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

कंप्यूटर सुरक्षा पर रिपोर्टों के साथ, अलेक्जेंडर ने कई अंतर्राष्ट्रीय सम्मेलनों में भाग लिया - HAL2001, नॉर्डू, FOSDEM, CanSecWest, PHDays। YaC 2012 में, उन्होंने बताया कि कैसे लाखों पासवर्डों को सुरक्षित रखें । प्रदर्शन से पहले, हमने उनका थोड़ा साक्षात्कार किया। सोलर डिज़ाइनर ने बताया कि कैसे वह एक कंप्यूटर सुरक्षा विशेषज्ञ बन गया और उसने अपनी वर्तमान स्थिति पर अपना विचार साझा किया।



सच कहूं तो, जब मैंने सोचा कि वाईसी बोलने वालों में से कौन सा अतिरिक्त बात करता है, तो मैं यैंडेक्स में कई लोगों के पास आया और यह सवाल पूछा। कोई आपको नहीं जानता था, और कोई व्यक्ति, वक्ताओं के बीच आपका नाम देखकर तुरंत बोला: “उसे बुलाओ! आप कैसे सोच सकते हैं कि उसके बारे में क्या बात है! ”ऐसा लगता है कि सभी लोग नहीं जानते कि आप क्या कर रहे हैं और केवल वे ही जानते हैं जो समझते हैं कि यह कितना दिलचस्प है। मुझे पहले बताएं कि आप क्या करते हैं और आप इस विषय पर बात क्यों करते हैं?

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

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

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

और हैशिंग के लिए कार्य अब खराब क्यों हैं?

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

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

अपनी रिपोर्ट में, मैं सिर्फ इस बारे में बात कर रहा हूं। एक मिलीसेकंड का स्तर पहले से ही एक समझौता है: मैं सौ चाहूंगा, लेकिन हम एक नीचे जाने के लिए तैयार हैं।

और क्या अभी भी scrypt का उपयोग करना संभव है?

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

क्या यह नमक की तरह है या यह कुछ और है?

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

अलग क्यों किया जाना चाहिए?

हां, अशुद्धि या तो भौतिक केबल द्वारा या क्रिप्टोग्राफिक प्रोटोकॉल द्वारा प्रदान की जानी चाहिए, अगर यह कंपनी के अंदर किसी तरह की सुरंग के माध्यम से हो।

क्या सुरक्षा मुद्दे महत्वपूर्ण हैं लेकिन आपको कम करके आंका गया है?

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

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

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

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

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

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

स्रोत कोड के बजाय संकलित किसी चीज़ का अध्ययन करना किन मामलों में अधिक उपयोगी है, जब बिना किसी विशेष अनुकूलन के भी इसका अध्ययन करने का अवसर है?

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

लेकिन कंपाइलर जिसमें ऑप्टिमाइज़ेशन डिसेबल है वह भी अलग होगा।

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