एचएल 2018. रिपोर्ट का सारांश “पासवर्ड को फिर से महान बनाएं! ब्रूट फोर्स को कैसे हराएं और हैकर्स को कुछ नहीं छोड़ें ”

नमस्कार, हेब्र! मेरा नाम अखमदेव रिनत है, मैं सीनियर हूं। PHP डेवलपर।

मैं आपके समक्ष रिपोर्ट का सारांश प्रस्तुत करता हूँ, पासवर्ड को फिर से महान बनाएं! ब्रूटफोर्स को कैसे हराया जाए और हैकरों को हाईग्लाद ++ 2018 के साथ विर्जिल सिक्योरिटी के एलेक्सी एर्मिशकिन से कुछ भी नहीं छोड़ना चाहिए ।

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

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

मुझे रिपोर्ट इतनी पसंद आई कि मैंने एक कम्पेंडियम तैयार किया। मैं हर किसी को खुद को परिचित करने की सलाह देता हूं।

एलेक्सी एर्मिशकिन ने स्लाइड्स और वीडियो रिपोर्ट को टिप्पणियों में साझा किया:

सारांश

प्रविष्टि

सभी को नमस्कार, सभी को सुप्रभात! मुझे आप सभी को हाईलोड सम्मेलन में देखकर खुशी हुई। मेरा नाम एलेक्सी एर्मिशकिन है, मैं वर्जिल सिक्योरिटी के लिए काम करता हूं।

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

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

तो, आज हम किस बारे में बात करने जा रहे हैं?

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

हैश

सिद्धांत रूप में, पासवर्ड इस तरह के एक व्यथा विषय क्यों हैं, यह उनके साथ अधिक सावधानी से काम करने के लायक क्यों है? समस्या यह है कि पासवर्ड में एक छोटा एंट्रॉपी है । एन्ट्रापी क्या है यह डेटा में निहित जानकारी की मात्रा है, अर्थात उदाहरण के लिए, हाईलोड शब्द में 8 अक्षर 8 बाइट्स हैं, लेकिन अगर हम एन्ट्रॉपी की गणना करते हैं, तो यह पूरे शब्द की तरह 64 बिट्स नहीं होगा, बल्कि 30 बिट्स से कम होगा। जब आज वे पासवर्ड तोड़ने की बात करते हैं, तो वे कहते हैं कि ऐसे समय में एंट्रॉपी के साथ पासवर्ड को क्रैक करना संभव है और न ही इतने सारे बिट्स से कम है। यानी यहां तक ​​कि पासवर्डों की संख्या को भी ध्यान में नहीं रखा जाता है।

पासवर्ड सुरक्षा के साथ लोगों की शुरुआत कैसे हुई? पहली बात जो दिमाग में आई वह थी यूनिडायरेक्शनल क्रिप्टोग्राफिक हैश का उपयोग करना।

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

रेनबो टेबल

इसके अलावा, प्रत्येक मुश्किल हैश की अपनी इंद्रधनुष तालिका है । यह तालिका क्या है और कैसे बनाई जाती है?

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

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

नमक

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

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

खोज को धीमा कैसे करें?

इससे निकलने का एक प्राकृतिक तरीका है कि किसी तरह से हैश की छंटाई को धीमा किया जा सके। यह कैसे किया जा सकता है?

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

SCrypt , Bcrypt , Argon2

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

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

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

फेसबुक का पासवर्ड प्याज

लोगों ने इस बारे में सोचा और सवाल पूछा: क्या बैकेंड को लोड किए बिना, अपने स्वयं के सर्वर को लोड किए बिना समान गुण प्राप्त करना संभव है?

इसमें से एक अग्रणी फेसबुक था । ये लाइनें जो आप देख रहे हैं, फेसबुक के ऐतिहासिक चरण हैं, उन्होंने पासवर्ड की सुरक्षा कैसे की, पहले तो सिर्फ पासवर्ड थे, फिर उन्होंने पुराने md5 फ़ंक्शन को लिया, जो लंबे समय से क्रैक था, फिर उन्होंने वहां नमक जोड़ा और sha1 हैश लिया, और फिर यह हुआ दिलचस्प बात है, वे दूरस्थ सेवा के लिए hmac फ़ंक्शन (यह एक कुंजी के साथ एक हैश है) की गणना लाए।

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

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

गूढ़ व्यक्ति

क्रिप्टोग्राफर्स ने पूरी बात को देखा। उन्हें दूरस्थ सेवाओं का उपयोग करने का विचार पसंद आया और सोचने का फैसला किया: क्या यह और भी बेहतर करना संभव है? क्या एक समान प्रणाली बनाना संभव है, लेकिन उन minuses के बिना जिन्हें Facebook ने इसके साथ संपन्न किया है?

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

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

Sphinx ने इस समस्या से कैसे संपर्क किया? वह मास्टर पासवर्ड लेता है, वह उस डोमेन को लेता है जिसे आप लॉग इन करना चाहते हैं, पूरी चीज़ को हैश के माध्यम से चलाता है और इसे एक नंबर में बदल देता है। लेकिन वास्तव में, वहाँ अण्डाकार क्रिप्टोग्राफी का उपयोग किया जाता है, सादगी के लिए मैं साधारण गणित के साथ साधारण संख्याओं पर यह सब समझाऊंगा। वह इसे एक संख्या में बदल देता है (इसे कॉल करें a ) और वह आगे क्या करता है?

बिल्कुल आश्चर्यजनक बात है, हर बार हम एक बड़े यादृच्छिक संख्या r उत्पन्न कर सकते हैं। यदि हम संख्या को r की शक्ति तक बढ़ाते हैं, और कुछ समय बाद हम इस संख्या को संख्या r व्युत्क्रम में बढ़ाते हैं, तो हम उसी संख्या को वापस प्राप्त करते हैं a , right? यानी हम शुरुआत से ही कुछ नकाब कर सकते हैं, और फिर इसे उतार सकते हैं।

और स्फिंक्स क्या करता है? फिर से एक उपयोगकर्ता है, एक दूरस्थ सेवा है। इस दूरस्थ सेवा के लिए एक नकाबपोश नंबर भेजा जाता है। रिमोट सेवा पर, एक निजी कुंजी b । वह क्या कर रहा है? वह अपने गुप्त कुंजी b द्वारा भेजे गए नंबर a^r गुणा करता है और उसे वापस भेजता है। ( संकलन के लेखक का ध्यान दें: स्लाइड पर, भेजी गई संख्या को निजी कुंजी से गुणा नहीं किया जाता है, बल्कि निजी कुंजी की डिग्री तक उठाया जाता है, लेकिन मुख्य बिंदु यह है )। चूंकि नंबर r हर बार अलग होता है, इसलिए दूरस्थ सेवा कुछ भी नहीं कह सकती है कि कौन से पासवर्ड और डोमेन को मास्क किया गया था, अर्थात्। हर बार वह कुछ अलग यादृच्छिक संख्याएँ देखता है। और वह बस अपने निजी कुंजी b गुणा करता है और वापस भेजता है।

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

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

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

पाइथिया

क्या यह बेहतर हो सकता है?

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

और वे पायथिया नामक एक प्रोटोकॉल के साथ आए।

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

यह कैसे काम करता है? एक बैकएंड (कुछ प्रकार की वेब सेवा, साइट) है और एक पायथिया सेवा है। बैकएंड क्या करता है और सर्विस क्या करता है? सेवा पर एक निजी कुंजी k , लेकिन यह बैकएंड पर अपनी सार्वजनिक कुंजी भी स्थानांतरित करता है। सेवा बैकेंड न केवल नकाबपोश नंबर a^r भेजता है, जैसा कि स्फिंक्स प्रोटोकॉल में है, बल्कि कुछ प्रकार के उपयोगकर्ता पहचानकर्ता ( UserID ) भी भेजता है। सेवा उपयोगकर्ता आईडी और पासवर्ड को अपनी निजी कुंजी से गुणा करती है और परिणाम (UserID, a)^(r*k) बैकएंड भेजती है। वह प्रतिक्रिया में एक निश्चित Proof भी भेजता है, जिसका उपयोग बैकएंड द्वारा सर्वर की जांच के लिए किया जा सकता है कि इसे हैक नहीं किया गया है, क्योंकि यह जवाब देना चाहिए।

फिर एक अनमास्किंग होती है और एक परिणाम के रूप में जो y निकलता है उसे एक DB में डाल दिया जाता है। डेटाबेस में हमारे पास न केवल एक हैश है, बल्कि एक संख्या है, एक अण्डाकार वक्र का एक बिंदु है।

यहाँ कुछ दिलचस्प बिंदु हैं:

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

इस प्रणाली के क्या फायदे हैं?

और वह उनमें से कई नहीं है।

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

लेकिन ये सभी अच्छाइयाँ नहीं हैं।

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

लेकिन यह सब नहीं है।

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

शहद की एक बैरल में, यह मरहम में एक मक्खी के बिना नहीं है।

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

पीएचई

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

और शाब्दिक रूप से इस वर्ष के जुलाई में, वैज्ञानिकों ने एक नया प्रोटोकॉल जारी किया, जिसे सरल पासवर्ड-हार्डक्रिप्शन एन्क्रिप्शन सर्विसेज या संक्षिप्त रूप से PHE कहा गया।

यह रसेल लाई है , जो यूरोप का एक वैज्ञानिक है।

इस सेवा का क्या लाभ है? सबसे पहले, यह मानक P-256 वक्र का उपयोग करता है, जिसका उपयोग सभी ब्राउज़रों, उत्पादों, हर जगह डिफ़ॉल्ट वक्र में किया जाता है, जो कई वर्षों से लगभग है। दूसरे, यह बात पायथिया की तुलना में लगभग 10 गुना तेज काम करती है और मानक प्राइमेटिव का उपयोग करती है। यह कठिन है, लेकिन आप इसे बिना किसी अस्पष्ट पुस्तकालयों का उपयोग किए अपने हाथों से लागू कर सकते हैं। आप ओपनएसएसएल , या बाउंसी कैसल , कुछ भी उपयोग कर सकते हैं।

लेकिन यह थोड़ा अलग तरीके से काम करता है। फिर से बैकएंड है, पीएचई सेवा है। बैकएंड में एक सार्वजनिक कुंजी है, सेवा के पास एक निजी कुंजी है। पायथिया के विपरीत, पंजीकरण प्रक्रिया और पासवर्ड सत्यापन प्रक्रिया थोड़ी अलग हैं। जब कोई नया उपयोगकर्ता सेवा में आता है और पंजीकरण करना चाहता है, तो बैकएंड क्या करता है? शुरुआत से, उन्होंने पीएचई सेवा से पूछा, कृपया मुझे कुछ डेटा दें जो मैं पंजीकृत करने के लिए उपयोग कर सकता हूं, किसी प्रकार का नामांकन रिकॉर्ड। सेवा ठीक है और निम्न बातों के साथ बैकएंड का जवाब देती है। यह कुछ यादृच्छिक 32-बाइट नमक ( sNonce ) उत्पन्न करता है। इस नमक और इसकी निजी कुंजी y के आधार पर, यह दो नंबर उत्पन्न करता है, चलो उन्हें C0 और C1 कहते हैं। यह सबूत ( Proof ) भी उत्पन्न करता है कि ये दो नंबर या 2 अंक ठीक इसके निजी कुंजी y का उपयोग करते हुए, Schnorr प्रोटोकॉल (पिछले प्रोटोकॉल की तरह) का उपयोग करके उत्पन्न किए गए थे। बैकेंड Proof जांच करता है। यहां अभी तक कोई पासवर्ड नहीं है। बैकेंड क्या करता है? अपने हिस्से के लिए, उसके पास अपना निजी क्लाइंट निजी कुंजी x और, उपयोगकर्ता से पासवर्ड प्राप्त करने के बाद, वह सेवा के रूप में उसी के बारे में करता है, जो केवल वहां एक पासवर्ड जोड़ता है। यह यादृच्छिक cNonce (यादृच्छिक क्लाइंट नमक), एक पासवर्ड लेता है, और फिर से 2 नंबर HC0 और HC1 उत्पन्न करता है। 2 क्यों? क्योंकि पहले HC0 प्रमाणीकरण के लिए उपयोग किया जाता है, और दूसरी संख्या HC1 कुछ यादृच्छिक संख्या M को निजी कुंजी x ( MC ) द्वारा गुणा किया जाता है। M की संख्या भी आकार में 32 बाइट्स है और बाद में इसका उपयोग उपयोगकर्ता डेटा (हमारे पास एन्क्रिप्शन सेवा है) को एन्क्रिप्ट करने के लिए किया जा सकता है ( नोट के लेखक द्वारा नोट: इस मामले में एन्क्रिप्शन कुंजी MC होगी )। उपयोगकर्ता द्वारा सही पासवर्ड दर्ज करने के बाद ही MC नंबर एक कुंजी के रूप में उपलब्ध होगा। यह पंजीकरण चरण में पता चलता है कि आप न केवल एक प्राधिकरण रिकॉर्ड उत्पन्न कर सकते हैं, बल्कि एक एन्क्रिप्शन कुंजी भी, प्रत्येक उपयोगकर्ता के लिए अद्वितीय है, जिसके साथ आप उसकी प्रोफ़ाइल, कुछ डेटा और कुछ और को एन्क्रिप्ट कर सकते हैं। फिर बैकएंड केवल यह बताता है कि सेवा ने क्या भेजा और उसने क्या किया - इन बिंदुओं को जोड़ता है और T0 और T1 । पहले मामले में, यह दो ( C0 + HC0 ) को C0 + HC0 , और दूसरे तीन ( C1 + HC1 + MC ) में। और वह आधार 2 लवण ( sNonce , cNonce ) में डालता है, cNonce सहायता से ये संख्याएँ प्राप्त हुईं और 2 संख्याएँ ( T0 और T1 ), जो योग के परिणामस्वरूप निकलीं।

तदनुसार, उपयोगकर्ता प्रमाणीकरण प्रक्रिया रिवर्स ऑर्डर में होती है। उपयोगकर्ता बैकएंड पर अपना पासवर्ड दर्ज करता है। बैकएंड HC0 गणना HC0 और इसके डेटाबेस में जो है, HC0 T0 से HC0 को HC0 है और परिणामी C0 को सर्वर नमक के साथ सेवा में भेजता है। सर्वर नमक जानने वाली सेवा, अपने आप में एक ही बिंदु की गणना करती है और देखती है, यह इस तथ्य से मेल खाती है कि उसने बैकएंड भेजा है या नहीं, यदि यह मेल खाता है, तो पासवर्ड सही है और आप इसका जवाब दूसरे नंबर C1 साथ दे सकते हैं, जिसे वह नंबर से HC1 साथ HC1 । T1 और एन्क्रिप्शन कुंजी प्राप्त करें। इस प्रकार, PHE सेवा का पासवर्ड भी नहीं जाता है। वह बैकएंड भी नहीं छोड़ता है। यह बैकएंड की निजी कुंजी द्वारा गुणा किए गए कुछ बिंदुओं के रूप में है। यह इस तरह भी मौजूद नहीं है, लेकिन एक ही समय में, दूरस्थ सेवा इस बारे में एक सख्त निष्कर्ष निकाल सकती है कि यह पासवर्ड सही है या नहीं और साबित हो सकता है, इसके अलावा, उसने अपनी निजी कुंजी y का उपयोग करके सभी गणनाएं y ।

इस प्रणाली में क्या विशेषताएं हैं?

पासवर्ड, जैसा कि मैंने कहा, बैकएंड नहीं छोड़ता है। लेकिन पायथिया के विपरीत, आपको बैकएंड पर एक निजी कुंजी की आवश्यकता होती है। खैर, हमें जरूरत है और जरूरत है, कहीं और बचत करें। PHE में पायथिया के सभी बुनियादी कार्य हैं:

• यदि आपके पास निजी कुंजी के साथ कुछ हुआ है तो आप अपडेट टोकन भी जारी कर सकते हैं;
• आप पूरे डेटाबेस के माध्यम से भी जा सकते हैं, अपडेट कर सकते हैं और सब कुछ वैसा ही होगा जैसा कि था;
• खोज सुरक्षा;
• सेवा पासवर्ड के बारे में कुछ नहीं जानती;
• (Pythia , , , , PHE );
• .

...

… . . passw0rd.io . password , 18- , , zero trust, .. . , , .. Let's encrypt . , . CLI , . 2 SDK , GO .Net, .

:

1. .
2. .
3. .

• VirgilSecurity.com
• @VirgilSecurity
• GitHub.com/VirgilSecurity
• NoiseSocket.com
• passw0rd.io

, .

?

37. ?

.

Q: , ! . , Pythia update token, ? private key . update token? या नहीं?
A: , update token- .
Q: . - update token-, Private key ?
A: , update token-, , - , , , update token. , .. .
Q: , , , .
A: .. .

Q: , , , - Pythia - , , , ?
A: .
Q: ?
A: , Pythia . यानी , .
Q: ( ) bcrypt ?
A: , , , .

Q: , . ? , …
A: password
Q: password ? आग! आम तौर पर।
A: 123456 , 12345, 123456.
Q: . Pythia , PHE .
A: , .
Q: . . ? production ?
A: . एक! Pythia.
Q: Pythia, , ?
A: .
Q: , ?
A: .
Q: , , !
A: SDK, .

Q: , , , , .. - , ? ? ?
A: , , , .. PHE, , 5 2 , 2 5 . , . PHE ( , ), , 10 , .
Q: .. - , - ? ?
A: . rate limiting, , .
Q: .. , ?
A: .

Q: . , .. Pythia (), , ? ?
A: , , .
Q: , update ?
A: , Pythia , , - - , , , )

A: ? ! . , , PHE, , .

निष्कर्ष

PHE ( ) + — ( , , ) ( ). PHE , .

:

• ( ) ;
• ( ).

, .

Scratch Virgil Security , , !

( )?

UPD : Scratch . . , . .