उपयोगकर्ता नाम और पासवर्ड से HTTP Basic प्रमाणीकरण हेडर जेनरेट करें, पेस्ट करने योग्य curl कमांड प्राप्त करें, और मौजूदा Basic टोकन को क्रेडेंशियल में वापस डिकोड करें।
एक HTTP Basic प्रमाणीकरण हेडर बनाएँ, या एक को डिकोड करें। उपयोगकर्ता नाम और पासवर्ड दर्ज करें ताकि आपको Authorization हेडर, कच्चा base64 टोकन और एक curl कमांड मिले जिसे आप सीधे टर्मिनल में पेस्ट कर सकें। नीचे दिया गया डिकोडर मौजूदा टोकन को उलट देता है।
मौजूदा टोकन डिकोड करें
सब कुछ आपके ब्राउज़र में गणना किया जाता है और कुछ भी प्रेषित नहीं होता। फिर भी, किसी भी वेब पेज पर, इसमें शामिल उत्पादन क्रेडेंशियल पेस्ट करने से बचें।
HTTP Basic प्रमाणीकरण वास्तव में कैसे काम करता है
तंत्र
Basic प्रमाणीकरण, जिसे RFC 7617 में परिभाषित किया गया है, HTTP योजना है। क्लाइंट उपयोगकर्ता नाम और पासवर्ड को कोलन से जोड़ता है, परिणाम को base64 में एन्कोड करता है, और उसे एक हेडर में भेजता है:
Authorization: Basic YWxpY2U6czNjcjN0
जब कोई सर्वर क्रेडेंशियल चाहता है तो वह 401 Unauthorized के साथ WWW-Authenticate: Basic realm="..." हेडर के साथ उत्तर देता है, और ब्राउज़र अपना मूल लॉगिन डायलॉग दिखाता है। कोई हैंडशेक नहीं, कोई नॉन्स नहीं और कोई समाप्ति नहीं — हर अनुरोध वही हेडर ले जाता है।
Base64 एन्क्रिप्शन नहीं है
यह वह बिंदु है जिसे हर किसी को आत्मसात करना चाहिए। Base64 एक प्रतिवर्ती ट्रांसपोर्ट एन्कोडिंग है जिसमें कोई कुंजी और कोई रहस्य नहीं है। जो कोई भी हेडर देखता है वह इसे तुरंत डिकोड कर सकता है, जो बिल्कुल वही है जो इस पेज का डिकोडर करता है। इसलिए Basic auth अकेले शून्य गोपनीयता प्रदान करता है और इसका उपयोग केवल HTTPS पर किया जाना चाहिए, जहाँ TLS पूरे अनुरोध की रक्षा करता है। सादे HTTP पर यह पासवर्ड को स्पष्ट टेक्स्ट में भेजने के बराबर है।
कोलन नियम
उपयोगकर्ता नाम में कोलन नहीं हो सकता, क्योंकि पहला कोलन अलगावकर्ता है। पासवर्ड में जितने चाहें हो सकते हैं — एक डिकोडर पहले वाले पर विभाजित करता है और बाकी को पासवर्ड मानता है। यदि आपके उपयोगकर्ता नाम को वास्तव में कोलन की आवश्यकता है, तो Basic auth उपयोगी नहीं है और आपको एक अलग योजना की आवश्यकता है।
वर्ण एन्कोडिंग
मूल विनिर्देश ASCII के बाहर किसी भी चीज़ के बारे में अस्पष्ट था, जिसने ऐतिहासिक रूप से गैर-ASCII पासवर्ड को क्लाइंट और सर्वर के बीच टूटने का कारण बनाया। RFC 7617 ने charset="UTF-8" पैरामीटर जोड़ा ताकि सर्वर अपनी अपेक्षा बता सके, और व्यवहार में हर आधुनिक स्टैक UTF-8 का उपयोग करता है। यह उपकरण base64 से पहले UTF-8 बाइट्स में एन्कोड करता है, जो वर्तमान ब्राउज़र व्यवहार से मेल खाता है।
यह अभी भी कहाँ समझदारी है
Basic auth आंतरिक नेटवर्क पर मशीन-टू-मशीन कॉल के लिए, nginx या Apache के पीछे स्टेजिंग वातावरण की त्वरित सुरक्षा के लिए, उन CI जॉब्स के लिए जिन्हें सरल क्रेडेंशियल की आवश्यकता होती है, और API कुंजियों के परिवहन के लिए एक उचित विकल्प बना हुआ है जहाँ कुंजी उपयोगकर्ता फ़ील्ड में जाती है और पासवर्ड खाली छोड़ा जाता है या x जैसे प्लेसहोल्डर पर सेट किया जाता है। कई भुगतान और मेल API ठीक वही पैटर्न उपयोग करते हैं।
यह सार्वजनिक साइट पर अंतिम-उपयोगकर्ता लॉगिन के लिए एक खराब विकल्प है। कोई लॉगआउट नहीं है, ब्राउज़र सत्र के लिए क्रेडेंशियल कैश करता है, डायलॉग को स्टाइल नहीं किया जा सकता, और प्रति सत्र मल्टी-फैक्टर प्रमाणीकरण या रेट लिमिटिंग जोड़ने का कोई तरीका नहीं है। इसके बजाय टोकन या सत्र-आधारित योजना का उपयोग करें।
व्यावहारिक सावधानियाँ
URL में एम्बेड किए गए क्रेडेंशियल — user:pass@example.com — अप्रचलित हैं और अधिकांश ब्राउज़र द्वारा अवरुद्ध या हटा दिए गए हैं, क्योंकि वे इतिहास, लॉग और रेफ़रर हेडर में लीक होते हैं। curl को -u user:pass पास करने से पासवर्ड आपके शेल इतिहास और प्रक्रिया सूची में भी रिकॉर्ड होता है, जहाँ मशीन पर अन्य उपयोगकर्ता इसे देख सकते हैं; -u user को प्राथमिकता दें और curl को प्रॉम्प्ट करने दें, या मान को पर्यावरण चर से पढ़ें।
अक्सर पूछे जाने वाले प्रश्न
क्या Basic auth सुरक्षित है?
केवल HTTPS पर। base64 एन्कोडिंग कोई सुरक्षा बिल्कुल नहीं देती — यह तुच्छ रूप से प्रतिवर्ती है। TLS के साथ क्रेडेंशियल ट्रांज़िट में अन्य अनुरोध डेटा की तरह संरक्षित होते हैं; बिना TLS के वे वास्तव में स्पष्ट टेक्स्ट हैं।
अगर यह एन्क्रिप्शन नहीं है तो base64 क्यों?
इसका उद्देश्य परिवहन सुरक्षा है, गोपनीयता नहीं। Base64 यह गारंटी देता है कि क्रेडेंशियल में केवल हेडर-सुरक्षित ASCII वर्ण हों, ताकि पासवर्ड में कोलन, रिक्त स्थान या गैर-ASCII बाइट हेडर को खराब न करे।
क्या उपयोगकर्ता नाम में कोलन हो सकता है?
नहीं। पहला कोलन उपयोगकर्ता नाम को पासवर्ड से अलग करता है, इसलिए उपयोगकर्ता नाम में कोलन क्रेडेंशियल को अस्पष्ट बनाता है। पासवर्ड में कितने भी कोलन हो सकते हैं।
मैं Basic auth से कैसे लॉगआउट करूँ?
कोई उचित तंत्र नहीं है। ब्राउज़र सत्र के लिए क्रेडेंशियल कैश करते हैं, और सामान्य उपाय ब्राउज़र बंद करना या एक विशेष एंडपॉइंट को 401 लौटाना है। यह सीमा एक कारण है कि Basic auth अंतिम-उपयोगकर्ता लॉगिन के लिए अनुपयुक्त है।
क्या टोकन समाप्त होता है?
कभी नहीं। वही हेडर तब तक वैध है जब तक पासवर्ड नहीं बदलता, जो इस बात का कारण है कि लीक हुआ Basic टोकन लीक हुए पासवर्ड जितना ही गंभीर है। यदि कोई उजागर हो तो क्रेडेंशियल घुमाएँ।
क्या मेरे क्रेडेंशियल कहीं भेजे जाते हैं?
नहीं। एन्कोडिंग और डिकोडिंग पूरी तरह आपके ब्राउज़र में चलती है। फिर भी, किसी भी वेब पेज पर वास्तविक उत्पादन क्रेडेंशियल कभी न पेस्ट करना एक अच्छा अभ्यास है।