आज, वेब संसाधनों पर पासवर्ड और पारंपरिक प्रमाणीकरण विधियों से बचने का विचार अधिक से अधिक बार उठाया जा रहा है, और Google, पेपैल और FIDO गठबंधन के अन्य सदस्यों के रूप में आईटी उद्योग के दिग्गजों ने इस बात का ध्यान रखा है। Google कर्मचारियों द्वारा किए गए शोध के हिस्से के रूप में, प्रमाणीकरण विधियों में सुधार के तरीकों का प्रस्ताव किया गया था, साथ ही टीएलएस विस्तार मानक का एक मसौदा तैयार किया गया था, जो कुकीज़ के उपयोग को समाप्त करता है।

इस लेख में, मैं पारंपरिक प्रमाणीकरण योजनाओं की समस्याओं के बारे में बात करूँगा, दो-चरणीय प्रमाणीकरण शुरू करने में आने वाली गड़बड़ियों के बारे में और प्रस्तावित टीएलएस विस्तार मानक पर विचार करूँगा। लेख का पाठ उन वेब डेवलपर्स के लिए उपयोगी होगा जो दो-चरणीय प्रमाणीकरण को एकीकृत करने की योजना बनाते हैं।

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

उनके महत्व द्वारा खातों का पृथक्करण
उपयोगकर्ता-पारदर्शी प्रमाणीकरण का उपयोग करना

खाता भेद

जाहिर है, सभी खातों को मजबूत प्रमाणीकरण की आवश्यकता नहीं होती है। Google उन्हें निम्नलिखित प्रकारों में विभाजित करने का सुझाव देता है:

उन सेवाओं पर एक बार का खाता जहां उपयोगकर्ता अब वापस लौटने की योजना नहीं बनाता है। ऐसी सेवाओं को मजबूत प्रमाणीकरण नियंत्रण की आवश्यकता नहीं है।
विशिष्ट खाते जो उपयोगकर्ता को पोषित करते हैं, लेकिन उनके नुकसान में सामग्री या प्रतिष्ठित नुकसान नहीं होता है।
सार्वजनिक खाते: बड़ी संख्या में ग्राहकों के साथ ट्विटर या एक ब्लॉग, साथ ही क्रेडिट कार्ड की जानकारी के साथ ऑनलाइन स्टोर का डेटाबेस
महत्वपूर्ण खाते: प्राथमिक डाक पते या ऑनलाइन बैंकों के खाते।

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

विशिष्ट धमकियां

किसी भी खाते की विशेषता निम्न भोज से है और बहुत खतरे नहीं:

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

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

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

पुराने प्रमाणीकरण के नए तरीके

उपकरणों के लिए प्रमाणीकरण प्रमाणीकरण

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

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

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

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

बहु-कारक प्रमाणीकरण पर विचार

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

सबसे सरल दो-चरण प्रमाणीकरण को लागू करते समय, आपको विचार करने की आवश्यकता है:

एप्लिकेशन का व्यवहार जब उपयोगकर्ता सेलुलर नेटवर्क के बाहर होता है (उदाहरण के लिए, छुट्टी पर)
उनके खाते की उपयोगकर्ता पुनर्प्राप्ति प्रक्रिया
डिवाइस / मोबाइल नंबर बदलने और एक्सेस टैग्स को निरस्त करने की प्रक्रिया

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

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

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

एक मध्यवर्ती उत्पादन के रूप में

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

हार्डवेयर और कार्यान्वयन के करीब

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

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

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

यह ध्यान देने योग्य है कि क्रोम ब्राउज़र डेवलपर्स का अनुभव बताता है कि सरल प्रमाणीकरण के लिए प्रमाण पत्र का उपयोग करना उचित नहीं है। इस संबंध में, Google TLS प्रोटोकॉल का एक विस्तार बनाने का प्रस्ताव करता है, जो ऊपर वर्णित प्रमाणीकरण योजना को लागू करेगा।

TLS ChannelID एक्सटेंशन

यह एक्सटेंशन IETF ड्राफ्ट में वर्णित है और TLS प्रोटोकॉल के विस्तार के लिए एक तंत्र प्रदान करता है, जो आपको HTTP कुकीज़ या OAuth टोकन जैसे प्रमाणीकरण टोकन (अंग्रेजी, बियर टोकन) के हस्तांतरण से छुटकारा पाने की अनुमति देता है।

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

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

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

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

टीएलएस हैंडशेक प्रक्रिया विवरण

कनेक्शन स्थापित करते समय, क्लाइंट ClientHello संदेश में "channel_id (0x754F)" एक्सटेंशन जोड़ सकता है। यदि सर्वर इस एक्सटेंशन का समर्थन करता है, तो यह क्लाइंट को ServerHello संदेश में संकेत दे सकता है।

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

struct { opaque x[32]; opaque y[32]; opaque r[32]; opaque s[32]; } ChannelIDExtension;

यहां x, y, r और s 32-बाइट बड़े-एंडियन नंबर हैं। X और y फ़ील्ड में P-256 अण्डाकार वक्र के affine निर्देशांक होते हैं, और r और s फ़ील्ड में संबंधित निजी कुंजी के साथ ECDSA हस्ताक्षर होते हैं। सामान्य TLS हैंडशेक नीचे दिए गए चित्र में दिखाया गया है। ग्रीन ने मानक की तुलना में संशोधनों पर प्रकाश डाला।

निष्कर्ष में

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

एक नए रास्ते में प्रमाणीकरण, या सुपर कुकीज़