Base64 decode करें

घटते क्रम में: कोई JWT, कोई Basic Auth हेडर, किसी Kubernetes secret का मान, किसी webhook का payload। इन चारों में से तीन क्रेडेंशियल हैं, और चौथे में आम तौर पर लोगों का डेटा होता है।

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

JWT में हेडर, payload और हस्ताक्षर होते हैं, बिंदुओं से अलग किए हुए, और हर हिस्सा URL-सुरक्षित Base64 में। पहले दो हिस्से JSON हैं और सीधे पढ़े जाते हैं; तीसरा हस्ताक्षर है और टेक्स्ट नहीं है, इसलिए उसे decode करने से काम की कोई चीज़ नहीं निकलती।

असुविधाजनक नतीजा यह है कि token की सामग्री गुप्त नहीं होती: जिसके पास वह है वह पढ़ सकता है कि वह किसका है, कब बेकार होगा और कौन-सी अनुमतियाँ बताता है। हस्ताक्षर उसे बदलने से रोकता है, पढ़ने से नहीं। इसलिए JWT के payload में निजी डेटा रखना उसे हर उस व्यक्ति के सामने रख देना है जो token देख ले।

Base64 की स्ट्रिंग में कोई वाक्य जितनी आसानी से बैठ सकता है, उतनी ही आसानी से कोई PNG, कोई PDF या कोई ZIP भी। उन बाइट को टेक्स्ट की तरह पढ़ने पर प्रतिस्थापन-चिह्न निकलते हैं, और बहुत से औज़ार वही लौटा देते हैं — जिससे लगता है कि Base64 टूटा हुआ था, जबकि वह पूरी तरह ठीक था।

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

JWT आख़िर के बराबर के चिह्न जान-बूझकर हटा देते हैं, क्योंकि URL-सुरक्षित Base64 का विनिर्देश इसकी छूट देता है। दूसरी ओर बहुत सी लाइब्रेरियाँ padding के बिना decode करने से मना कर देती हैं और ऐसी त्रुटि लौटाती हैं जो कुछ नहीं समझाती।

यह decoder ज़रूरत पड़ने पर उसे ख़ुद जोड़ लेता है, इसलिए हेडर से कॉपी किया हुआ token जैसा है वैसा पढ़ा जाता है। अगर आपका कोड ऐसे मान पर विफल हो रहा है जो यहाँ चल जाता है, तो वजह आम तौर पर यही होती है, और हल यह है कि लाइब्रेरी को देने से पहले उसे अगले चार के गुणक तक भर दीजिए।

मानक वर्णमाला `+` और `/` इस्तेमाल करती है; URL-सुरक्षित वाली `-` और `_`। यहाँ दोनों बिना पूछे मानी जाती हैं, क्योंकि किसी की चिपकाई हुई स्ट्रिंग पढ़ने के लिए यह जानना पहले से ज़रूरी नहीं होना चाहिए कि वह किस रूप में है।

उलटी दिशा में यह जानना ज़रूर काम आता है। अगर आप ऐसा मान बना रहे हैं जिसे किसी पते में सफ़र करना है और आप मानक वर्णमाला इस्तेमाल करते हैं, तो तिरछी लकीर path तोड़ देगी और plus स्पेस की तरह पढ़ा जाएगा: मान पहुँच तो जाएगा, पर बदला हुआ, और गड़बड़ी उस जगह से बहुत दूर दिखेगी जहाँ वह हुई थी।

ईमेल Base64 को 76 अक्षरों की पंक्तियों में तोड़ता है और PEM प्रमाणपत्र 64 की, क्योंकि उनके मानक ऐसा कहते हैं। इसलिए किसी `.pem` फ़ाइल से या किसी ईमेल के भीतर से कॉपी किया हुआ मान भीतर पंक्ति-विच्छेदों के साथ आता है।

उन्हें अनदेखा कर दिया जाता है, और साथ ही उन इक्के-दुक्के स्पेस को भी जो terminal से कॉपी करते समय आ जाते हैं। पहले कुछ साफ़ करने की ज़रूरत नहीं: अगर आपके चिपकाए में कुछ ऐसा है जो वर्णमाला का हिस्सा नहीं, तो आपको बता दिया जाता है कि दिक़्क़त क्या है, बजाय इसके कि आधा-अधूरा decode करके ऐसा नतीजा लौटाया जाए जो ठीक लगता है।

किसी स्ट्रिंग का decode हो जाना यह नहीं कहता कि उसकी सामग्री सही है। बेकार हो चुका JWT उतनी ही आसानी से पढ़ा जाता है जितना चालू वाला, और नक़ली हस्ताक्षर बिलकुल उसी तरह decode होता है जैसे असली, क्योंकि हस्ताक्षर जाँचने के लिए कुंजी चाहिए और यह पन्ना न वह रखता है न चाहता है।

यह पढ़ने के लिए है, भरोसा करने के लिए नहीं। अगर आपको यह जानना है कि token वैध है या नहीं, तो यह उसी तंत्र को बताना होगा जिसने उसे जारी किया; यह पन्ना जिस सवाल का जवाब देता है वह है कि उसमें लिखा क्या है — अलग सवाल, और आम तौर पर पहला सवाल।

अगर नतीजे में प्रश्नचिह्न वाले चौकोर दिखें तो बाइट वैध UTF-8 नहीं बनातीं। या तो वह binary डेटा है — फ़ाइल, टेक्स्ट नहीं — या टेक्स्ट किसी और encoding में लिखा गया था और अब UTF-8 की तरह पढ़ा जा रहा है।

हिंदी डेटा में इस दूसरी हालत का सबसे आम रूप UTF-8 बनाम Latin-1 नहीं है, बल्कि Kruti Dev या Chanakya जैसी फ़ॉन्ट-आधारित सामग्री है: वहाँ बाइट असल में ASCII हैं और देवनागरी सिर्फ़ फ़ॉन्ट की वजह से दिखती है। ऐसी स्ट्रिंग decode होने पर बेतरतीब रोमन अक्षर देती है, न कि प्रतिस्थापन-चिह्न — और यही उसे पहचानने का सबसे भरोसेमंद तरीक़ा है। ISCII वाला पुराना डेटा इसके उलट सीधे प्रतिस्थापन-चिह्न देता है।

Kubernetes का `Secret` अपने मान Base64 में रखता है, और यह बहुत लोगों को भ्रमित करता है: वह विश्राम में एन्क्रिप्टेड नहीं होता जब तक अलग से ऐसा सेट न किया जाए, और जिसे उस संसाधन को पढ़ने की अनुमति है वह एक ही क़दम में क्रेडेंशियल पढ़ लेता है।

इसलिए यह साफ़ रखना ज़रूरी है कि किसकी रक्षा कौन करता है। Base64 वहाँ इसलिए है कि binary मान YAML में समा जाएँ, उन्हें छिपाने के लिए नहीं। असली सुरक्षा क्लस्टर की अनुमतियाँ हैं और, ज़रूरत हो तो, विश्राम में encryption — और किसी ऑनलाइन औज़ार में चिपकाया गया `Secret` का मान एक ऐसी क्रेडेंशियल है जो क्लस्टर से बाहर निकल चुकी है।

इस साइट के सारे पन्नों में सबसे ज़्यादा क्रेडेंशियल और निजी डेटा इसी को मिलते हैं: नाम-पते वाले webhook payload, किसी व्यक्ति की पहचान बताने वाले token, कॉन्फ़िग के dump। चूँकि decoding पन्ने पर ही होती है, इनमें से कुछ भी हम तक नहीं पहुँचता।

यही वह बात है जो इस औज़ार को गंभीर आंतरिक नीति वाले माहौल में इस्तेमाल लायक़ बनाती है। जो सेवा दूर किसी सर्वर पर decode करती वह वह निजी डेटा पा चुकी होती और वह उसके लॉग में होता — और DPDP Act के तहत की जाने वाली बहुत सी सतर्कता ठीक इसी हालत से बचने के लिए है। नेटवर्क पैनल इसे एक मिनट में दिखा देता है।

Encode करने का अपना पन्ना है क्योंकि वह दूसरा क्षण है। जो encode कर रहा है वह कुछ जोड़ रहा है और उसे वर्णमाला तय करनी है; जो decode कर रहा है वह कुछ पढ़ रहा है जो उस तक पहुँचा है और उसे जानना है कि नतीजा टेक्स्ट न निकले तो क्या करें।

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