एसआरपी -6: पासवर्ड रहित प्रमाणीकरण

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

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

इसलिए, एसआरपी की कम संख्या का उपयोग करके उपयोगकर्ता प्रमाणीकरण की सामान्य योजना इस तरह दिखती है:

• "सुरक्षा क्षेत्र" ऑपरेशन के लिए चुना गया है:
  H = , .
N = " " = 2*q+1 , q .
g = N => 0 < X < N x , g^x % N = X.
k = -. SRP-6a H(N, g); SRP-6 3
• पंजीकरण के बाद, ग्राहक निम्नलिखित गणना करता है:
  s = random_string()
x = H(s, p)
v = g^x % N
  और सर्वर को तीन फ़ील्ड भेजता है:
  I = username
s = salt
v = password verifier
g और N के सही विकल्प के साथ, इस डेटा का स्थानांतरण काफी सुरक्षित है - पी प्राप्त करना कम्प्यूटेशनल रूप से मुश्किल है।
  असतत लघुगणक संचालन की जटिलता से सुरक्षा सुनिश्चित की जाती है - x से v=g^x%N जानना v, g, N v=g^x%N से प्राप्त करना v, g, N
  यह इस कारण से है कि, भले ही उपयोगकर्ता डेटाबेस (हैलो सोनी!) सर्वर से सूखा है, पासवर्ड प्राप्त करना या उपयोगकर्ता के रूप में खुद को पेश करना असंभव होगा।
  हालांकि, यह ध्यान दिया जाना चाहिए कि यदि उपयोगकर्ता डेटाबेस को मर्ज किया जाता है, तो प्रोटोकॉल _server_ द्वारा हमलावर के प्रतिनिधित्व से संरक्षित किया जाना बंद हो जाता है। यही है, यह विधि क्लाइंट को गारंटी नहीं देती है कि सर्वर वह है जो यह होने का दावा करता है। हालांकि, एक मैन-इन-द-मिडिल हमला असंभव बना हुआ है - एक हमलावर (कम्प्यूटेशनल रूप से मुश्किल नहीं) अपने सर्वर से एक सत्र कुंजी K प्राप्त कर सकता है।
• उपयोगकर्ता:
  I = username
a = random()
A = g^a % N
  लॉगिन I और गणना A की एक जोड़ी सर्वर को प्रेषित की जाती है।
  सर्वर को जांचना चाहिए और सुनिश्चित करना चाहिए कि ए! = 0।
• सर्वर को इसके ज़श्निकों से लॉगिन के लिए दो नंबर मिलते हैं:
  s = ,
v = ,
  फिर यह एक यादृच्छिक संख्या b उत्पन्न करता है, और गणना करता है
  B=(k*v + g^b % N) % N
  नमक की गणना और B की एक जोड़ी ग्राहक को भेजी जाती है।
  इस क्षण के ग्राहक को उस B != 0 को सत्यापित करना चाहिए।
• दोनों पक्ष स्क्रैम्बलर की गणना करते हैं:
  u = H(A, B) ।
  यदि u == 0, कनेक्शन समाप्त हो गया है।
• क्लाइंट अपने पासवर्ड p प्रवेश करता है, जिसके आधार पर साझा सत्र कुंजी की गणना की जाती है:
  x = H(s, p)
S = ((B - k*(g^x % N)) ^ (a + u*x)) % N
K = H(S)
• सर्वर, इसके भाग के लिए, साझा सत्र कुंजी की गणना भी करता है:
  S = ((A*(v^u % N)) ^ b) % N
K = H(S)
• इस बिंदु से, यदि क्लाइंट और सर्वर दोनों _really_ एक-दूसरे को जानते हैं, तो दोनों के लिए एक समान संख्या K है।
  एक दूसरे को यह साबित करने के लिए कि वे खुद दुष्ट पिनोचियो हैं, विनिमय का दूसरा दौर।
  ग्राहक एक पुष्टिकरण उत्पन्न करता है:
  M = H( H(N) XOR H(g), H(I), s, A, B, K)
  और सर्वर को भेजता है।
  सर्वर स्वयं K की प्रतिलिपि का उपयोग करके M की गणना करता है, और समानता के लिए जाँच करता है। यदि वे समान हैं, तो क्लाइंट के पास वास्तव में एक ही K है, और इसलिए, क्लाइंट वह है जो वह होने का दावा करता है। यदि समान नहीं है, तो क्लाइंट आर को भेजे बिना कनेक्शन समाप्त कर दिया जाता है।
  यदि वे समान हैं, तो ग्राहक को यह साबित करने के लिए कि वह ऊंट नहीं है, वह उसे उत्तर में अपनी पुष्टि भेजता है:
  R = H( A, M, K )
  ग्राहक उसी तरह से गणना करता है कि R अपनी गणना K के उपयोग से करता है, और इसकी तुलना सर्वर से प्राप्त करता है।

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

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

हालांकि, अगर साइट को जेएस के बिना काम करने की आवश्यकता नहीं है (उदाहरण के लिए, फॉलबैक बिल्कुल भी संभव नहीं है, तो यह बहुत जटिल है, हम डेवलपर्स के समय और बलों को "खींच" नहीं करते हैं), तो इस तरह की योजना को लागू करना अधिक उचित लगता है: बाहर निकलने के बाद फ़ील्ड फॉर्म में बिल्कुल भी नहीं हैं। लॉगिन फ़ील्ड से, पासवर्ड फ़ील्ड को कुछ समय के लिए ब्लॉक किया जाता है, और ajax के बगल में एक स्पिनर तैयार किया जाता है। सर्वर से उपयोगकर्ता नाम के लिए नमक प्राप्त करने के बाद, पासवर्ड फ़ील्ड अनलॉक किया गया है और आप पासवर्ड दर्ज कर सकते हैं।
जेएस को गणना के लिए समय देने के लिए अलगाव की भावना आवश्यक है। फिर भी, बड़ी संख्या के साथ बहुत सारे गणित हैं। जब मैंने SRP-3 पर SHA1 (पांच साल पहले) का उपयोग करते हुए इस सवाल की जांच की, तो 512-बिट कुंजियों का उपयोग करके पासवर्ड की पुष्टि करने के लिए गणना के लिए 30 सेकंड तक बहुत धीमी गति से निकला। इस स्थिति में, संपूर्ण ब्राउज़र UI [विशेष रूप से IE6;)] पूरे गणना समय के लिए अवरुद्ध है। समाधान निरंतरताओं का उपयोग करके गणना की जा सकती है (सेटटाइमआउट के माध्यम से स्लाइस में गणना शुरू करना), (कॉल के बीच के संदर्भ को संरक्षित करना) या फ्लैश / जावा में गणना करना। इसके अलावा, जावा कंप्यूटिंग गति के दृष्टिकोण से बेहतर है, और फ्लैश - उपयोगकर्ता द्वारा पहुंच की संभावना के दृष्टिकोण से।

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

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

जेएस पर तैयार एसआरपी कार्यान्वयन लिंक पर पाए जा सकते हैं:

• "क्या चल रहा है" के अध्ययन के लिए एसआरपी जावास्क्रिप्ट डेमो जेएस में दोनों पक्षों का कार्यान्वयन। SHA1 का उपयोग करता है, जो निश्चित रूप से, जीवित प्रणालियों में उपयोग नहीं किया जा सकता है ।
• Django बैकएंड के साथ GoogleCode पर SRP-JS
• जावास्क्रिप्ट क्रिप्टो लाइब्रेरी

आप इस विषय पर और अधिक पढ़ सकते हैं:

• स्टैनफोर्ड एसआरपी होमपेज
• विकिपीडिया में SRP
• RFC2945 SRP-3 का वर्णन (पदावनत)
• IEEE P1363.2: पासवर्ड-आधारित सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी , जिसमें SRP का वर्णन है
• डिफी-हेलमैन एलगोरिदम
• असतत लघुगणक