डाइजेस्ट ऑथेंटिकेशन क्या है?

101

सादे पाठ के रूप में क्रेडेंशियल्स भेजने के अलावा बेसिक प्रमाणीकरण से डाइजेस्ट प्रमाणीकरण कैसे भिन्न होता है?

digest-authentication

@Gumbo द्वारा यहीं महान विवरण: stackoverflow.com/a/5288679/591487

— अकार्बनिक

कुछ आप कभी भी उपयोग करना चाहिए। पारगमन में पासवर्ड की रक्षा नहीं करता है और सर्वर को सादे में पासवर्ड संग्रहीत करने की आवश्यकता होती है।

— कोडइंचौस

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

— रस्टेक्स

जवाबों:

179

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

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

यह इस हैश कुंजी को सर्वर और उपयोगकर्ता नाम के साथ भेजता है ताकि प्रमाणित करने का प्रयास किया जा सके।

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

RFC2617 में डाइजेस्ट ऑथेंटिकेशन को मानकीकृत किया गया है । विकिपीडिया पर इसका एक अच्छा अवलोकन है :

आप इसे इस तरह से सोच सकते हैं:

ग्राहक अनुरोध करता है
क्लाइंट को सर्वर से नॉनस और 401 प्रमाणीकरण अनुरोध वापस मिल जाता है
क्लाइंट निम्न प्रतिक्रिया सरणी (उपयोगकर्ता नाम, दायरे, जनरेट_मेड 5_की (नॉन, यूज़रनेम, रियलिटी, यूआरआई, पासवर्ड_गिवेन_बीस_सोउटर)) को भेजता है, (हाँ, यह बहुत सरल है
सर्वर उपयोगकर्ता नाम और क्षेत्र लेता है (प्लस यह जानता है कि URI ग्राहक अनुरोध कर रहा है) और यह उस उपयोगकर्ता नाम के लिए पासवर्ड देखता है। तब यह अपने स्वयं के संस्करण का निर्माण करता है और जनरेट करता है__dd___ (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
यह generate_md5 () के आउटपुट की तुलना करता है जो इसे भेजे गए क्लाइंट के साथ मिलता है, यदि वे मेल खाते हैं तो क्लाइंट ने सही पासवर्ड भेजा है। यदि वे भेजे गए पासवर्ड से मेल नहीं खाते तो गलत था।

— इयान सी।
स्रोत

अच्छी व्याख्या। उपयोगकर्ता नाम और विंडोज उपयोगकर्ता के लिए pwd हैं? वे कहाँ से उत्पन्न होते हैं?

— SoftwareGeek

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

— इयान सी।

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

— रेमन डे क्लेन

यदि यूजरनेम और पासवर्ड के डाइजेस्ट हैश को सादे पासवर्ड के बजाय db में संग्रहित किया जाता है, तो यह अभी भी डाइजेस्ट ऑइंटमेंट का उपयोग करना संभव है @RemonteKlein

— karakays

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

— logo_writer

क्रेडेंशियल्स का एक हैश तार पर भेजा जाता है।

HA1 = MD5(username:realm:password)

इस विषय पर विकिपीडिया का एक उत्कृष्ट लेख है

— फिलिप फूरी
स्रोत

क्लाइंट से सर्वर तक? क्या आप कृपया सहभागिता के लिए कदम प्रदान कर सकते हैं? विकिपीडिया लेख अच्छा है लेकिन मुझे बेहतर स्पष्टीकरण या उदाहरण की आवश्यकता है।

— SoftwareGeek

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

— फिलिप फूरी

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

— क्रिस ओकले
स्रोत

यह डाइजेस्ट प्रमाणीकरण के लिए स्पष्टीकरण है, जहां पासवर्ड सादे पाठ में नहीं भेजा गया है (जो मूल

— प्रमाण के