डेवलपर टूल · JWT डिकोडर
JWE समझाया गया: क्यों एक एन्क्रिप्टेड JWT में पांच भाग होते हैं और कोई पढ़ने योग्य पेलोड नहीं होता है
· पेजभूमि
जेडब्ल्यूटी कूटलेखन डेटा-प्रारूप
कुछ टोकन में दो के बजाय चार बिंदु होते हैं और एक पेलोड JSON नहीं होता है। यह पोस्ट JWE कॉम्पैक्ट क्रमांकन की व्याख्या करती है, इसके पांच भागों में से प्रत्येक में क्या है, और कोई भी डिकोड-ओनली टूल अपने दावे क्यों नहीं दिखा सकता है।
चार बिंदु और एक पेलोड जो JSON नहीं है - वे चिह्न जो आप JWE धारण कर रहे हैं, न कि JWS
चार बिंदु और पांच खंड परिचित तीन-भाग वाले हस्ताक्षरित फॉर्म से एक अलग कॉम्पैक्ट लिफाफे का संकेत देते हैं। इसके मध्य बाइट्स को JWT दावों के रूप में पार्स करने का प्रयास बकवास पैदा करता है क्योंकि सामग्री सिफरटेक्स्ट है, न कि प्लेनटेक्स्ट JSON की Base64url वर्तनी।
ToolAcre डिकोडिंग से पहले सेगमेंट गिनती की जांच करता है। पांच भाग एक INVALID_JWT संदेश को ट्रिगर करते हैं जो JWE की पहचान करता है और बताता है कि डिक्रिप्शन कुंजी के बिना इस डिकोड-केवल मार्ग को दिखाने के लिए कुछ भी क्यों नहीं है। यह अस्पष्ट पार्स विफलता के बजाय एक सटीक सीमा है।
पाँच भाग - संरक्षित हेडर, एन्क्रिप्टेड कुंजी, इनिशियलाइज़ेशन वेक्टर, सिफरटेक्स्ट और प्रमाणीकरण टैग
कॉम्पैक्ट JWE भाग एक संरक्षित हेडर, एन्क्रिप्टेड-कुंजी सामग्री, एक प्रारंभिक मूल्य, सिफरटेक्स्ट और एक प्रमाणीकरण टैग का प्रतिनिधित्व करते हैं। प्रत्येक की एक अलग क्रिप्टोग्राफ़िक भूमिका होती है। अकेले खंड स्थिति दूसरे या चौथे फ़ील्ड को पढ़ने योग्य JWT पेलोड नहीं बनाती है।
एक डिकोडर कुछ बाइट्स को विभाजित और Base64url-डीकोड कर सकता है, लेकिन कच्चे बाइट्स डिक्रिप्शन नहीं हैं। उन्हें पाठ के रूप में प्रदर्शित करने से प्रतिस्थापन वर्ण या भ्रामक टुकड़े बन जाएंगे। सही कार्रवाई लिफाफे की पहचान करना और अधिकृत प्राप्तकर्ता कार्यान्वयन के लिए आगे बढ़ना है।
alg और enc - कुंजी प्रबंधन बनाम सामग्री एन्क्रिप्शन, और क्यों एक JWE हेडर दो एल्गोरिदम का नाम देता है
JWE हेडर में कुंजी प्रबंधन के लिए `alg` और सामग्री एन्क्रिप्शन के लिए `enc` हो सकता है। ये लेबल विभिन्न परिचालनों का वर्णन करते हैं। हस्ताक्षरित टोकन की तरह, हेडर मान ऐसे इनपुट होते हैं जो टोकन को मनमाने एल्गोरिदम का चयन करने की अनुमति के बजाय प्राप्तकर्ता नीति से मेल खाना चाहिए।
ToolAcre के तीन-भाग वाले एल्गोरिदम नोट JWE प्रसंस्करण को लागू नहीं करते हैं, और पांच-भाग वाली शाखा हेडर पार्सिंग से पहले बाहर निकल जाती है। इसलिए पेज विशेष एन्क्रिप्शन एल्गोरिदम प्रदर्शित या समर्थन नहीं करता है। समर्थित विकल्पों के लिए प्राप्तकर्ता लाइब्रेरी और जारीकर्ता अनुबंध से परामर्श लें।
सामग्री एन्क्रिप्शन कुंजियाँ - कैसे एक यादृच्छिक कुंजी पेलोड की सुरक्षा करती है और प्राप्तकर्ता के लिए स्वयं लपेटी जाती है
सामग्री एन्क्रिप्शन आमतौर पर एक उत्पन्न सामग्री-एन्क्रिप्शन कुंजी का उपयोग करता है, जबकि एन्क्रिप्टेड-कुंजी खंड प्राप्तकर्ता व्यवस्था के तहत उस कुंजी को संप्रेषित या प्राप्त करता है। पृथक्करण पेलोड बाइट्स को सामग्री सिफर के साथ संरक्षित करने की अनुमति देता है जबकि कुंजी-प्रबंधन नीति यह निर्धारित करती है कि कुंजी को कौन पुनर्प्राप्त कर सकता है।
यह वैचारिक मॉडल बताता है कि प्लेनटेक्स्ट पुनर्प्राप्ति के लिए कॉम्पैक्ट स्ट्रिंग का होना अपर्याप्त क्यों है। आवश्यक प्राप्तकर्ता रहस्य और नीति को स्वतंत्र रूप से उपयोग करने योग्य निर्देशों के रूप में एन्कोड नहीं किया गया है। एक सार्वजनिक डिकोडर उनका आविष्कार नहीं कर सकता है और उपयोगकर्ताओं को कभी भी निजी डिक्रिप्शन कुंजियों को किसी सामान्य पेज में पेस्ट करने के लिए नहीं कहना चाहिए।
जब जारीकर्ता JWE चुनते हैं - तो ऐसे दावे जो ग्राहक या मध्यस्थों से गोपनीय रहने चाहिए
जारीकर्ता एन्क्रिप्शन का चयन कर सकते हैं जब दावों को धारकों या मध्यस्थों से गोपनीय रहना चाहिए जो हस्ताक्षरित टोकन देख सकते हैं। यह सही विकल्प है या नहीं यह खतरे के मॉडल, प्रमुख वितरण और परिचालन आवश्यकताओं पर निर्भर करता है। दावा सामग्री को न्यूनतम करना अनावश्यक डेटा को एन्क्रिप्ट करने की तुलना में अभी भी बेहतर हो सकता है।
एन्क्रिप्शन प्राधिकरण, सत्यापन या मेटाडेटा चिंताओं को समाप्त नहीं करता है। प्राप्तकर्ता को संरक्षित सामग्री को प्रमाणित करना होगा और डिक्रिप्शन के बाद टोकन नीति लागू करनी होगी। अधिकृत प्राप्तकर्ता द्वारा प्राप्त पठनीय परिणाम प्रत्येक सेवा के लिए स्वचालित रूप से स्वीकार्य नहीं है।
हेडर पर डिकोडिंग क्यों रुक जाती है - पेलोड सिफरटेक्स्ट है, इसलिए केवल कुंजी धारक ही इसे पढ़ सकता है
डिकोडिंग संरचना पर रुक जाती है क्योंकि संभावित पेलोड खंड सिफरटेक्स्ट है। ToolAcre जानबूझकर मनमाने बाइनरी को JSON के रूप में प्रस्तुत करने से बचता है और इसके बजाय एक विशिष्ट संदेश देता है। यह उपयोगकर्ताओं को अन्यथा वैध एन्क्रिप्टेड लिफाफे में अस्पष्टता को भ्रष्टाचार के रूप में व्याख्या करने से रोकता है।
यदि आप इच्छित प्राप्तकर्ता हैं, तो उपयुक्त कुंजी और एल्गोरिदम के साथ कॉन्फ़िगर किए गए नियंत्रित सॉफ़्टवेयर का उपयोग करें। यदि आप नहीं हैं, तो अपठनीय पेलोड अपेक्षित सुरक्षा संपत्ति है। कोई भी पैडिंग ट्रिक या वैकल्पिक कैरेक्टर डिकोडर डिक्रिप्शन की जगह नहीं ले सकता।
इसमें क्या शामिल नहीं है - नेस्टेड JWT जिन पर हस्ताक्षर किए जाते हैं और फिर एन्क्रिप्ट किए जाते हैं, और JWE JSON क्रमबद्धता
नेस्टेड निर्माण सामग्री पर हस्ताक्षर कर सकते हैं और फिर परिणाम को एन्क्रिप्ट कर सकते हैं, या अन्यथा एक परिभाषित प्रोफ़ाइल के तहत परतों को जोड़ सकते हैं। JWE में कॉम्पैक्ट पांच-भाग स्ट्रिंग से परे भी प्रतिनिधित्व हैं। ToolAcre उन मामलों पर कार्रवाई नहीं करता है, और यह आलेख केवल हेडर लेबल से नेस्टिंग का अनुमान नहीं लगाता है।
समस्या निवारण से पहले आपका सिस्टम किस परत की अपेक्षा करता है, इसका दस्तावेजीकरण करें। अन्यथा कोई टीम सिफरटेक्स्ट पर हस्ताक्षर सत्यापन का प्रयास कर सकती है या किसी आंतरिक टोकन को डीकोड कर सकती है जिसे प्रमाणित नहीं किया गया है। चयनित JOSE लाइब्रेरी को स्पष्ट नीति के तहत ऑर्डर संभालने दें।
टेकअवे: एक डिकोडर केवल वही दिखा सकता है जो एन्क्रिप्टेड नहीं है - ToolAcre JWT डिकोडर एक हस्ताक्षरित टोकन का हेडर और पेलोड दिखाता है; JWE का पेलोड डिज़ाइन के अनुसार अपठनीय है
एक डिकोडर केवल वही दिखा सकता है जो एन्क्रिप्टेड नहीं है। ToolAcre तीन-भाग हस्ताक्षरित इनपुट के हेडर और पेलोड से JSON पढ़ता है, जबकि पांच खंड एक व्याख्यात्मक रोक का कारण बनते हैं। यह अंतर डिकोड-ओनली इंटरफ़ेस को यह दिखाने से रोकता है कि उसमें प्राप्तकर्ता क्षमता है।
खंड गणना का उपयोग रूटिंग सुराग के रूप में करें, विश्वास परिणाम के रूप में नहीं। तीन पठनीय भागों को अभी भी हस्ताक्षर सत्यापन की आवश्यकता है; पाँच एन्क्रिप्टेड भागों को अधिकृत डिक्रिप्शन और सत्यापन की आवश्यकता होती है। किसी भी मामले में विज़ुअल आउटपुट अकेले दावों को प्रमाणित नहीं करता है या पहुंच प्रदान नहीं करता है।