تصدیق (Authentication) آپ کی ایپلی کیشن کے دروازے پر موجود باؤنسر کی طرح ہے۔ جب بھی کوئی سائن اپ کرتا ہے یا لاگ ان کرتا ہے، آپ کے سسٹم کو یہ فیصلہ کرنا پڑتا ہے کہ آیا وہ وہی ہے جس کا وہ دعویٰ کر رہا ہے۔ اگر آپ سے غلطی ہو گئی، تو آپ صرف ایک ناکام لاگ ان کو ڈی بگ نہیں کر رہے ہوں گے، بلکہ آپ صارفین کے اصل ڈیٹا کو براہ راست خطرے میں ڈال رہے ہوں گے۔ اس کام کو صحیح طریقے سے کرنے کے لیے دو قابل اعتماد ٹولز کی ضرورت ہوتی ہے: پاس ورڈز کو محفوظ رکھنے کے لیے Bcrypt، اور صارف کے ایپ میں گھومتے وقت اس کی شناخت کی تصدیق کے لیے JSON Web Tokens۔
سادہ متن (Plaintext) میں اسٹوریج کیوں ناکام ہو جاتی ہے
اگر آپ اس مضمون سے صرف ایک اصول یاد رکھیں، تو وہ یہ ہے: اپنے ڈیٹا بیس میں پاس ورڈز کو کبھی بھی سادہ متن (plaintext) کی صورت میں محفوظ نہ کریں۔ اس سے کوئی فرق نہیں پڑتا کہ آپ کا ڈیٹا بیس فائر وال کے پیچھے ہے یا آپ ٹیم کے ہر انجینئر پر بھروسہ کرتے ہیں۔ پاس ورڈز کو ان کی اصل شکل میں ٹیبلز میں لکھنا ایسا ہی ہے جیسے گھر کی چابیاں ویلکم میٹ (welcome mat) کے نیچے چھوڑ دینا۔ جس لمحے کسی کو اس ڈیٹا بیس تک رسائی حاصل ہوتی ہے—چاہے وہ غلط کنفیگر شدہ API کے ذریعے ہو، لیک شدہ بیک اپ کے ذریعے، یا انجیکشن اٹیک (injection attack) کے ذریعے—ہر کواڈ (credential) فوری طور پر ظاہر ہو جاتا ہے۔
نقصان اس لیے بڑھ جاتا ہے کیونکہ لوگ پاس ورڈز کو بار بار استعمال کرتے ہیں۔ ایک واحد خلاف ورزی نہ صرف آپ کی ایپلی کیشن بلکہ صارف کے ای میل، بینکنگ اور سوشل میڈیا اکاؤنٹس کو بھی خطرے میں ڈال سکتی ہے۔ یہی وجہ ہے کہ ہم پاس ورڈز کو ہیش (hash) کرتے ہیں۔ ہیشنگ پاس ورڈ کو ایک ایسے الجھے ہوئے اسٹرنگ (string) میں تبدیل کر دیتی ہے جس کا اصل پاس ورڈ سے کوئی ظاہری تعلق نہیں رہتا۔ یہ عمل یک طرفہ اور ناقابل واپسی ہے۔ آپ ہیش پر کوئی ریاضیاتی تیزاب نہیں ڈال سکتے تاکہ اسے دوبارہ اسی پاس ورڈ میں تبدیل کر سکیں جس نے اسے بنایا تھا۔
Bcrypt کے ذریعے پاس ورڈز کی ہیشنگ
Bcrypt ایک ہیشنگ فنکشن ہے جو خاص طور پر پاس ورڈز کے لیے بنایا گیا ہے۔ یہ سادہ اسٹرنگ لیتا ہے، اسے Blowfish cipher کے ذریعے گزارتا ہے، اور ایک ایسا نتیجہ واپس کرتا ہے جو کچھ اس طرح نظر آتا ہے: $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy۔ وہ پری فکس (prefix) آپ کو الگورتھم اور کاسٹ فیکٹر (cost factor) بتاتا ہے۔ طویل حصہ سالٹ (salt) اور خود ہیش کا مجموعہ ہوتا ہے۔
سالٹ (salt) وہ رینڈم ڈیٹا ہے جسے ہیشنگ شروع ہونے سے پہلے پاس ورڈ میں ملایا جاتا ہے۔ چونکہ ہر صارف کے لیے سالٹ منفرد ہوتا ہے، اس لیے دو لوگ جو "password123" کا انتخاب کرتے ہیں، آپ کے ڈیٹا بیس میں بالکل مختلف ہیشز کے ساتھ نظر آئیں گے۔ یہ معمولی سا فرق رینبو ٹیبلز (rainbow tables)—جو عام پاس ورڈز کے ہیشز کی پہلے سے تیار شدہ ڈکشنریز ہوتی ہیں—کو ناکام بنا دیتا ہے—کیونکہ حملہ آوروں کو ہر منفرد سالٹ کے لیے پوری ٹیبل دوبارہ بنانی پڑے گی۔
Bcrypt جان بوجھ کر سست بھی رکھا گیا ہے۔ جدید ہارڈ ویئر SHA-256 جیسے تیز الگورتھم کے ساتھ سیکنڈ میں اربوں ہیشز کا اندازہ لگا سکتا ہے۔ Bcrypt اس عمل کو سست کر دیتا ہے۔ یہ ہیشنگ کے عمل کو کئی بار چلاتا ہے، جسے ایک کاسٹ فیکٹر کے ذریعے کنٹرول کیا جاتا ہے جسے آپ کمپیوٹرز کے تیز ہونے کے ساتھ بڑھا سکتے ہیں۔ یہ سستی کسی بھی ایسے شخص کو سزا دیتی ہے جو چوری شدہ ڈیٹا بیس کو بروٹ فورس (brute-force) کرنے کی کوشش کر رہا ہے۔ لاگ ان کے دوران اضافی دو سو ملی سیکنڈ کا انتظار کرنے والا ایک جائز صارف اسے محسوس نہیں کرے گا۔ لیکن لاکھوں اندازے لگانے کی کوشش کرنے والا حملہ آور اسے ضرور محسوس کرے گا۔
JSON Web Tokens کیسے کام کرتے ہیں
جہاں Bcrypt سامنے کے دروازے کو سنبھالتا ہے، وہیں JWT راہداری کے پاس (hallway pass) کی طرح کام کرتا ہے۔ ایک JSON Web Token ایک مختصر، URL-محفوظ اسٹرنگ ہے جو ثابت کرتی ہے کہ صارف کی پہلے ہی تصدیق ہو چکی ہے۔ اسے ایک ڈیجیٹل آئی ڈی کارڈ سمجھیں جو سرور جاری کرتا ہے اور کلائنٹ اسے اپنے ساتھ رکھتا ہے۔
ایک JWT میں تین حصے ہوتے ہیں جو ڈاٹس (dots) سے الگ کیے جاتے ہیں: ہیڈر (header)، پے لوڈ (payload)، اور سگنیچر (signature)۔ ہیڈر ٹوکن کی قسم اور سائننگ الگورتھم کی وضاحت کرتا ہے۔ پے لوڈ میں کلیمز (claims)—صارف اور خود ٹوکن کے بارے میں بیانات—جیسے کہ صارف کی آئی ڈی، یوزر نیم، اور ایکسپائریشن ٹائم اسٹیمپ شامل ہوتے ہیں۔ سگنیچر ایک کرپٹوگرافک مہر ہے۔ سرور ہیڈر اور پے لوڈ کو انکوڈ کر کے اور پھر انہیں ایک خفیہ کی (secret key) کے ذریعے گزار کر اسے تخلیق کرتا ہے۔ اگر کوئی پے لوڈ کے ساتھ چھیڑ چھاڑ کرتا ہے، تو سگنیچر مزید میچ نہیں کرتا، اور سرور ٹوکن کو فوری طور پر مسترد کر دیتا ہے۔