डेवलपर टूल · Base64 एनकोडर और डिकोडर
HTTP बेसिक प्रमाणीकरण हेडर को Base64 के साथ कैसे बनाया और डीकोड किया जाता है
· यह काम किस प्रकार करता है
Base64 सुरक्षा
प्राधिकरण: मूल शीर्षलेख केवल उपयोगकर्ता नाम: पासवर्ड है जो Base64 के माध्यम से चलता है। यह पोस्ट दिखाती है कि मान कैसे बनाया जाता है, अनुरोध लॉग से किसी को कैसे डिकोड किया जाता है, और एन्कोडिंग कुछ भी क्यों नहीं छिपाती है।
401 जो क्रेडेंशियल सही होने के बावजूद कायम रहता है - एक हेडर मान जो एक सूक्ष्म रूप से गलत स्ट्रिंग को डिकोड करता है
एक HTTP API 401 को अनधिकृत लौटाता है और एक Authorization: Basic हेडर की अपेक्षा करता है। मान योजना शब्द बेसिक, एक स्थान और एक Base64 स्ट्रिंग है। एक अनुपलब्ध उपसर्ग, एक एन्कोडेड उपसर्ग, या एक ध्यान न दी गई नई पंक्ति दृश्य उपयोगकर्ता नाम और पासवर्ड सही दिखने पर भी सर्वर को प्राप्त होने वाली चीज़ों को बदल देती है।
उस स्ट्रिंग को डीकोड करें और यह उपयोगकर्ता नाम: पासवर्ड (शाब्दिक रूप से दो के बीच कोलन) पढ़ता है। बाइट्स उपयोगकर्ता नाम: पासवर्ड को UTF-8 एन्कोड किया गया है, फिर Base64 एन्कोड किया गया है, जिससे हेडर मान उत्पन्न होता है। यदि क्रेडेंशियल व्यवस्थापक हैं: s3cret, UTF-8 बाइट्स 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII अक्षर प्लस कोलन) हैं, Base64 एन्कोडिंग उत्पन्न होती है YWRtaW46czNjcmV0, और हेडर प्राधिकरण है: बेसिक YWRtaW46czNjcmV0।
RFC 7617 से नुस्खा: 'उपयोगकर्ता:पास', UTF-8, Base64 - सटीक चरण और कोलन की भूमिका
यह पूर्ण HTTP मूल प्रमाणीकरण योजना है जो RFC 7617 में परिभाषित है। यह सरल, मानकीकृत है, और अपने आप में कोई सुरक्षा प्रदान नहीं करता है: हेडर पढ़ने वाला कोई भी व्यक्ति पासवर्ड पढ़ने के लिए इसे तुरंत डिकोड कर सकता है। यही कारण है कि बेसिक प्रमाणीकरण के लिए HTTPS अनिवार्य है। एन्कोडिंग परिवहन आवश्यकता है, सुरक्षा सुविधा नहीं। पासवर्ड UTF-8 बाइट्स के रूप में यात्रा करता है, किसी भी अन्य डेटा के समान; Base64 केवल HTTP प्रोटोकॉल में उपयोग किया जाने वाला नोटेशन है।
यदि नेटवर्क लॉग से बेसिक हेडर को डीकोड करने की आवश्यकता है, तो प्रक्रिया सीधी है: स्ट्रिप बेसिक, Base64 डीकोड शेष, और आपके पास उपयोगकर्ता नाम: पासवर्ड है। कोलन उपयोगकर्ता नाम और पासवर्ड के बीच सीमांकक है। RFC 7617 निर्दिष्ट करता है कि क्रेडेंशियल उपयोगकर्ता-ID: पासवर्ड हैं, और पहला कोलन विभाजक है। यदि पासवर्ड में कोलन है, तो दूसरा कोलन पासवर्ड में सिर्फ एक और अक्षर है। बृहदान्त्र संरचनात्मक है क्योंकि रिसीवर को एक स्पष्ट सीमा की आवश्यकता होती है। यह डिकोडिंग के बाद पहले कोलन की खोज करता है; इससे पहले की हर चीज़ उपयोगकर्ता की पहचान करती है और इसके बाद की हर चीज़ पासवर्ड है। इसलिए एक गायब कोलन एक विकृत क्रेडेंशियल जोड़ी को इंगित करता है, Base64-वर्णमाला समस्या को नहीं।
कारगर उदाहरण: एन्कोडिंग एडमिन:s3cret और लॉग से हेडर को डिकोड करना - दोनों दिशाएँ, जिसमें एक ट्रेलिंग-न्यूलाइन बग भी शामिल है
यदि उपयोगकर्ता नाम एडमिन है और पासवर्ड पास: वर्ड है, तो क्रेडेंशियल एडमिन: पास: वर्ड हैं, जो YWRtaW46cGFzczp3b3Jk को एन्कोड करता है। इसे डिकोड करते समय, उपयोगकर्ता नाम एडमिन और पासवर्ड पास:वर्ड देते हुए, केवल पहले कोलन पर विभाजित होना चाहिए। प्रत्येक कोलन पर विभाजन करने से पासवर्ड गलत तरीके से विभाजित हो जाएगा। RFC 7617 में वर्णसेट पैरामीटर बताता है कि क्रेडेंशियल UTF-8 एन्कोडेड हैं। इसका मतलब है कि उपयोगकर्ता नाम या पासवर्ड में गैर-ASCII वर्ण Base64 एन्कोडिंग से पहले UTF-8 बाइट्स में परिवर्तित हो जाते हैं।
यदि उपयोगकर्ता नाम कैफ़े (ई उच्चारण) है, तो UTF-8 बाइट्स 0x63 0x61 0x66 0xC3 0xA9 हैं (ASCII अक्षरों के लिए चार बाइट्स और उच्चारण वर्ण के लिए दो), और पूर्ण क्रेडेंशियल कैफ़े: पासवर्ड में कैफ़े के लिए बाइट्स हैं, फिर कोलन बाइट 0x3A, फिर पासवर्ड। Base64 आउटपुट सभी बाइट्स को ईमानदारी से एन्कोड करता है। डिकोडर को डिकोड किए गए बाइट्स को UTF-8 टेक्स्ट के रूप में समझना आना चाहिए, न कि लैटिन-1 के रूप में।
कोलन, रिक्त स्थान और गैर-ASCII वाले पासवर्ड - पहला कोलन क्यों विभाजित होता है, और वर्णसेट पैरामीटर किसके लिए है
एक कारगर उदाहरण: admin:s3cret से प्रारंभ करें। में बदलो UTF-8 बाइट्स: a=0x61, d=0x64, m=0x6D, i=0x69, n=0x6E, :=0x3A, s=0x73, 3=0x33, c=0x63, r=0x72, e=0x65, t=0x74. दशमलव में:(97, 100, 109, 105, 110, 58, 115, 51, 99, 114, 101, 116). Base64 इन्हें एन्कोड करता है 12 bytes: तीन के चार समूहों में समूहित करें (चार Base64 वर्णों के चार समूह बनाएं)।
एन्कोडेड मान YWRtaW46czNjcmV0 है। प्राधिकरण शीर्षलेख प्राधिकरण है: मूल YWRtaW46czNjcmV0। पासवर्ड साइड में उस पहली सीमा को हिलाए बिना एक और कोलन शामिल हो सकता है। रिक्त स्थान और गैर-ASCII पाठ भी तब बचे रहते हैं जब दोनों सहकर्मी पाठ एन्कोडिंग पर सहमत होते हैं। ToolAcre अपने द्वारा उत्सर्जित UTF-8 बाइट्स को सत्यापित कर सकता है, लेकिन एक पुराना सर्वर जो एक अलग वर्णसेट की अपेक्षा करता है वह Base64 परिवर्तन के बाहर एक इंटरऑपरेबिलिटी समस्या बनी हुई है।
TLS के बिना यह सुरक्षित क्यों नहीं है - डिकोडिंग हेडर देखने वाले किसी भी व्यक्ति को पासवर्ड दिखाता है
प्राप्त हेडर को डीकोड करने के लिए, बेसिक स्ट्रिप करें, बाइट्स वापस पाने के लिए Base64 डीकोड YWRtaW46czNjcmV0, एडमिन प्राप्त करने के लिए UTF-8 टेक्स्ट के रूप में व्याख्या करें: s3cret, उपयोगकर्ता नाम और पासवर्ड निकालने के लिए पहले कोलन पर विभाजित करें। एक सामान्य गलती है इको से न्यूलाइन का पीछे हटना। यदि इको एडमिन:s3cret | चलाएँ Unix शेल में Base64, इको डिफ़ॉल्ट रूप से न्यूलाइन जोड़ता है, इसलिए admin:s3cret को न्यूलाइन (13 bytes के बजाय 12) के साथ एन्कोड करें।
Base64 आउटपुट अलग है: YWRtaW46czNjcmV0Cg== (पैडिंग और अतिरिक्त अक्षर)। इस मान के साथ प्राधिकरण शीर्षलेख विफल हो जाएगा क्योंकि पासवर्ड में न्यूलाइन वर्ण शामिल है। फिक्स का उपयोग इको -n या पाइप के माध्यम से प्रिंटफ या टूल के माध्यम से किया जाता है जो नई लाइनें नहीं जोड़ता है। Base64 एनकोडर और डिकोडर इससे बचता है: आप जो पेस्ट करते हैं उसे बिल्कुल एनकोड करता है, कोई छिपी हुई नई लाइनें नहीं। TLS परिवहन खतरे को बदलता है, क्रेडेंशियल प्रारूप को नहीं। संरक्षित कनेक्शन के अंदर हेडर को बाकी अनुरोध के साथ एन्क्रिप्ट किया जाता है; एक बार जब सॉफ्टवेयर इसे लॉग या प्रदर्शित करता है, तो Base64 मान इसे डीकोड करने में सक्षम किसी भी व्यक्ति के लिए पुन: प्रयोज्य क्रेडेंशियल को फिर से उजागर करता है। प्रत्येक अवलोकन बिंदु पर पुनर्निर्देशन अभी भी मायने रखता है।
सामान्य गलतियाँ - इको से एक नई पंक्ति, एक गायब 'बेसिक' उपसर्ग, और मान को डबल-एन्कोडिंग
एक अन्य त्रुटि में मूल उपसर्ग गायब है। प्राधिकरण हेडर मान अकेले Base64 मान्य नहीं है; यह योजना का नाम (बेसिक या बियरर या अन्य) है जिसके बाद स्थान और फिर क्रेडेंशियल है। कुछ सिस्टम YWRtaW46czNjcmV0 को क्रेडेंशियल के रूप में पहचानने में विफल रहते हैं लेकिन बेसिक YWRtaW46czNjcmV0 के साथ सफल होते हैं। यदि 401 को डीबग किया जा रहा है, तो जांचें कि सर्वर प्राधिकरण हेडर को सही ढंग से पार्स कर रहा है या नहीं।
योजना HTTP मानक में केस-संवेदनशील है, लेकिन कई कार्यान्वयन केस-संवेदनशील हैं; API दस्तावेज़ की जाँच करें। डबल-एन्कोडिंग एक और विफलता मोड है। यदि Base64 एनकोड स्ट्रिंग जो पहले से ही Base64 एन्कोडेड है, तो आउटपुट अलग स्ट्रिंग है। YWRtaW46czNjcmV0 को एन्कोड करने से WVdkbWFXNDZjek5qY3JldA== (पूरी तरह से अलग) उत्पन्न होता है। कुछ सिस्टम गलती से दो बार एन्कोडिंग लागू कर सकते हैं: एक बार क्रेडेंशियल सेटअप के दौरान और दूसरी बार हेडर बनाते समय। शेल कमांड से एक नई लाइन को छोड़ना विशेष रूप से आसान है क्योंकि इसे Base64 के आसपास व्हाइटस्पेस के रूप में खारिज करने के बजाय क्रेडेंशियल के हिस्से के रूप में एन्कोड किया जा सकता है। परिणामी हेडर एक अतिरिक्त बाइट के साथ पासवर्ड को स्पष्ट रूप से डीकोड करता है, जिससे एक 401 उत्पन्न होता है जो सर्वर-साइड प्रमाणीकरण विफलता जैसा दिखता है।
इसमें क्या शामिल नहीं है - डाइजेस्ट और बियरर योजनाएं, और ब्राउज़र क्रेडेंशियल संकेत
डिकोडर Base64 की एकल परत की अपेक्षा करता है, इसलिए डबल-एन्कोडिंग बेमेल का कारण बनती है। यही कारण है कि Base64 फॉर्म (प्लेनटेक्स्ट नहीं) में क्रेडेंशियल मान लॉग करना भ्रमित करने वाला हो सकता है: यदि कोई एक बार डिकोडिंग लागू करता है, तो उन्हें उपयोगकर्ता नाम और पासवर्ड दिखाई देता है; यदि दो बार आवेदन करें, तो उन्हें अस्पष्टता दिखाई देती है। डाइजेस्ट प्रमाणीकरण (RFC 7616) और बियरर प्रमाणीकरण (OAuth टोकन के लिए) अलग-अलग योजनाओं का उपयोग करते हैं, प्रत्येक अलग-अलग क्रेडेंशियल प्रारूप के साथ।
डाइजेस्ट के लिए सर्वर को नॉन भेजने की आवश्यकता होती है, क्लाइंट को हैश की गणना करने के लिए, और हेडर में हैश प्लस उपयोगकर्ता नाम शामिल करने की आवश्यकता होती है, पासवर्ड की नहीं। बियरर आमतौर पर JSON वेब टोकन (JWT) होता है, जो Base64url एन्कोडेड होता है लेकिन उपयोगकर्ता नाम के साथ उपसर्ग नहीं होता है। बेसिक ऑथ दोनों की तुलना में सरल है लेकिन TLS के बिना पूरी तरह से असुरक्षित है क्योंकि क्रेडेंशियल हेडर में पढ़ने योग्य हैं। डाइजेस्ट और बियरर एक ही प्राधिकरण हेडर फ़ील्ड का उपयोग करते हैं लेकिन उनके मूल्यों को पूरी तरह से अलग अर्थ प्रदान करते हैं। ब्राउज़र क्रेडेंशियल संकेत बेसिक के शीर्ष पर उपयोगकर्ता-इंटरफ़ेस और कैशिंग व्यवहार जोड़ते हैं। यह आलेख उन प्रमाणीकरण प्रणालियों की तुलना करने के बजाय मूल क्रेडेंशियल पेलोड के निर्माण और निरीक्षण पर रुकता है।
टेकअवे: मूल प्रमाणीकरण Base64 है, सुरक्षा नहीं - कैसे Base64 एनकोडर और डिकोडर आपको कहीं भी क्रेडेंशियल भेजे बिना स्थानीय रूप से हेडर मान की जांच करने देता है
यदि API एकाधिक प्रमाणीकरण योजनाओं का समर्थन करता है, तो सबसे सुरक्षित उपलब्ध चुनें। Base64 एनकोडर और डिकोडर डिबग में मदद कर सकते हैं मूल प्रमाणीकरण विफलता: क्रेडेंशियल स्ट्रिंग (उपयोगकर्ता नाम और कोलन और पासवर्ड) पेस्ट करें, और टूल तुरंत Base64 मान उत्पन्न करता है। परिणाम की तुलना हेडर भेजने से करें, और बेमेल दिखाई देता है। इसके विपरीत, नेटवर्क लॉग से हेडर वैल्यू पेस्ट करें, बेसिक प्रीफ़िक्स स्ट्रिप करें, सर्वर ने क्या देखा यह देखने के लिए डीकोड करें।
सीखने के लिए, admin:s3cret पेस्ट करें और आउटपुट देखें, फिर Base64 कैसे बदलता है यह देखने के लिए पासवर्ड संशोधित करें। यह समझना कि हेडर कैसे बनाया गया, यह स्पष्ट करता है कि डिकोडिंग के लिए RFC प्रारूप को जानना आवश्यक क्यों है और कोलन संरचनात्मक तत्व क्यों है, Base64 नहीं। एक स्थानीय चेक में आविष्कृत क्रेडेंशियल का उपयोग किया जाना चाहिए, न कि उत्पादन से कॉपी किए गए लाइव पासवर्ड का। जोड़ी को एनकोड करें, आउटपुट को इनपुट पैनल में वापस ले जाएं, और इसे डीकोड करें। मिलान विराम चिह्न और सटीक अनुगामी वर्ण हेडर को कहीं भी भेजे जाने से पहले प्रतिनिधित्व को राउंड-ट्रिप साबित करते हैं।