Authentication आपके एप्लिकेशन के दरवाजे पर खड़ा एक बाउंसर है। हर बार जब कोई साइन अप करता है या लॉग इन करता है, तो आपके सिस्टम को यह तय करना होता है कि क्या वे वही हैं जो वे होने का दावा कर रहे हैं। अगर इसमें गलती हुई, तो आप केवल एक विफल लॉगिन को डीबग नहीं कर रहे होंगे। आप वास्तविक उपयोगकर्ता डेटा के सीधे चोरी होने का जोखिम उठा रहे होंगे। इसे ठीक से करने के लिए दो विश्वसनीय उपकरणों की आवश्यकता होती है: पासवर्ड को सुरक्षित रखने के लिए Bcrypt, और उपयोगकर्ता के ऐप में घूमते समय उनकी पहचान सत्यापित करने के लिए JSON Web Tokens।
Plaintext स्टोरेज क्यों विफल होता है
यदि आप इस लेख से केवल एक नियम याद रखना चाहते हैं, तो वह यह है: अपने डेटाबेस में पासवर्ड को कभी भी plaintext के रूप में स्टोर न करें। इससे कोई फर्क नहीं पड़ता कि आपका डेटाबेस फायरवॉल के पीछे है या आप टीम के हर इंजीनियर पर भरोसा करते हैं। पासवर्ड को उनके कच्चे (raw) रूप में टेबल्स में लिखना, घर की चाबियों को वेलकम मैट के नीचे छोड़ने जैसा है। जिस क्षण कोई उस डेटाबेस तक पहुँच प्राप्त कर लेता है—एक गलत कॉन्फ़िगर किए गए API, लीक हुए बैकअप, या इंजेक्शन अटैक के माध्यम से—हर क्रेडेंशियल तुरंत उजागर हो जाता है।
नुकसान कई गुना बढ़ जाता है क्योंकि लोग पासवर्ड को दोबारा इस्तेमाल करते हैं। एक अकेला उल्लंघन न केवल आपके एप्लिकेशन को, बल्कि उपयोगकर्ता के ईमेल, बैंकिंग और सोशल मीडिया खातों को भी खतरे में डाल सकता है। इसीलिए हम पासवर्ड को हैश (hash) करते हैं। हैशिंग पासवर्ड को एक ऐसे उलझे हुए स्ट्रिंग (scrambled string) में बदल देती है जिसका मूल पासवर्ड से कोई स्पष्ट संबंध नहीं दिखता। यह प्रक्रिया एकतरफा और अपरिवर्तनीय है। आप किसी हैश पर गणितीय एसिड डालकर उसे वापस उसी पासवर्ड में नहीं बदल सकते जिससे वह बना था।
Bcrypt के साथ पासवर्ड हैश करना
Bcrypt विशेष रूप से पासवर्ड के लिए बनाया गया एक हैशिंग फंक्शन है। यह प्लेन स्ट्रिंग लेता है, उसे Blowfish cipher के माध्यम से चलाता है, और एक ऐसा परिणाम देता है जो कुछ इस तरह दिखता है: $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy। वह प्रीफ़िक्स आपको एल्गोरिदम और कॉस्ट फैक्टर (cost factor) बताता है। लंबा हिस्सा (tail) साल्ट (salt) और हैश का संयोजन है।
साल्ट (salt) वह रैंडम डेटा है जिसे हैशिंग शुरू होने से पहले पासवर्ड में मिला दिया जाता है। क्योंकि साल्ट हर उपयोगकर्ता के लिए अद्वितीय होता है, इसलिए "password123" चुनने वाले दो लोगों के डेटाबेस में पूरी तरह से अलग हैश होंगे। यह मामूली अंतर रेनबो टेबल्स (rainbow tables)—सामान्य पासवर्ड के हैश के प्रीकंप्यूटेड डिक्शनरी—को विफल कर देता है, क्योंकि हमलावरों को प्रत्येक अद्वितीय साल्ट के लिए पूरी टेबल को फिर से बनाने की आवश्यकता होगी।
Bcrypt जानबूझकर धीमा भी है। आधुनिक हार्डवेयर SHA-256 जैसे तेज़ एल्गोरिदम के साथ प्रति सेकंड अरबों हैश का अनुमान लगा सकता है। Bcrypt जानबूझकर समय लेता है। यह हैशिंग प्रक्रिया को कई बार चलाता है, जिसे एक कॉस्ट फैक्टर द्वारा नियंत्रित किया जाता है जिसे आप कंप्यूटर के तेज़ होने के साथ बढ़ा सकते हैं। वह सुस्ती किसी भी ऐसे व्यक्ति को दंडित करती है जो चोरी किए गए डेटाबेस के माध्यम से ब्रूट-फोर्स (brute-force) करने की कोशिश कर रहा है। लॉगिन के दौरान अतिरिक्त दो सौ मिलीसेकंड प्रतीक्षा करने वाला एक वैध उपयोगकर्ता इसे नोटिस नहीं करेगा। लेकिन लाखों अनुमान लगाने की कोशिश करने वाला हमलावर इसे निश्चित रूप से महसूस करेगा।
JSON Web Tokens कैसे काम करते हैं
जहाँ Bcrypt मुख्य दरवाजे को संभालता है, वहीं JWT हॉलवे पास (hallway pass) को संभालता है। एक JSON Web Token एक संक्षिप्त, URL-सुरक्षित स्ट्रिंग है जो यह साबित करता है कि उपयोगकर्ता पहले ही प्रमाणित (authenticated) हो चुका है। इसे एक डिजिटल आईडी कार्ड के रूप में सोचें जिसे सर्वर जारी करता है और क्लाइंट अपने साथ रखता है।
एक JWT में डॉट्स द्वारा अलग किए गए तीन सेगमेंट होते हैं: हेडर (header), पेलोड (payload), और सिग्नेचर (signature)। हेडर टोकन प्रकार और साइनिंग एल्गोरिदम को निर्दिष्ट करता है। पेलोड में क्लेम्स (claims)—उपयोगकर्ता और स्वयं टोकन के बारे में विवरण—जैसे कि उपयोगकर्ता आईडी, यूजरनेम और एक्सपायरी टाइमस्टैम्प होते हैं। सिग्नेचर एक क्रिप्टोग्राफिक सील है। सर्वर हेडर और पेलोड को एनकोड करके और फिर उन्हें एक सीक्रेट की (secret key) के माध्यम से चलाकर इसे बनाता है। यदि कोई पेलोड के साथ छेड़छाड़ करता है, तो सिग्नेचर अब मेल नहीं खाता है, और सर्वर टोकन को तुरंत खारिज कर देता है।
