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

समस्या और समाधान

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

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

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

इथेरियम यहां कैसे मदद कर सकता है? हमने पहले ही महसूस किया कि तीन मुख्य समस्याएं हैं:

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

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

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

कार्यान्वयन

हमारे समाधान में, मैंने उपयोगकर्ता आईडी और संबंधित वॉलेट पते को संग्रहीत करने के लिए एक सरल ईथरथ कॉन्ट्रैक्ट लिखा। उपयोगकर्ता आईडी आकार में केवल 2 और 32 बाइट्स के बीच एक UTF-8 स्ट्रिंग है। यह एक बार स्वयं उपयोगकर्ता द्वारा आविष्कार किया गया था और बाद में एथरथ का समर्थन करने वाली किसी भी साइट पर लॉग इन करता था। आज मैं स्ट्रिंग में शामिल संभावित पात्रों पर प्रतिबंध लगाऊंगा, ताकि बाहरी समान रूप से लॉगिन बनाने की क्षमता को सीमित करने के लिए लैटिन वर्णों और अरबी अंकों (7-बिट ASCII एन्कोडिंग के सबसेट) का उपयोग करने की संभावना को छोड़ दें।

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

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

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

EtherAuth का उपयोग करते हुए सामान्य उपयोगकर्ता प्रमाणीकरण प्रक्रिया इस तरह दिखाई देती है:

• साइट (बैकएंड) एक स्मार्ट अनुबंध में बदल जाती है और उपयोगकर्ता के Ethereum पते को प्राप्त करती है;
• साइट (बैकएंड) कुछ संदेश उत्पन्न करती है और याद करती है और उपयोगकर्ता को इस संदेश को ऑर्किटेय एड्रेस का उपयोग करके साइन करने के लिए कहती है;
• उपयोगकर्ता, साइट (फ्रंटएंड) पर होने के नाते, मेटामास्क प्लगइन का उपयोग करके संदेश पर हस्ताक्षर करता है और इसे बैकएंड पर भेजता है;
• साइट (बैकएंड) हस्ताक्षर की पुष्टि करता है, और यदि सब कुछ क्रम में है, तो यह उपयोगकर्ता सत्र को उसके चुने हुए तर्क के अनुसार सक्रिय करता है।

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

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

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

निष्कर्ष

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

संदर्भ

• स्रोत कोड