انکوڈنگ، ہیشنگ اور انکرپشن تین الگ چیزیں ہیں
اس صفحے سے متعلق تقریباً ہر غلط فہمی انہیں ایک دوسرے کا متبادل سمجھنے سے پیدا ہوتی ہے، اس لیے انہیں اچھی طرح الگ الگ سمجھ لینا فائدہ مند ہے۔
انکوڈنگ واپس پلٹائی جا سکتی ہے اور اس میں کوئی راز نہیں ہوتا۔ Base64 اس لیے ہے کہ بائنری ڈیٹا کو ان راستوں سے گزارا جا سکے جو صرف ٹیکسٹ قبول کرتے ہیں — ای میل اٹیچمنٹس، data URIs، JSON اسٹرنگز — ہر تین بائٹس کو چار حروف میں لکھ کر، اسی لیے نتیجہ ہمیشہ تقریباً ایک تہائی بڑا ہوتا ہے۔ کوئی کی (key) نہیں ہوتی۔ جو بھی یہ اسٹرنگ دیکھے وہ اسے ایک قدم میں ڈیکوڈ کر سکتا ہے، اس سائٹ پر بھی۔ Base64 سیکیورٹی نہیں، قابلِ ذکر پردہ پوشی نہیں، اور دیکھنے والے سے کچھ چھپانے کا طریقہ بھی نہیں۔ پرسنٹ انکوڈنگ URLs کے لیے اسی قسم کی چیز ہے، اور دوسرا عام بگ یہیں پایا جاتا ہے: query string میں جانے والی ایک ویلیو کو انکوڈ کرنا پورے بنے ہوئے URL کو صاف کرنے سے الگ عمل ہے، کیونکہ صرف پہلا عمل وہ &، =، ? اور / escape کرتا ہے جو URL کو اس کی ساخت دیتے ہیں۔ یہ غلط ہو جائے تو "Smith & Sons" سرور تک ایک ویلیو کے بجائے دو پیرامیٹرز بن کر پہنچتا ہے۔
ہیشنگ یک طرفہ ہے اور اس میں بھی کوئی کی نہیں ہوتی۔ ہیش کسی بھی ان پٹ سے ایک مقررہ لمبائی کا فنگر پرنٹ بناتا ہے، اور اسے واپس نہیں پلٹایا جا سکتا — اس لیے نہیں کہ وہ انکرپٹڈ ہے بلکہ اس لیے کہ معلومات ختم ہو چکی ہے۔ آپ صرف ان پٹس کا اندازہ لگا کر موازنہ کر سکتے ہیں، اور یہی بات MD5، SHA-1 اور SHA-256 کو پاس ورڈ محفوظ کرنے کے لیے غلط بناتی ہے: یہ تیز ہیں، ایک گرافکس کارڈ ایک سیکنڈ میں اربوں ہیش بنا لیتا ہے، اور ان کا چوری شدہ ٹیبل اسی رفتار سے کریک ہو جاتا ہے۔ پاس ورڈز کے لیے جان بوجھ کر سست، salt والا فنکشن چاہیے — bcrypt، scrypt یا Argon2۔ اس سے ہٹ کر، MD5 اور SHA-1 ایک اور وجہ سے بھی ٹوٹ چکے ہیں: اب ایک ہی ہیش والی دو مختلف فائلیں جان بوجھ کر بنائی جا سکتی ہیں، اس لیے دونوں میں سے کوئی یہ ثابت نہیں کر سکتا کہ فائل وہی ہے جس کی آپ کو توقع تھی، اگرچہ غلطی سے خراب ہونے والا ڈاؤن لوڈ پکڑنے کے لیے دونوں اب بھی ٹھیک ہیں۔
انکرپشن وہ ہے جس میں کی ہوتی ہے، اور ان میں سے کوئی ٹول یہ نہیں کرتا۔ یہ کوئی کمی نہیں۔ انکرپشن کو صحیح طرح کرنے کے لیے کی مینجمنٹ ضروری ہے، اور ویب پیج کی رکھنے کی غلط جگہ ہے۔
JWT سائن کیا جاتا ہے، انکرپٹ نہیں، اور لوگ اس بات پر بار بار دھوکا کھاتے ہیں۔ ٹوکن کا ہیڈر اور پے لوڈ Base64URL ہیں — جس کے پاس بھی ٹوکن ہو وہ انہیں پڑھ سکتا ہے، کسی کی کی ضرورت نہیں۔ سگنیچر کسی کو ٹوکن بدلنے سے روکتا ہے؛ پڑھنے سے روکنے کے لیے کچھ نہیں کرتا، اس لیے پے لوڈ میں کوئی خفیہ چیز نہیں ہونی چاہیے۔ اسی سے یہ نتیجہ نکلتا ہے کہ ٹوکن ڈیکوڈ کرنا اس کے بارے میں قطعاً کچھ ثابت نہیں کرتا: کوئی بھی جو چاہے کلیمز لکھ کر انہیں Base64 کر سکتا ہے۔ تصدیق کا مطلب ہے جاری کرنے والے کی کی سے سگنیچر دوبارہ حساب کرنا، اور یہ کام آپ کا سرور کرتا ہے، کسی ویب سائٹ کو یہ کی کبھی نہیں مانگنی چاہیے۔ اسی لیے ہمارا ڈیکوڈر تصدیق کا تاثر دینے سے انکار کرتا ہے، اور ان صورتوں کی نشاندہی کرتا ہے جو مسئلے کی علامت ہیں — ایکسپائر ہو چکا ٹوکن، ایسا ٹوکن جس کی ایکسپائری ہی نہ ہو، اور "none" الگورتھم، جو کوئی دلچسپ عجوبہ نہیں بلکہ ایک دستاویزی authentication bypass ہے۔
JSON میں نمبرز کی درستگی کی ایک حد ہے جس سے زیادہ تر فارمیٹرز خاموشی سے ٹکرا جاتے ہیں۔ خود JSON نمبر کے سائز پر کوئی حد نہیں لگاتا، مگر JavaScript نمبر 64-bit float ہوتا ہے، اس لیے مکمل اعداد صرف 9,007,199,254,740,991 تک درست رہتے ہیں۔ Twitter پوسٹ ID، Discord snowflake، 64-bit ڈیٹا بیس کی یا بینک اکاؤنٹ نمبر اس سے بڑا ہوتا ہے، اور اسے عام ایک لائن والے فارمیٹر — parse پھر stringify — سے گزارنے پر اس کے آخری ہندسے بدل جاتے ہیں۔ نتیجہ پھر بھی ایک معقول نمبر لگتا ہے، اور یہی بات اسے خطرناک بناتی ہے: 7205759403792793600 خاموشی سے 7205759403792793000 بن جاتا ہے۔ ہمارے JSON ٹولز وہی ہندسے دوبارہ لکھتے ہیں جو آپ نے پیسٹ کیے، اور بتاتے ہیں کہ انہیں کتنے نمبرز بچانے پڑے۔
UUID کا ورژن بتاتا ہے کہ وہ کیسے بنایا گیا، یہ نہیں کہ وہ کس چیز کی ضمانت دیتا ہے۔ کوئی بھی UUID کو رجسٹر نہیں کرتا اور نہ انفرادیت نافذ کرتا ہے؛ انفرادیت امکانی ہے، اور ورژن بتاتا ہے کہ بٹس کہاں سے آئے۔ ورژن 4 براؤزر کے کرپٹوگرافک جنریٹر سے 122 بٹس کی رینڈمنیس ہے، جس کی وجہ سے اس کا اندازہ نہیں لگایا جا سکتا اور یہ ری سیٹ لنکس، دعوتی کوڈز اور ہر خفیہ چیز کے لیے صحیح ہے — اور ڈیٹا بیس کی کے طور پر غلط، کیونکہ رینڈم کیز ترتیب شدہ انڈیکس میں بکھر کر اسے ٹکڑوں میں بانٹ دیتی ہیں۔ ورژن 7 شروع میں 48-bit ملی سیکنڈ ٹائم اسٹیمپ رکھتا ہے، اس لیے کیز آٹو انکریمنٹ انٹیجر کی طرح انڈیکس کے آخر میں جڑتی جاتی ہیں اور پھر بھی عالمی طور پر منفرد رہتی ہیں۔ اس کی قیمت یہ ہے کہ v7 UUID جس کے پاس بھی ہو اسے صاف بتا دیتا ہے کہ وہ ملی سیکنڈ تک کب بنایا گیا۔
جہاں براؤزر واقعی غلط ٹول ہے
ان تیرہ میں سے کوئی بھی کچھ کہیں نہیں بھیجتا۔ کوئی ریکوئسٹ نہیں جاتی، کچھ لاگ نہیں ہوتا، اور نیٹ ورک منقطع ہونے پر بھی صفحات کام کرتے رہتے ہیں — اسی لیے انہیں گاہکوں کے ریکارڈز سے بھرے API رسپانس یا ایسے ٹوکن پر استعمال کیا جا سکتا ہے جو آپ کسی کو ای میل نہ کریں۔ ان کے حق میں ایماندارانہ دلیل یہی ہے۔ اب ان کے خلاف ایماندارانہ دلیل۔
لائیو پروڈکشن سیکرٹ کسی ویب پیج میں پیسٹ کرنا ایسی عادت ہے جس سے بچنا بہتر ہے — اس صفحے سمیت۔ ہمارا پرائیویسی کا دعویٰ سچ ہے، مگر دعویٰ آپ کو تحفظ نہیں دیتا؛ کوڈ کا برتاؤ دیتا ہے، اور کسی بھی ویب پیج کے بارے میں واحد سمجھ داری کا رویہ بھروسا کرنے کے بجائے جانچنا ہے۔ جانچ مفت ہے: صفحہ لوڈ ہونے کے بعد انٹرنیٹ بند کریں اور دیکھیں کہ یہ ٹولز کام کرتے رہتے ہیں۔ جس ٹول کو سرور کی ضرورت ہوتی وہ رک جاتا۔ اور اگر کوئی کریڈینشل اب بھی درست ہے اور آپ اسے کسی ایسی جگہ پیسٹ کر چکے ہیں جس کی آپ جانچ نہیں کر سکتے، تو صحیح قدم اسے بدلنا (rotate کرنا) ہے، اس پر سوچ بچار کرنا نہیں۔ جو ٹوکن ابھی لائیو ہے اسے مقامی طور پر ڈیکوڈ کرنا — آپ کی پروگرامنگ زبان کا اپنا Base64 فنکشن، یا شیل میں دو لائنیں — کسی بھی ویب سائٹ سے بہتر طریقہ ہے، ہماری سمیت۔
اسکیما ویلیڈیشن۔ ہمارے JSON اور XML ٹولز چیک کرتے ہیں کہ دستاویز درست ساخت (well-formed) کی ہے، اور یہ اس سوال سے الگ ہے کہ وہ کسی اسکیما سے مطابقت رکھتی ہے یا نہیں۔ JSON Schema یا XSD کے مطابق ویلیڈیٹ کرنے کا مطلب ہے اسکیما فائل حاصل کر کے لاگو کرنا، اور یہ ایک نیٹ ورک ریکوئسٹ ہے جو یہ صفحات جان بوجھ کر کبھی نہیں بھیجتے۔ JSON Schema کے لیے ajv اور XSD اور DTD کے لیے xmllint استعمال کریں؛ دونوں مفت ہیں اور دونوں اس کام میں کسی بھی ویب پیج سے بہتر ہیں۔
کوئی بھی واقعی بڑی یا اسٹریم ہونے والی چیز۔ دستاویزات پوری کی پوری میموری میں رکھی جاتی ہیں، فارمیٹنگ کے دوران کبھی کبھی دو بار، اس لیے حد ٹیب کی ہے۔ چند میگابائٹ فوراً ہو جاتے ہیں، چند سو نہیں۔ jq کئی گیگابائٹ کی JSON فائل اسٹریم کر لیتا ہے جسے کوئی براؤزر نہیں کھولے گا، اور ripgrep پوری ریپوزٹری اس سے تیز سرچ کر لیتا ہے جتنی دیر میں آپ ایک فائل پیسٹ کریں۔ ہیشنگ میں یہی حد زیادہ سخت ہے: براؤزر کی کرپٹوگرافی میں incremental digest نہیں، اس لیے پوری فائل کو ایک ساتھ میموری میں سمانا ضروری ہے — DVD امیج فائل ناکام ہو جائے گی، جبکہ sha256sum، shasum یا certutil اسے بلا جھجک اسٹریم کر لیتے ہیں۔
آٹومیشن اور CI۔ یہ تب چلتے ہیں جب کوئی شخص کلک کرے۔ ریپوزٹری کی ہر فائل فارمیٹ کرنا، کسی fixture کے لیے دس ہزار UUID بنانا، یا پائپ لائن میں JSON چیک کرنا اسکرپٹ کا کام ہے: jq، xmllint، uuidgen، openssl اور base64 کمانڈ زیادہ تر مشینوں پر پہلے سے انسٹال ہیں۔
سائن کی گئی کسی بھی چیز کی تصدیق۔ سگنیچر کی تصدیق، سرٹیفکیٹ چینز اور ہر وہ چیز جس کے لیے پرائیویٹ کی چاہیے، آپ کے سرور پر کسی ایسی لائبریری سے ہونی چاہیے جس کی دیکھ بھال ہوتی ہو۔ یہ صفحہ آپ کو بتائے گا کہ ٹوکن کیا دعویٰ کرتا ہے؛ یہ کبھی نہیں بتائے گا کہ ٹوکن اصلی ہے، اور جو سائٹ آپ کی کی کے بغیر ایسا کر سکنے کا دعویٰ کرے اس پر بھروسا نہ کریں۔
ملتے جلتے ناموں والے ٹولز میں انتخاب
JSON فارمیٹر بمقابلہ JSON ویلیڈیٹر۔ ایک ہی پارسر، سوال الگ۔ فارمیٹر ایسی دستاویز پڑھنے اور اس کی شکل بدلنے کے لیے ہے جو پہلے سے پارس ہوتی ہو — انڈینٹ کریں، منیفائی کریں، بڑے نمبرز جوں کے توں رکھیں۔ ویلیڈیٹر ایسی دستاویز کے لیے ہے جو پارس نہیں ہوتی، اور اس کا آؤٹ پٹ ہے لائن، کالم، غلط حرف جس کے نیچے caret لگا ہو، اور یہ کہ چار عام وجوہات میں سے کون سی تھی۔ اگر آپ "Unexpected token" کو گھور رہے ہیں تو آپ کو ویلیڈیٹر چاہیے۔ یہی تقسیم XML فارمیٹر اور XML ویلیڈیٹر پر بھی لاگو ہوتی ہے۔
Base64 ڈیکوڈ بمقابلہ JWT ڈیکوڈر۔ JWT تین Base64URL حصوں پر مشتمل ہوتا ہے، اس لیے عام ڈیکوڈر آپ کو ٹکڑے دکھا دے گا۔ JWT صفحہ انہیں آپ کے لیے الگ کرتا ہے، JSON فارمیٹ کرتا ہے، expiry، issued-at اور not-before کلیمز کو Unix ٹائم اسٹیمپس سے آپ کے ٹائم زون کی اصل تاریخوں میں بدلتا ہے، رجسٹرڈ کلیمز پر لیبل لگاتا ہے، اور ایکسپائری اور "none" الگورتھم کے بارے میں خبردار کرتا ہے۔ Base64 بلاب کے لیے عام ڈیکوڈر اور ٹوکن کے لیے JWT صفحہ استعمال کریں۔
Base64 انکوڈ بمقابلہ URL انکوڈ۔ الگ الگ کام جو دونوں “محفوظ” ٹیکسٹ بناتے ہیں۔ Base64 کسی بھی بائٹس کو 33 فیصد اضافی سائز کی قیمت پر ٹیکسٹ میں بدلتا ہے، اور معیاری Base64 URL میں بالکل محفوظ نہیں — اس کے +، / اور = وہاں کوئی معنی رکھتے ہیں، اسی لیے Base64URL موجود ہے۔ پرسنٹ انکوڈنگ پڑھنے کے قابل ٹیکسٹ کو پڑھنے کے قابل ہی رہنے دیتی ہے اور صرف وہ escape کرتی ہے جو URL کو خراب کر دے، اور سرچ ٹرم، ای میل ایڈریس یا ری ڈائریکٹ ٹارگٹ کے لیے آپ کو یہی چاہیے۔ query string کے لیے پوری فائل انکوڈ کرنا عام طور پر اس بات کی علامت ہے کہ اسے request body ہونا چاہیے تھا۔
ہیش جنریٹر بمقابلہ UUID جنریٹر۔ ہیش اپنے ان پٹ سے نکلتا ہے، اس لیے ایک ہی ان پٹ ہمیشہ ایک ہی ویلیو دیتا ہے — یہی اسے فنگر پرنٹ بناتا ہے، جو ڈاؤن لوڈ کی تصدیق یا ایک جیسے مواد کی ڈپلیکیٹس ہٹانے کے لیے اچھا ہے۔ UUID تازہ رینڈمنیس ہے جس کا کسی چیز سے کوئی تعلق نہیں، اس لیے وہ کبھی دہرایا نہیں جاتا۔ اگر آپ کو ایک ہی مواد کے لیے ایک ہی شناخت چاہیے تو اس کا ہیش نکالیں۔ اگر نئی شناخت چاہیے تو UUID بنائیں۔
QR کوڈ بنائیں بمقابلہ بارکوڈ بنائیں۔ QR ایک دو جہتی گرڈ ہے جس میں کوئی بھی ٹیکسٹ آ سکتا ہے — URL، Wi-Fi کی تفصیلات، فون نمبر — اور اسے فون کا کیمرا پڑھتا ہے۔ بارکوڈ پیج ریٹیل اور لاجسٹکس کے یک جہتی کوڈز بناتا ہے: EAN-13، EAN-8، UPC-A، ITF-14، Code 128 اور Code 39، ریٹیل چیک ڈیجٹ کے حساب کے ساتھ، اور غلط یا چھوٹا نمبر خاموشی سے بھر کر کسی دوسری پروڈکٹ کا درست بارکوڈ بنانے کے بجائے رد کر دیا جاتا ہے۔