एन्कोडिंग, एस्केपिंग और हैशिंग

एन्कोडिंग एन्क्रिप्शन नहीं है, और यह संपीड़न नहीं है

एन्कोडिंग से डेटा लिखने का तरीका बदल जाता है। एन्क्रिप्शन बदलता है कि इसे कौन पढ़ सकता है। संपीड़न से यह बदल जाता है कि यह कितनी जगह लेता है। ये तीन अलग-अलग नौकरियां हैं, और Base64 केवल पहला काम करता है - बुरी तरह से, यदि आप अन्य दो में से किCAक की उम्मीद कर रहे थे।

Base64 एक समय में तीन बाइट्स लेता है और उन्हें 64-प्रतीक वर्णमाला से खींचे गए चार वर्णों के रूप में फिर से लिखता है। तीन बाइट्स वाले चार वर्णों का मतलब है कि आउटपुट हमेशा इनपुट से लगभग 33% बड़ा होता है, साथ ही पैडिंग भी। यह अस्तित्व में है क्योंकि बुनियादी ढांचे का एक बड़ा हिस्सा - ईमेल हेडर, HTTP हेडर, JSON स्ट्रिंग मान, URL, XML विशेषताएँ - टेक्स्ट के लिए डिज़ाइन किया गया था और मनमाने बाइट्स को व्यवस्थित या अस्वीकार करता है। Base64 वह एडाप्टर है जो आपको टेक्स्ट-आकार वाले पाइप के माध्यम से बाइट्स पुश करने देता है।

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

btoa() क्यों टूटता है, और यह दो अलग-अलग तरीकों से टूटता है

ब्राउज़र आपको btoa() और atob() देता है, और वे आधुनिक टेक्स्ट API से पुराने हैं। btoa को "बाइनरी स्ट्रिंग्स" पर परिभाषित किया गया है: स्ट्रिंग्स जिसमें प्रत्येक कोड इकाई एक बाइट है, 0 से 255 तक। पाठ वह नहीं है.

पहली असफलता ज़ोरदार है. btoa("世界") पर कॉल करें और आपको एक InvalidCharacterError मिलता है, क्योंकि U+4E16 एक बाइट में फिट नहीं होता है। जोरदार विफलताएं अच्छी तरह की होती हैं - आप उन्हें तुरंत नोटिस करते हैं और समाधान की तलाश में लग जाते हैं।

दूसरी विफलता मौन है, और वह वह है जो उत्पादन तक पहुँचती है। अक्षर é U+00E9 है, जो एक बाइट में फिट बैठता है। तो btoa("café") खुशी से लौटता है, é को एकल बाइट 0xE9 के रूप में एन्कोडिंग करता है। लेकिन UTF-8 में é दो बाइट्स है, 0xC3 0xA9। आपके द्वारा अभी-अभी तैयार किया गया Base64, पृथ्वी पर हर दूसरे सिस्टम में, किसी ऐसी चीज़ को डीकोड करता है जो आपका टेक्स्ट नहीं है। आपको कुछ सप्ताह बाद पता चलेगा कि डेटाबेस में कोई नाम प्रतिस्थापन वर्ण में कब बदल गया है।

समाधान यह है कि टेक्स्ट को बाइट्स के रूप में मानना ​​बंद कर दिया जाए और इसे स्पष्ट रूप से परिवर्तित किया जाए। TextEncoder UTF-8 बाइट्स उत्पन्न करता है; उनको एन्कोड करें। टेक्स्टडिकोडर बाइट्स को वापस टेक्स्ट में बदल देता है, और इसे { fatal: true } के साथ बनाने से यह U+FFFD को चुपचाप प्रतिस्थापित करने के बजाय अमान्य अनुक्रमों पर फेंक देता है, इसलिए एक डिकोड जो संभवतः सही नहीं हो सकता, प्रशंसनीय दिखने वाली बकवास को वापस करने के बजाय विफल हो जाता है। यह वह पाइपलाइन है जिसका उपयोग यह टूलकिट करता है, यही कारण है कि इमोजी, निशान और दाएं से बाएं स्क्रिप्ट को बिल्कुल गोल-गोल घुमाता है।

1. TextEncoder के साथ टेक्स्ट को बाइट्स में कन्वर्ट करें - कभी भी स्ट्रिंग में इंडेक्स न करें।
2. बाइट्स को Base64 पर एन्कोड करें।
3. रिवर्स करने के लिए: Base64 को बाइट्स में डिकोड करें, फिर बाइट्स को fatal: true के साथ UTF-8 के रूप में डिकोड करें।
4. यदि UTF-8 चरण विफल हो जाता है, तो पेलोड बाइनरी है, टेक्स्ट नहीं। दिखावा करने के बजाय इसे हेक्स के रूप में दिखाएं।

Base64 बनाम Base64url, और पैडिंग प्रश्न

मानक Base64 अपने अंतिम दो प्रतीकों के रूप में + और / का उपयोग करता है। दोनों URL में अर्थपूर्ण हैं: + को क्वेरी स्ट्रिंग्स में एन्कोडेड स्पेस के रूप में पढ़ा जा सकता है, और / एक पथ विभाजक है। तो RFC 4648 एक दूसरे वर्णमाला, Base64url को परिभाषित करता है, जो इसके स्थान पर - और _ को प्रतिस्थापित करता है। जेडब्ल्यूटी इसका उपयोग करते हैं, जैसा कि अधिकांश टोकन प्रारूप और कई APआई करते हैं।

पैडिंग दूसरा वैरिएबल है। मानक Base64 पैड = के साथ इसलिए आउटपुट लंबाई हमेशा चार का गुणज होती है। Base64url आमतौर पर पैडिंग को हटा देता है, क्योंकि URL में = स्वयं एक अजीब वर्ण है और लंबाई को अंकगणितीय रूप से पुनर्प्राप्त किया जा सकता है। एक डिकोडर जो पैडिंग पर जोर देता है वह पूरी तरह से मान्य JWT सेगमेंट को अस्वीकार कर देगा।

व्यावहारिक सलाह: आपके डिकोडर को दोनों अक्षरों को स्वीकार करना चाहिए और गायब पैडिंग को सहन करना चाहिए, क्योंकि आपको जो सौंपा गया है उस पर आप शायद ही कभी नियंत्रण कर पाते हैं। आपके एनकोडर को यह स्पष्ट होना चाहिए कि वह क्या उत्सर्जित करता है, क्योंकि प्राप्तकर्ता को संभवतः इसकी परवाह होती है। यहां Base64 उपयोगिता बिल्कुल यही करती है - यह किसी भी उचित चीज़ को स्वीकार करती है और आपको वही चुनने देती है जो यह उत्पादित करती है।

encodeURI और encodeURIComponent: एक वाक्य में अंतर

दोनों प्रतिशत-एनकोड UTF-8 का उपयोग करके करते हैं। वे केवल इस बात में भिन्न हैं कि वे किन पात्रों को अकेला छोड़ते हैं, और वह अंतर पूरी कहानी है: encodeURIComponent आरक्षित सीमांकक से बच जाता है, encodeURI नहीं।

आरक्षित सीमांकक वे वर्ण हैं जो URL को इसकी संरचना देते हैं: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. encodeURI मानता है कि आपने इसे URL दिया है जो पहले से ही सही ढंग से संरचित है और इसे उसी तरह रहना चाहिए, इसलिए यह उन्हें संरक्षित करता है - यह https:// को https%3A%2F%2F में नहीं बदलेगा। encodeURIComponent मानता है कि आपने इसे एक टुकड़ा सौंपा है जिसे एक स्लॉट में छोड़ा जा रहा है, इसलिए यह उनसे बच जाता है, यह सुनिश्चित करते हुए कि टुकड़ा अपने स्लॉट से बाहर नहीं निकल सकता है।

इससे उत्पन्न होने वाला बग पूरी तरह से यांत्रिक है। a&b=c का खोज मान लें। इसे एनकोडयूआरआई के साथ एनकोड करें और इसे ?q=a&b=c के रूप में जोड़ें, और आपने चुपचाप दो पैरामीटर बना लिए हैं: q अब केवल "a" है, और एक भटका हुआ b=c सामने आया है। इसे encodeURIComponent के साथ एनकोड करें और आपको ?q=a%26b%3Dc, एक पैरामीटर, सही मान मिलता है। बग का वही वर्ग एक तैयार किए गए मान को आपके कोड द्वारा बनाए गए URL में पैरामीटर इंजेक्ट करने देता है - यही कारण है कि "मूल्यों के लिए घटक प्रपत्र का उपयोग करें" एक सुरक्षा नियम है, न कि केवल शुद्धता।

प्रपत्र एन्कोडिंग एक तीसरा नियम है जो दूसरे जैसा दिखता है। एप्लिकेशन/x-www-form-urlencoded किसी स्पेस को %20 के बजाय + के रूप में लिखता है। यदि आप किसी फॉर्म बॉडी को सादे decodeURIComponent के साथ डीकोड करते हैं, तो डेटा में प्रत्येक प्लस चिह्न एक स्थान बन जाता है। प्रत्येक खोज बॉक्स जिसने "C++" को "C" में बदल दिया है, यह बग है।

HTML इकाइयां, और उन्हें insideHTML से डिकोड करना एक बुरी आदत क्यों है

HTML के लिए बचना संकीर्ण और अच्छी तरह से समझा गया है: & &amp; बन जाता है, < &lt; बन जाता है, > &gt; बन जाता है, और विशेषता मानों के अंदर " और ' को भी भागने की जरूरत है। पांच अक्षर। इससे अधिक बचना - प्रत्येक उच्चारण अक्षर को एक नामित इकाई में बदलना - अनिश्चित चरित्र एन्कोडिंग के दिनों के लिए एक समाधान था, और अब वैकल्पिक स्टाइल है सुरक्षा के बजाय.

डिकोडिंग वह जगह है जहां बुरी आदत रहती है। प्रत्येक उत्तर में दिखाई देने वाली एक-पंक्ति युक्ति स्ट्रिंग को एक अलग तत्व के आंतरिक HTML में निर्दिष्ट करना और उसके टेक्स्टकंटेंट को वापस पढ़ना है। यह काम करता है, और यह एक ख़राब विचार है। आपने HTML पार्सर को अविश्वसनीय इनपुट सौंप दिया है, जो इससे वास्तविक DOM नोड्स बनाता है। उस स्ट्रिंग में एक <img src=x onerror=...> एक वास्तविक छवि तत्व बन जाता है जिसमें एक वास्तविक त्रुटि हैंडलर संलग्न होता है; यदि उस उपवृक्ष को कभी भी दस्तावेज़ में डाला जाता है, तो वह चलता है। यह आपके डेटा को भी चुपचाप नष्ट कर देता है: इनपुट में टैग राउंड-ट्रिपिंग के बजाय गायब हो जाते हैं, क्योंकि पार्सर ने उन्हें टेक्स्ट के बजाय मार्कअप के रूप में व्याख्या की है।

इकाइयों को ठीक से डिकोड करने के लिए किसी पार्सर की आवश्यकता नहीं होती है: संदर्भ से मिलान करें, तालिका में नाम देखें, या संख्यात्मक संदर्भ के लिए अंकगणित करें। यह कुछ दर्जन लाइनें हैं, यह कुछ भी निष्पादित नहीं कर सकती है, और यह ईमानदारी से गोल-गोल घूमती है। यह टूलकिट इसे इस तरह से करता है, यही कारण है कि इकाई डिकोडर में एक स्क्रिप्ट टैग चिपकाने से आपको एक स्क्रिप्ट टैग दिखाई देता है।

हैश चुनना, और इसे तय करने वाले तीन प्रश्न

एक क्रिप्टोग्राफ़िक हैश किसी भी इनपुट को एक निश्चित-लंबाई वाले डाइजेस्ट में बदल देता है, जैसे कि एक ही डाइजेस्ट के साथ दो इनपुट ढूंढना असंभव होना चाहिए। वह संपत्ति वह है जो एक डाइजेस्ट को डेटा के लिए खड़ा होने देती है - एक हस्ताक्षर, एक अखंडता जांच, या एक सामग्री पते में।

पहला प्रश्न: क्या आप दुर्घटना से रक्षा कर रहे हैं या किसी विरोधी से? दूषित डाउनलोड से बचाव के लिए चेकसम को केवल यादृच्छिक फ़्लिप को पकड़ने की आवश्यकता होती है; CRC32 ठीक है. एक डाइजेस्ट जिससे टकराने से एक हमलावर को फायदा हो सकता है, उसे एक हैश की आवश्यकता होती है जो अभी भी खड़ा है। यही अंतर है कि SHA-1 केवल "पुराना" नहीं है।

SHA-1 ठोस रूप से टूट गया है। 2017 में SHAttered कार्य ने समान SHA-1 डाइजेस्ट के साथ दो अलग-अलग PDF फ़ाइलें तैयार कीं। 2020 में, "SHA-1 एक शैम्बल्स है" ने एक चुने हुए-उपसर्ग टकराव का प्रदर्शन किया - मजबूत और कहीं अधिक खतरनाक संस्करण, क्योंकि यह एक हमलावर को दो सावधानीपूर्वक निर्मित ब्लॉब्स के बजाय दो अर्थपूर्ण रूप से अलग-अलग दस्तावेज़ों से टकराने देता है। यदि किसी सिस्टम की सुरक्षा SHA-1 टकराव प्रतिरोध पर टिकी हुई है, तो वह सुरक्षा समाप्त हो जाती है। SHA-1 इस टूलकिट में रहता है क्योंकि git ऑब्जेक्ट ID और विरासत API हस्ताक्षरों की एक लंबी पूंछ अभी भी इसका उपयोग करती है, और आपको उन मानों को पुन: उत्पन्न करने में सक्षम होने की आवश्यकता है। किसी मूल्य को पुन: प्रस्तुत करना उस पर निर्भर रहने के समान नहीं है।

दूसरा प्रश्न: क्या इनपुट एक पासवर्ड है? यदि हां, तो इनमें से कोई भी उत्तर नहीं है। SHA-256 को तेज़ बनाने के लिए डिज़ाइन किया गया है, और पासवर्ड के लिए तेज़ बिल्कुल गलत है: इसका मतलब है कि आपके डेटाबेस वाला एक हमलावर प्रति सेकंड अरबों अनुमान लगाने की कोशिश कर सकता है। पासवर्ड को प्रति-उपयोगकर्ता नमक के साथ जानबूझकर धीमी, मेमोरी-हार्ड फ़ंक्शन की आवश्यकता होती है - Argon2id, scrypt, या bcrypt। यह कोई अति सूक्ष्म अंतर नहीं है; पासवर्ड के लिए SHA-256 का उपयोग करना सबसे आम गंभीर हैशिंग गलती है।

तीसरा प्रश्न: क्या आपको कुंजीयुक्त डाइजेस्ट की आवश्यकता है? यदि आप किसी संदेश को फ़िंगरप्रिंट करने के बजाय प्रमाणित कर रहे हैं, तो आप HMAC चाहते हैं, न कि एक खाली हैश। किसी रहस्य को जोड़ना और उसे हैश करना लंबाई-विस्तार हमलों के विरुद्ध एक क्लासिक स्वयं-लक्ष्य है; HMAC मौजूद है क्योंकि वह निर्माण जितना दिखता है उससे कहीं अधिक कठिन है।

बाकी सभी चीजों के लिए - एक फ़ाइल, एक सामग्री पता, एक अखंडता विशेषता को फ़िंगरप्रिंट करना - SHA-256 समझदार डिफ़ॉल्ट है, और SHA-512 व्यापक डाइजेस्ट देते हुए 64-बिट हार्डवेयर पर अक्सर तेज़ होता है।

यहाँ हैश ब्राउज़र से क्यों आते हैं?

इस टूलकिट में डाइजेस्ट की गणना ब्राउज़र के स्वयं के Web Crypto कार्यान्वयन, SubtleCrypto द्वारा की जाती है, न कि इस साइट से भेजे गए JavaScript द्वारा। यह एक जानबूझकर किया गया विकल्प है: ब्राउज़र के कार्यान्वयन का ऑडिट किया जाता है, रखरखाव किया जाता है, और आमतौर पर अनुकूलित मूल कोड के रूप में चलाया जाता है। पेज बंडल में हस्तलिखित SHA-256 बिना किसी लाभ के विश्वास करने लायक अधिक कोड है।

इसका एक प्रत्यक्ष परिणाम है। Web Crypto केवल एक सुरक्षित संदर्भ में प्रदर्शित होता है, जिसका अर्थ है https:// या लोकलहोस्ट। इस पेज को सादे HTTP पर LAN पते पर खोलें और crypto.subtle अपरिभाषित होगा, इसलिए हैश उपयोगिता आपको चुपचाप विफल होने या किसी कमजोर चीज़ को प्रतिस्थापित करने के बजाय स्पष्ट रूप से बताएगी।

वही तर्क UUID जनरेटर को संचालित करता है। crypto.randomUUID() भी सुरक्षित-संदर्भ-केवल है, इसलिए जहां यह अनुपलब्ध है, टूलकिट crypto.getRandomValues() पर वापस आ जाता है - जो अभी भी वही क्रिप्टोग्राफ़िक रूप से सुरक्षित स्रोत है - और संस्करण और वैरिएंट बिट्स को स्वयं सेट करता है। यह कभी नहीं करेगा कि Math.random() पर वापस आ जाए। यह एक तेज़ गैर-क्रिप्टोग्राफ़िक PRNG है जिसकी आंतरिक स्थिति को इसके आउटपुट के थोड़े समय से पुनर्प्राप्त किया जा सकता है, और पहचानकर्ताओं को सत्र कुंजी और पासवर्ड-रीसेट लिंक में पदोन्नत होने की दुर्भाग्यपूर्ण आदत है। यदि कोई सुरक्षित स्रोत मौजूद नहीं है, तो यह टूल कुछ भी उत्पन्न नहीं करता है और बताता है कि क्यों।

आप जो चिपकाते हैं उसका क्या होता है

• प्रत्येक रूपांतरण, हैश, डिकोड और अंतर आपके ब्राउज़र टैब में चलता है। सर्वर पर कोई इनपुट अपलोड, लॉग या संग्रहीत नहीं किया जाता है, क्योंकि पेज लोड होने के बाद कोई सर्वर शामिल नहीं होता है।
• हैश ब्राउज़र के अपने Web Crypto कार्यान्वयन से आते हैं, और UUID इसके क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक जनरेटर से आते हैं। न ही नेटवर्क कॉल शामिल है।
• आपके द्वारा टाइप किया गया कुछ भी स्थानीय संग्रहण या कुकी पर नहीं लिखा जाता है। पेज को पुनः लोड करने से वह ख़ारिज हो जाता है; टैब बंद करने से वह ख़ारिज हो जाता है।
• साइट-व्यापी विश्लेषण केवल कॉन्फ़िगर किए गए कैनोनिकल प्रोडक्शन होस्ट पर चलता है और गोपनीयता नीति में इसका खुलासा किया गया है; स्थानीय और पूर्वावलोकन होस्ट इसे अस्वीकार कर देते हैं। चिपकाए गए मान, टोकन, URL और फ़ाइल सामग्री को ToolAcre के स्वयं के विश्लेषण ईवेंट से बाहर रखा गया है। वर्तमान कॉन्फ़िगरेशन में विज्ञापन अक्षम है.
• उसने कहा: JWT या API कुंजी एक लाइव क्रेडेंशियल है। सुरक्षित आदत यह है कि इसे कभी भी किसी ऐसे वेब पेज पर पेस्ट न करें जिसे आपने नहीं लिखा है, भले ही इसके दावे कितने भी भरोसेमंद हों - इसमें यह भी शामिल है।

प्रश्न

सीमाएँ

• नामित HTML इकाई तालिका व्यावहारिक उपसमुच्चय को शामिल करती है - मार्कअप-महत्वपूर्ण वर्ण, टाइपोग्राफी, मुद्रा, तीर, गणित, ग्रीक और लैटिन-1 - सभी 2,231 HTML5 नामित संदर्भ नहीं। अज्ञात नामों की सूचना दी जाती है और अनुमान लगाने की बजाय बिल्कुल वैसा ही छोड़ दिया जाता है जैसा लिखा गया है।
• इकाई डिकोडिंग के लिए अंतिम अर्धविराम की आवश्यकता होती है। HTML5 एक के बिना मुट्ठी भर विरासत संदर्भों को सहन करता है, लेकिन उन्हें सही ढंग से डिकोड करना आसपास के मार्कअप संदर्भ पर निर्भर करता है, जो एक स्टैंडअलोन टेक्स्ट टूल में नहीं होता है।
• हैशिंग और UUID जेनरेशन को एक सुरक्षित संदर्भ (https:// या लोकलहोस्ट) की आवश्यकता होती है क्योंकि Web Crypto अन्यथा उजागर नहीं होता है। टूल कमजोर कार्यान्वयन को प्रतिस्थापित करने के बजाय इसकी रिपोर्ट करता है।
• केवल SHA-1, SHA-256, SHA-384 और SHA-512 उपलब्ध हैं, क्योंकि SubtleCrypto इन्हें लागू करता है। MD5 पसंद के साथ-साथ आवश्यकता से भी अनुपस्थित है।
• यहां कोई HMAC, कोई कुंजी व्युत्पत्ति और कोई एन्क्रिप्शन नहीं है। उन्हें कुंजी प्रबंधन की आवश्यकता है, जिसे इंटरनेट पर आपके द्वारा पाया गया कोई पेज नहीं संभालना चाहिए।
• सब कुछ आपके डिवाइस की मेमोरी द्वारा सीमित है, क्योंकि यह सब एक ब्राउज़र टैब में चलता है। इनपुट सीमित हैं - प्रति उपयोगिता कुछ मेगाबाइट - और टूल फ़्रीज़ होने के बजाय बड़े आकार के काम से इंकार कर देता है।