डाइजेस्ट और बेसिक ऑथेंटिकेशन में क्या अंतर है?

Question

डाइजेस्ट और बेसिक ऑथेंटिकेशन में क्या अंतर है ?

Comments

java.boot.by/wcd-guide/ch05s03.html

— अखिलेश मणि

क्या डाइजेस्ट ऑटेथिकेशन के लिए यह आवश्यक है कि सर्वर को पासवर्ड पता हो या सत्यापन के लिए बैकएंड को डाइजेस्ट करना हो?

— मैसिमो

Answer 1

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

जबकि बेसिक ऑथेंटिकेशन नॉन-एनक्रिप्टेड बेस 64 एनकोडिंग का उपयोग करता है ।

इसलिए, बेसिक ऑथेंटिकेशन का आमतौर पर केवल वही उपयोग किया जाना चाहिए, जहां ट्रांसपोर्ट लेयर सिक्योरिटी जैसे कि https दिया जाता है।

देखें RFC-2617 सभी रक्तमय जानकारी के लिए।

Comments

कैसे बुनियादी प्रमाणीकरण एन्क्रिप्टेड नहीं है? मैंने इस वेबसाइट का उपयोग उपयोगकर्ता नाम और पासवर्ड डेटा base64decode.org

— Dot Freelancer

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

— एंडी

@ और क्या डाइजेस्ट ऑथेंटिकेशन और क्रिप्टोग्राफिक ऑथेंटिकेशन के बीच अंतर है? या वे एक ही बात का जिक्र कर रहे हैं? धन्यवाद।

— user224567893

@ और क्या मतलब है "साख को डिकोड करें"? हॉन्टेड क्रेडेंशियल्स को डिकोड नहीं किया जा सकता ...

— अलेक्जेंडर सुरफेल

सही, और मूल स्रोत हैशेड क्रेडेंशियल्स का उपयोग नहीं करते हैं, वे base64 एन्कोडेड हैं।

— एंडी

Answer 2

HTTP बेसिक एक्सेस ऑथेंटिकेशन

• चरण 1 : क्लाइंट सूचना के लिए अनुरोध करता है, जो यूजरनेम और पासवर्ड को सादा पाठ में सर्वर को भेजता है
• चरण 2 : सर्वर वांछित सूचना या त्रुटि के साथ प्रतिक्रिया करता है

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

पेशेवरों:

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

विपक्ष:

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

सारांश में - यदि आपके पास ग्राहकों का नियंत्रण है, या यह सुनिश्चित कर सकता है कि वे एसएसएल का उपयोग करते हैं, तो HTTP बेसिक एक अच्छा विकल्प है। एसएसएल की सुस्ती को केवल एक अनुरोध करने की गति से रद्द किया जा सकता है

मूल प्रमाणीकरण का सिंटैक्स

Value = username:password
Encoded Value =  base64(Value)
Authorization Value = Basic <Encoded Value> 
//at last Authorization key/value map added to http header as follows
Authorization: <Authorization Value>

क्रिप्टोग्राफिक परिणाम उत्पन्न करने के लिए HTTP डाइजेस्ट एक्सेस ऑथेंटिकेशन डाइजेस्ट एक्सेस ऑथेंटिकेशन हैशिंग (यानी पाचन को छोटे टुकड़ों में काटे जाने के तरीके) का उपयोग करता है। HTTP डाइजेस्ट एक्सेस प्रमाणीकरण प्रमाणीकरण का एक अधिक जटिल रूप है जो निम्नानुसार काम करता है:

• चरण 1 : एक क्लाइंट एक सर्वर के लिए एक अनुरोध भेजता है
• चरण 2 : सर्वर एक विशेष कोड (जिसे कहा जाता है) के साथ प्रतिक्रिया करता हैअस्थायी रूप सेयानी एन umber केवल एक बार उपयोग किया जाता है ), एक और स्ट्रिंग जो दायरे (एक हैश) का प्रतिनिधित्व करता है और क्लाइंट को प्रमाणित करने के लिए कहता है
• चरण 3 : ग्राहक इस नॉन्स और यूज़रनेम, पासवर्ड और दायरे के एन्क्रिप्टेड संस्करण के साथ प्रतिक्रिया करता है (एक हैश)
• चरण 4 : यदि ग्राहक हैश उपयोगकर्ता नाम, पासवर्ड और दायरे के अपने हैश से मेल खाता है, या नहीं तो त्रुटि के साथ सर्वर अनुरोधित सूचना पर प्रतिक्रिया देता है।

पेशेवरों:

• किसी उपयोगकर्ता नाम या पासवर्ड को सर्वर में नहीं भेजा जाता है, जो एक गैर-एसएसएल कनेक्शन को HTTP बेसिक अनुरोध से अधिक सुरक्षित बनाता है जो एसएसएल पर नहीं भेजा जाता है। इसका मतलब है कि एसएसएल की आवश्यकता नहीं है, जो प्रत्येक कॉल को थोड़ा तेज करता है

विपक्ष:

• प्रत्येक कॉल के लिए, क्लाइंट को 2 को बनाना चाहिए, जिससे यह प्रक्रिया HTTP बेसिक से थोड़ी धीमी हो जाएगी
• HTTP डाइजेस्ट एक मानव-में-मध्य सुरक्षा हमले के लिए असुरक्षित है, जिसका मूल अर्थ है कि इसे हैक किया जा सकता है
• HTTP डाइजेस्ट मजबूत पासवर्ड एन्क्रिप्शन के उपयोग को रोकता है, जिसका अर्थ है कि सर्वर पर संग्रहीत पासवर्ड हैक किए जा सकते हैं

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

यदि आपके पास अपने ग्राहकों पर नियंत्रण नहीं है, लेकिन वे एसएसएल के बिना मूल प्रमाणीकरण करने का प्रयास कर सकते हैं, जो डाइजेस्ट की तुलना में बहुत कम सुरक्षित है।

RFC 2069 डाइजेस्ट एक्सेस ऑथेंटिकेशन सिंटैक्स

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:Hash2)

RFC 2617 डाइजेस्ट एक्सेस ऑथेंटिकेशन सिंटैक्स

Hash1=MD5(username:realm:password)
Hash2=MD5(method:digestURI)
response=MD5(Hash1:nonce:nonceCount:cnonce:qop:Hash2)
//some additional parameters added 

स्रोत और उदाहरण

पोस्टमैन में निम्नानुसार दिखता है:

ध्यान दें:

• बेसिक और डाइजेस्ट योजनाओं प्रमाणीकरण एक उपयोगकर्ता नाम और एक गुप्त का उपयोग कर के लिए समर्पित कर रहे हैं।
• बियरर योजना प्रमाणीकरण एक टोकन का उपयोग करने के लिए समर्पित है।

Comments

आपके वेब सर्वर पर क्या आप सभी http अनुरोधों के लिए https को पुनर्निर्देशित नहीं कर सकते, भले ही आपके पास ग्राहकों का नियंत्रण न हो?

— 10cool

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

— 10cool

क्यों, डाइजेस्ट के साथ, आप डेटाबेस में संग्रहीत करने से पहले अपना पासवर्ड एन्क्रिप्ट नहीं कर सकते हैं, और जब इसे बाहर निकालते हैं, तो इसे डिक्रिप्ट करते हैं?

— पैपीरो

यद्यपि चयनित उत्तर प्रश्न के अधिक निकट है, मुझे यह उत्तर पसंद है क्योंकि यह हमारे लिए असम्बद्ध लोगों के लिए पक्ष और विपक्ष देता है।

— कोडर

@ 10cool एक बार जब आप http से वेबसाइट को हिट करते हैं, तो बहुत देर हो चुकी होती है ... दुर्भाग्य से। उपयोगकर्ता: पास को पहले से ही तार पर स्पष्ट भेजा गया है, भले ही आप httpS के बाद पुनर्निर्देशित किए गए हों।

— जुलिएन

Answer 3

आइए हम दो HTTP प्रमाणीकरण Wireshark(भेजे गए या प्राप्त पैकेट का विश्लेषण करने के लिए टूल) का उपयोग करने के बीच अंतर देखते हैं ।

1. Http बेसिक ऑथेंटिकेशन

जैसे ही क्लाइंट सही उपयोगकर्ता नाम में टाइप करता है : पासवर्ड , जैसा कि वेब-सर्वर द्वारा अनुरोध किया गया है, वेब-सर्वर डेटाबेस में जांच करता है यदि क्रेडेंशियल सही हैं और संसाधन तक पहुंच देता है।

यहां बताया गया है कि पैकेट कैसे भेजे और प्राप्त किए जाते हैं:

पहले पैकेट में ग्राहक संसाधन पर POST विधि का उपयोग करके क्रेडेंशियल भरते हैं - lab/webapp/basicauth। HTTP प्रतिक्रिया कोड 200 ओके के साथ सर्वर को वापस करते हैं , अर्थात, उपयोगकर्ता नाम: पासवर्ड सही थे।

अब, Authorizationशीर्ष लेख में यह दिखाया गया है कि यह बेसिक ऑथराइजेशन है जिसके बाद कुछ रैंडम स्ट्रिंग है। यह स्ट्रिंग क्रेडेंशियल (कोलन सहित ) का एन्कोडेड (बेस 64) संस्करण है admin:aadd।

२। Http डाइजेस्ट प्रमाणीकरण (आरएफसी 2069)

अब तक हमने देखा है कि बेसिक ऑथेंटिकेशन नेटवर्क पर प्लेनटेक्स्ट में यूजरनेम: पासवर्ड भेजता है । लेकिन डाइजेस्ट ऑथ हश एल्गोरिथ्म का उपयोग करके पासवर्ड का एक एचएएच भेजता है ।

यहां ग्राहक द्वारा किए गए अनुरोधों और सर्वर से प्रतिक्रिया दिखाने वाले पैकेट हैं।

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

इसके बाद के संस्करण में Authorization, responseस्ट्रिंग के मूल्यों का उपयोग कर गणना की जाती है Username, Realm, Password, http-method, URIऔर Nonceछवि में दिखाया गया है:

(कॉलन शामिल हैं)

इसलिए, हम देख सकते हैं कि डाइजेस्ट ऑथेंटिकेशन अधिक सुरक्षित है क्योंकि इसमें हैशिंग (एमडी 5 एन्क्रिप्शन) शामिल है, इसलिए पैकेट स्निफर टूल पासवर्ड को सूँघ नहीं सकता है, हालांकि बेसिक ऑथेंट में सटीक पासवर्ड विंडसर पर दिखाया गया था।

Comments

यह स्वीकृत उत्तर होना चाहिए क्योंकि यह चार्ट के लिए अधिक जानकारीपूर्ण और यश है।

— mak

लेकिन वायरशर्क में आप केवल http प्रोटोकॉल का उपयोग करके पैकेट सूँघ रहे हैं? यदि आप https प्रोटोकॉल का उपयोग कर रहे हैं तो क्या होगा?

— JohnRDOrazio

यह वायरशर्क द्वारा तय नहीं किया गया है कि क्या Http या Https को सूँघना है। यह वेब-सर्वर है जो प्रोटोकॉल के साथ कॉन्फ़िगर किया गया है।

— BoRRis

बकवास। मूल प्रामाणिक केवल HTTPS से अधिक उपयोग किया जाना है। तो असली तुलना HTTP पर HTTPS बनाम Digest Auth पर बेसिक ऑथेंटिक है। आजकल वेबसाइटें अपने सभी ट्रैफ़िक को एन्क्रिप्ट कर रही हैं, इसलिए आप HTTPS पर बेसिक ऑथेंट का उपयोग कर सकते हैं।

— जिली

Answer 4

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

डाइजेस्ट एक्सेस ऑथेंटिकेशन क्रिप्टोग्राफ़िक परिणाम उत्पन्न करने के लिए हैशिंग विधियों का उपयोग करता है

Comments

बेस 64 एनकोडिंग क्रिप्टोग्राफिक नहीं है।

— थॉमस सोबिक