📴 🖐🏿 🤞🏿 OpenSSH की डिफ़ॉल्ट कुंजी एन्क्रिप्शन किसी से भी बदतर नहीं है 👨🏾‍🎤 📳 🕺🏼

इस लेख के लेखक ओपनएसएसएच में मानक कुंजी एन्क्रिप्शन तंत्र के खिलाफ तर्क देते हैं।

हमलावरों ने हाल ही में उपयोगकर्ता के घर निर्देशिकाओं से npm टोकन चोरी करने के लिए npm पैकेज एस्लिन्ट-स्कोप का उपयोग किया है। इस घटना के प्रकाश में, हमने अन्य समान कमजोरियों की जांच करना शुरू किया और सोचा कि इस तरह की घटनाओं के जोखिम और परिणामों को कैसे कम किया जाए।

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

user@work /tmp $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): mykey ... user@work /tmp $ head -n 5 mykey -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,CB973D5520E952B8D5A6B86716C6223F +5ZVNE65kl8kwZ808e4+Y7Pr8IFstgoArpZJ/bkOs7rB9eAfYrx2CLBqLATk1RT/

यह कुंजी एन्क्रिप्ट की गई है, जैसा कि फ़ाइल की पहली लाइनों में से एक द्वारा इंगित किया गया है। इसके अलावा, शुरुआत में RSA में MII - base64 एन्कोडिंग कुंजी का उपयोग नहीं किया गया है। और, बेशक, एईएस आपकी आंख को पकड़ता है! यह अच्छा है, है ना? और सीबीसी, पहली नज़र में, एक यादृच्छिक आरंभीकरण वेक्टर के साथ। कोई प्रमाणीकरण कोड (मैक) नहीं है। तो ठीक है, कोई गद्दी का दौरा नहीं होगा, है ना?

यह पता लगाना कि DEK-Info की सामग्री वास्तव में कितनी सरल है। खुलता-पोर्टेबल रिपॉजिटरी में कीवर्ड "DEK-Info" की खोज केवल चाबियों के उदाहरण से पता चलता है। लेकिन यहां मुद्दा यह है कि एईएस कुंजी एक साधारण एमडी 5 हैश (पासवर्ड || आरंभीकरण वेक्टर [: 8]) से ज्यादा कुछ नहीं है। और यह बुरा है, क्योंकि पासवर्ड को संग्रहीत करने के लिए सर्वोत्तम अभ्यासों का कहना है कि पासवर्ड उनके शुद्ध रूप में, कम एंट्रोपी के कारण, खराब एन्क्रिप्शन सामग्री है। और इसे बेहतर बनाने के लिए, आपको आर्गन 2 जैसे महंगे फ़ंक्शन की आवश्यकता है। लेकिन एमडी 5, बाद के विपरीत, गणना करना आसान है।

इस योजना में केवल सकारात्मक बिंदु यह है कि नमक पासवर्ड के बाद रखा गया है, इसलिए, यह मध्यवर्ती राज्य MD5 (IV [8:]) की गणना करने और इसके आधार पर पासवर्ड खोजने के लिए काम नहीं करेगा। लेकिन यह थोड़ा सांत्वना है, खासकर एक ऐसे युग में जब प्रति सेकंड अरबों एमडी 5 कॉल करने वाली मशीनें हमारे पास उपलब्ध हैं - पासवर्ड से अधिक के साथ आ सकते हैं।

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

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

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

आरएसए कुंजियों की जोड़ी के बारे में खुद कोई शिकायत नहीं है: एकमात्र सवाल निजी कुंजी के सममित एन्क्रिप्शन के तरीके हैं। केवल सार्वजनिक कुंजी को जानते हुए, ऊपर वर्णित हमले को अंजाम देना असंभव है।

मैं स्थिति को कैसे ठीक कर सकता हूं?

OpenSSH उपयोग करने के लिए एक नया कुंजी प्रारूप प्रदान करता है। 2013 में नए का मतलब है। यह प्रारूप bcrypt_pbkdf का उपयोग करता है, जो अनिवार्य रूप से PBKDF2 मानक के तहत कार्यान्वित एक निश्चित-जटिलता bcrypt है।

आसानी से, आप स्वतः ही एक नए प्रारूप में एक कुंजी प्राप्त करते हैं, जब Ed25519 कुंजी बनाते हैं, क्योंकि पुराने SSH कुंजी प्रारूप नए प्रकार की कुंजी का समर्थन नहीं करता है। यह बल्कि अजीब है, क्योंकि वास्तव में हमें यह निर्धारित करने के लिए मुख्य प्रारूप की आवश्यकता नहीं है कि Ed25519 क्रमांकन कैसे काम करता है, क्योंकि Ed25519 स्वयं क्रमांकन कार्य सेट करता है। लेकिन अगर आपको वास्तव में एक अच्छे फॉर्मेटिव फंक्शन की जरूरत है, तो आप ऐसी ट्राइफल्स से परेशान नहीं हो सकते। परिणामस्वरूप, उत्तरों में से एक ssh-keygen -t ed25519 है ।

यदि, संगतता कारणों के लिए, आपको RSA का पालन करना चाहिए, तो आप ssh-keygen -o का उपयोग कर सकते हैं। इस प्रकार, पुराने प्रकार की चाबियों के लिए भी एक नया प्रारूप प्राप्त किया जा सकता है। आप कमांड ssh-keygen -p -o -f कुंजी नाम के साथ पुरानी कुंजियों को अपडेट कर सकते हैं। यदि आपकी चाबियाँ Yubikey या स्मार्ट कार्ड पर रहती हैं, तो इन संशोधनों को पहले ही ध्यान में रखा जा चुका है।

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

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

और अंत में - पूर्ण कुंजी का लिंक । यह उस स्थिति में है जब आप आज कुछ भी हैक करने के लिए तैयार हैं।

OpenSSH की डिफ़ॉल्ट कुंजी एन्क्रिप्शन किसी से भी बदतर नहीं है

मैं स्थिति को कैसे ठीक कर सकता हूं?

More articles: