Authentication म्हणजे तुमच्या ॲप्लिकेशनच्या दरवाजावरील बाउन्सर आहे. जेव्हा जेव्हा कोणीतरी साइन अप करते किंवा लॉग इन करते, तेव्हा ते खरोखर तेच आहेत का जे ते असल्याचा दावा करत आहेत, याचा निर्णय तुमच्या सिस्टमला घ्यावा लागतो. यात चूक झाली, तर तुम्ही फक्त अयशस्वी लॉग इनचे डीबगिंग करत नाही आहात, तर तुम्ही वापरकर्त्याचा खरा डेटा थेट चोरीला जाण्याचा धोका निर्माण करत आहात. हे योग्यरित्या करण्यासाठी दोन विश्वसनीय साधनांची आवश्यकता आहे: साठवलेले पासवर्ड सुरक्षित ठेवण्यासाठी Bcrypt आणि वापरकर्ता तुमच्या ॲपमध्ये फिरत असताना त्याची ओळख पटवण्यासाठी JSON Web Tokens.
प्लेनटेक्स्ट स्टोरेज (Plaintext Storage) का अपयशी ठरते
जर तुम्ही या लेखातून फक्त एकच नियम लक्षात ठेवणार असाल, तर तो हाच असावा: तुमच्या डेटाबेसमध्ये पासवर्ड कधीही प्लेनटेक्स्ट (plaintext) स्वरूपात साठवू नका. तुमचा डेटाबेस फायरवॉलच्या मागे आहे किंवा तुम्ही टीममधील प्रत्येक इंजिनिअरवर विश्वास ठेवता, याने काहीही फरक पडत नाही. पासवर्ड थेट टेबलमध्ये त्यांच्या मूळ स्वरूपात लिहिणे म्हणजे घराच्या पायरीखाली चाव्या सोडून ठेवण्यासारखे आहे. ज्या क्षणी कोणीतरी चुकीच्या कॉन्फिगर केलेल्या API, लीक झालेल्या बॅकअप किंवा इंजेक्शन अटॅकद्वारे त्या डेटाबेसमध्ये प्रवेश मिळवेल, त्या क्षणी प्रत्येक क्रेडेंशियल (credential) त्वरित उघड होईल.
लोक पासवर्डचा पुन्हा वापर करत असल्यामुळे याचे नुकसान अधिक वाढते. एका सिंगल डेटा ब्रीचमुळे केवळ तुमचे ॲप्लिकेशनच नाही, तर वापरकर्त्याचे ईमेल, बँकिंग आणि सोशल मीडिया अकाउंट्स देखील धोक्यात येऊ शकतात. म्हणूनच आपण पासवर्ड हॅश (hash) करतो. हॅशिंग पासवर्डला अशा एका विस्कळीत स्ट्रिंगमध्ये रूपांतरित करते ज्याचा मूळ पासवर्डशी कोणताही स्पष्ट संबंध नसतो. ही प्रक्रिया एकतर्फी आणि अपरिवर्तनीय (irreversible) आहे. तुम्ही हॅशवर कोणतेही गणिती ॲसिड ओतून त्याला मूळ पासवर्डमध्ये पुन्हा विरघळवू शकत नाही.
Bcrypt वापरून पासवर्ड हॅश करणे
Bcrypt हे विशेषतः पासवर्डसाठी बनवलेले हॅशिंग फंक्शन आहे. हे प्लेन स्ट्रिंग घेते, तिला Blowfish cipher मधून फिरवते आणि $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy सारखा निकाल देते. तो प्रीफिक्स (prefix) तुम्हाला अल्गोरिदम आणि कॉस्ट फॅक्टर (cost factor) सांगतो. लांब शेपटी (tail) ही सॉल्ट (salt) आणि हॅशचे मिश्रण असते.
सॉल्ट (salt) हा हॅशिंग सुरू होण्यापूर्वी पासवर्डमध्ये मिसळलेला एक रँडम डेटा आहे. प्रत्येक वापरकर्त्यासाठी सॉल्ट युनिक असल्यामुळे, "password123" निवडणाऱ्या दोन व्यक्तींचे तुमच्या डेटाबेसमध्ये पूर्णपणे वेगळे हॅश तयार होतील. हा छोटासा फरक 'रेनबो टेबल्स' (rainbow tables) — जे सामान्य पासवर्डसाठी हॅशचे आधीच तयार केलेले डिक्शनरी असतात — ला निकामी करतो; कारण हल्लेखोरांना प्रत्येक युनिक सॉल्टसाठी संपूर्ण टेबल पुन्हा तयार करावे लागेल.
Bcrypt मुद्दामहून संथ (slow) ठेवले आहे. आधुनिक हार्डवेअर SHA-256 सारख्या वेगवान अल्गोरिदमसह प्रति सेकंद अब्जावधी हॅश ओळखू शकते, पण Bcrypt मुद्दाम वेळ घेते. हे हॅशिंग प्रक्रिया अनेक वेळा चालवते, जी एका कॉस्ट फॅक्टरद्वारे नियंत्रित केली जाते. संगणक जसजसे वेगवान होतील, तसा तुम्ही हा कॉस्ट फॅक्टर वाढवू शकता. ही संथता चोरीला गेलेल्या डेटाबेसवर ब्रूट-फोर्स (brute-force) करण्याचा प्रयत्न करणाऱ्या कोणालाही रोखते. लॉग इन करताना अतिरिक्त दोनशे मिलीसेकंद वाट पाहणारा वैध वापरकर्त्याला याची जाणीव होणार नाही, पण लाखो अंदाज तपासण्याचा प्रयत्न करणाऱ्या हल्लेखोराला नक्कीच जाणवेल.
JSON Web Tokens कसे काम करतात
Bcrypt मुख्य दरवाजा सांभाळत असताना, JWT 'हॉलवे पास' (hallway pass) सारखे काम करते. JSON Web Token ही एक संक्षिप्त, URL-safe स्ट्रिंग आहे जी वापरकर्त्याची ओळख आधीच पटली आहे हे सिद्ध करते. याला सर्व्हरने दिलेले आणि क्लायंटने सोबत ठेवलेले डिजिटल आयडी कार्ड समजा.
एका JWT मध्ये डॉट्सने विभागलेले तीन भाग असतात: हेडर (header), पेलोड (payload) आणि सिग्नेचर (signature). हेडर टोकनचा प्रकार आणि साइनिंग अल्गोरिदम निर्दिष्ट करते. पेलोडमध्ये 'क्लेम्स' (claims) असतात — वापरकर्ता आणि टोकनबद्दलची माहिती — जसे की युजर आयडी, युजरनेम आणि एक्सपायरी टाइमस्टॅम्प. सिग्नेचर हे क्रिप्टोग्राफिक सील आहे. सर्व्हर हेडर आणि पेलोड एन्कोड करून आणि त्यानंतर त्यांना एका सिक्रेट की (secret key) मधून फिरवून हे सिग्नेचर तयार करते. जर कोणी पेलोडमध्ये फेरफार करण्याचा प्रयत्न केला, तर सिग्नेचर जुळणार नाही आणि सर्व्हर तो टोकन थेट नाकारून देईल.