Bcrypt और Argon2: आपके पासवर्ड्स को वर्कआउट की ज़रूरत क्यों है

एक वाक्य में

Bcrypt और Argon2 जैसे पासवर्ड हैशिंग एल्गोरिदम यूज़र के पासवर्ड को कैरेक्टर्स की एक लंबी, इर्रिवर्सिबल स्ट्रिंग में बदल देते हैं। इन्हें इस तरह डिज़ाइन किया गया है कि इन्हें कंप्यूट करना धीमा और महंगा हो, जिससे हमलावरों के लिए पूरे यूज़र डेटाबेस को चुराने के बाद भी पासवर्ड क्रैक करना बेहद मुश्किल हो जाता है।

यह क्या समस्या हल करता है

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

अगला कदम "हैशिंग" (hashing) था। P@ssword123 स्टोर करने के बजाय, आप उसका हैश स्टोर करते थे—MD5 या SHA-1 जैसे एल्गोरिदम से बनी एक फिक्स्ड-लेंथ स्ट्रिंग। जब यूज़र लॉग इन करता, तो आप उसके डाले गए पासवर्ड को हैश करते और देखते कि क्या यह स्टोर किए गए हैश से मेल खाता है। यह बेहतर था, लेकिन इसमें एक घातक कमी थी: रेनबो टेबल्स (rainbow tables)। चूँकि एक हैश फ़ंक्शन हमेशा एक ही इनपुट के लिए एक ही आउटपुट देता है (जैसे, password का MD5 हैश हमेशा 5f4dcc3b5aa765d61d8327deb882cf99 होता है), हमलावरों ने अरबों आम पासवर्ड के हैश पहले से ही कंप्यूट कर लिए और उन्हें एक विशाल लुकअप टेबल में स्टोर कर लिया। एक चोरी हुए हैश को मिलीसेकंड में उसके मूल पासवर्ड में बदला जा सकता था।

अगला विकास "सॉल्टिंग" (salting) था। पासवर्ड को हैश करने से पहले, आप उसमें एक यूनिक, रैंडम स्ट्रिंग जोड़ते हैं जिसे "सॉल्ट" (salt) कहते हैं। तो P@ssword123 को हैश करने के बजाय, आप P@ssword123 + aBcDeFg12345 को हैश करते। फिर सॉल्ट को डेटाबेस में हैश के साथ स्टोर कर दिया जाता है। यह रेनबो टेबल्स को पूरी तरह से बेकार कर देता है, क्योंकि अब हर यूज़र का हैश यूनिक है, भले ही उन सबने "password" को ही अपना पासवर्ड चुना हो। एक हमलावर को हर एक यूज़र के यूनिक सॉल्ट के लिए एक नई रेनबो टेबल बनानी होगी, जो कम्प्यूटेशनली संभव नहीं है।

लेकिन एक नए विलेन की एंट्री हुई: रॉ कंप्यूटिंग पावर। आधुनिक GPU और कस्टम हार्डवेयर (ASICs) एक चोरी हुए हैश के खिलाफ प्रति सेकंड अरबों सॉल्टेड पासवर्ड कॉम्बिनेशन आज़मा सकते हैं। SHA-256 जैसे हैशिंग एल्गोरिदम डिज़ाइन से ही तेज़ होते हैं, जो फ़ाइल इंटेग्रिटी को वेरिफाई करने के लिए तो बहुत अच्छा है लेकिन पासवर्ड की सुरक्षा के लिए भयानक है।

इसी समस्या को हल करने के लिए bcrypt और Argon2 का जन्म हुआ। ये पासवर्ड हैशिंग फंक्शन्स (PHFs) हैं, जो हैश एल्गोरिदम की एक विशेष श्रेणी है जो जानबूझकर, बहुत धीमे और रिसोर्स-इंटेंसिव होते हैं। वे एक पासवर्ड को चेक करना भी इतना महंगा बना देते हैं कि चोरी हुए डेटाबेस को ब्रूट-फोर्स करना हमलावर के लिए एक आर्थिक और समय के हिसाब से दुःस्वप्न बन जाता है।

यह अंदर से कैसे काम करता है

आधुनिक पासवर्ड हैशिंग के पीछे का जादू सिर्फ एल्गोरिदम के बारे में नहीं है; यह उस एल्गोरिदम से एक कॉन्फ़िगर करने योग्य मात्रा में "काम" करवाने के बारे में है। इसे अक्सर "की स्ट्रेचिंग" (key stretching) कहा जाता है।

मूल आईडिया: एडैप्टिव कॉस्ट

Bcrypt और Argon2 दोनों में ट्यून करने योग्य "कॉस्ट" (cost) या "वर्क" (work) फैक्टर होते हैं। यही उनकी सुपरपावर है। यह एक नंबर है जिसे आप सेट करते हैं जो यह तय करता है कि हैशिंग प्रक्रिया कितनी धीमी और रिसोर्स-हंग्री होगी। आईडिया यह है कि इस कॉस्ट को इस तरह ट्यून किया जाए कि आपके सर्वर पर पासवर्ड को हैश करने में एक उचित समय लगे (मान लीजिए, 100-500 मिलीसेकंड) — इतना धीमा कि हमलावर निराश हो जाए, लेकिन इतना तेज़ कि आपके यूज़र्स परेशान न हों।

जैसे-जैसे मूर के नियम (Moore's Law) के अनुसार कंप्यूटर तेज़ होते जाते हैं, आप सिक्योरिटी का वही स्तर बनाए रखने के लिए हर कुछ सालों में कॉस्ट फैक्टर को बस बढ़ा सकते हैं। जैसे-जैसे हमलावर का हार्डवेयर मज़बूत होता जाता है, आपका हैशिंग "वर्कआउट" और कठिन होता जाता है।

Bcrypt: भरोसेमंद पुराना खिलाड़ी

1999 में पेश किया गया Bcrypt, ब्लोफिश एन्क्रिप्शन सिफर पर आधारित है। ब्रूट-फोर्स हमलों के खिलाफ इसका मुख्य बचाव यह है कि यह केवल कम्प्यूटेशनली इंटेंसिव ही नहीं, बल्कि मेमोरी इंटेंसिव भी है।

एल्गोरिदम बार-बार पासवर्ड और सॉल्ट को प्रोसेस करता है, लेकिन इसकी इंटरनल स्टेट का एक मुख्य हिस्सा इस तरह से स्टोर किया जाता है कि उसे RAM के एक हिस्से तक लगातार एक्सेस की ज़रूरत पड़ती है। जबकि CPU इसमें अच्छे होते हैं, GPU—हमलावर का पसंदीदा हथियार—सरल, पैरेलल हो सकने वाले कैलकुलेशन पर पनपते हैं जिनमें न्यूनतम मेमोरी एक्सेस हो। प्रक्रिया को लगातार मेमोरी में जाने के लिए मजबूर करके, bcrypt GPU-आधारित क्रैकिंग रिग्स के काम में अड़ंगा डालता है।

एक सामान्य bcrypt हैश स्ट्रिंग इस तरह दिखती है:

$2b$12$J9yLsf9dTOZiCEpT1zO97uF2Yp3uG/yG4Q6V.C1rCg8u6d5qO5GqS

आइए इसे तोड़कर समझते हैं:

हिस्सा	उदाहरण	मतलब
एल्गोरिदम	$2b	bcrypt एल्गोरिदम और उसके वर्ज़न को पहचानता है।
कॉस्ट फैक्टर	12	यह वर्क फैक्टर है। इटरेशन्स की संख्या 212 है। इसे 1 बढ़ाने से समय दोगुना हो जाता है।
सॉल्ट और हैश	J9yLsf...d5qO5GqS	पहले 22 कैरेक्टर Base64-एन्कोडेड सॉल्ट हैं। बाकी का हिस्सा असली हैश किया हुआ पासवर्ड डाइजेस्ट है।

महत्वपूर्ण बात यह है कि पासवर्ड को वेरिफाई करने के लिए ज़रूरी सभी जानकारी—एल्गोरिदम, कॉस्ट, और सॉल्ट—एक ही सुविधाजनक स्ट्रिंग में स्टोर होती है।

Argon2: आज का चैंपियन

Argon2 2015 में पासवर्ड हैशिंग कॉम्पिटिशन (PHC) का विजेता था, जो एक नया, मानकीकृत पासवर्ड हैशिंग एल्गोरिदम खोजने के लिए एक कई वर्षों तक चला प्रयास था। इसे bcrypt से भी ज़्यादा आधुनिक हार्डवेयर हमलों के प्रतिरोधी होने के लिए डिज़ाइन किया गया है।

यह अपनी कॉस्ट को ट्यून करने के लिए तीन अलग-अलग लीवर्स प्रदान करता है:

1. मेमोरी कॉस्ट (m): मेमोरी की मात्रा (KiB में) जो एल्गोरिदम इस्तेमाल करेगा। यह हार्डवेयर एक्सेलेरेशन के खिलाफ इसका मुख्य बचाव है, क्योंकि इसे इतनी मेमोरी की ज़रूरत के लिए ट्यून किया जा सकता है जितनी एक सिंगल GPU कोर पर उपलब्ध नहीं है।
2. टाइम कॉस्ट (t): इटरेशन्स, या पासेज़ की संख्या, जो एल्गोरिदम मेमोरी पर करता है। यह कुल कंप्यूटेशन समय को बढ़ाता है।
3. पैरलेलिज़्म (p): थ्रेड्स या "लेन्स" की संख्या जिन्हें इस्तेमाल किया जा सकता है। यह एल्गोरिदम को हैशिंग के लिए मल्टी-कोर CPU का लाभ उठाने की अनुमति देता है, लेकिन इसका मतलब यह भी है कि एक हमलावर भी उसी पैरलेलिज़्म का उपयोग कर सकता है। यह एक ट्रेड-ऑफ पैरामीटर है।

इसकी सबसे रेकमेंडेड वेरिएंट Argon2id है, जो दो अन्य वर्ज़न्स का एक हाइब्रिड है। यह साइड-चैनल हमलों (जहाँ एक हमलावर सिस्टम के प्रभावों जैसे बिजली की खपत का विश्लेषण करता है) और GPU क्रैकिंग हमलों दोनों के खिलाफ एक संतुलित प्रतिरोध प्रदान करता है।

एक Argon2id हैश स्ट्रिंग भी इसी तरह सेल्फ-कंटेन्ड होती है:

$argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTIT0T7cKLfgflAIk124

हिस्सा	उदाहरण	मतलब
एल्गोरिदम	$argon2id	Argon2id एल्गोरिदम को पहचानता है।
वर्ज़न	v=19	एल्गोरिदम का वर्ज़न नंबर।
पैरामीटर्स	m=65536,t=3,p=4	मेमोरी, टाइम और पैरलेलिज़्म कॉस्ट।
सॉल्ट	c29tZXNhbHQ	Base64-एन्कोडेड रैंडम सॉल्ट। (यह "somesalt" में डिकोड होता है)।
हैश	Rdescudv...flAIk124	Base64-एन्कोडेड हैश किया हुआ पासवर्ड डाइजेस्ट।

वेरिफ़िकेशन की प्रक्रिया

यह सबसे खूबसूरत हिस्सा है। आप हैश को कभी भी डिक्रिप्ट नहीं करते। वेरिफ़िकेशन एक वन-वे स्ट्रीट है।

1. एक यूज़र P@ssword123 के साथ लॉग इन करने का प्रयास करता है।
2. आपका एप्लिकेशन डेटाबेस से उसकी पूरी हैश स्ट्रिंग (जैसे, ऊपर की टेबल से Argon2id स्ट्रिंग) प्राप्त करता है।
3. आपका कोड उस स्ट्रिंग को पार्स करता है, जिससे एल्गोरिदम (argon2id), वर्ज़न (19), कॉस्ट फैक्टर (m=65536, t=3, p=4), और सॉल्ट (c29tZXNhbHQ) निकलते हैं।
4. फिर यह यूज़र द्वारा अभी दर्ज किए गए पासवर्ड (P@ssword123) को लेता है और उसे उन्हीं सटीक पैरामीटर्स का उपयोग करके हैश करता है।
5. अंत में, यह नए जेनरेट किए गए हैश की तुलना डेटाबेस से मिली स्ट्रिंग के हैश वाले हिस्से से करता है। यदि वे समान हैं, तो पासवर्ड सही है। यदि नहीं, तो एक्सेस अस्वीकृत कर दिया जाता है।

असल दुनिया की कहानियाँ

2012 का लिंक्डइन ब्रीच: स्पीड से मिला एक सबक

2012 में, लिंक्डइन को एक बड़े ब्रीच का सामना करना पड़ा, और 6.5 मिलियन से अधिक यूज़र पासवर्ड हैश एक रूसी हैकर फोरम पर लीक हो गए। समस्या? हैश बिना सॉल्ट वाला SHA-1 था। कुछ ही घंटों में, सिक्योरिटी के शौकीनों और ब्लैक हैट हैकर्स ने उन्हें क्रैक करने की होड़ शुरू कर दी। सफलतापूर्वक क्रैक किए गए पासवर्ड की सूचियाँ मिनटों में बढ़ने लगीं। क्योंकि हैश "तेज़" और बिना सॉल्ट के थे, एक विशाल रेनबो टेबल ही काफी थी। कंपनी की प्रतिष्ठा को भारी नुकसान हुआ।

सबक: एक तेज़, बिना सॉल्ट वाला हैश प्लेनटेक्स्ट से बस थोड़ा ही बेहतर है। लिंक्डइन ब्रीच उद्योग के लिए एक बड़ी चेतावनी थी जिसने अनगिनत कंपनियों को अंततः bcrypt जैसे धीमे, सॉल्टेड हैशिंग को अपनाने के लिए प्रेरित किया।

वो ई-कॉमर्स साइट जिसने समय खरीदा

एक स्टार्टअप, "सर्किट क्रेज़" के एक समझदार डेवलपर ने अपने नए ग्राहक डेटाबेस के लिए Argon2id का उपयोग करने पर जोर दिया, और पैरामीटर्स को इस तरह ट्यून किया कि प्रति लॉगिन लगभग 300ms लगे। एक साल बाद, एक गलत कॉन्फ़िगर किए गए क्लाउड स्टोरेज बकेट ने डेटाबेस बैकअप को एक्सपोज कर दिया। users टेबल, अपने सभी Argon2id हैश के साथ, एक हमलावर द्वारा डाउनलोड कर ली गई। टीम ने तुरंत एक ग्लोबल पासवर्ड रीसेट लागू कर दिया। हमलावर, जिसे अब एक बेकार हो चुके डेटासेट से मुट्ठी भर पासवर्ड क्रैक करने के लिए क्लाउड कंप्यूटिंग पर हजारों डॉलर खर्च करने की संभावना का सामना करना पड़ा, ने बस हार मान ली और आसान शिकार की तलाश में आगे बढ़ गया।

सबक: मज़बूत पासवर्ड हैशिंग एक ब्रीच के बाद आपका प्राथमिक बचाव है। यह ब्रीच को नहीं रोकता है, लेकिन यह आपको प्रतिक्रिया देने के लिए महत्वपूर्ण समय देकर एक विनाशकारी डेटा लीक को एक प्रबंधनीय घटना में बदल देता है।

कॉस्ट फैक्टर का धीरे-धीरे बढ़ना

एक टीम ने 2015 में एक नया वेब ऐप लॉन्च किया, समझदारी से 10 के कॉस्ट फैक्टर के साथ bcrypt को चुना। यह बढ़िया काम कर रहा था। आज के समय में, मूर के नियम ने अपना काम किया है, और 10 का कॉस्ट फैक्टर अब कमज़ोर माना जाता है। एक सिक्योरिटी ऑडिट इसे उच्च-प्राथमिकता वाले जोखिम के रूप में चिह्नित करता है। टीम अब एक दुविधा का सामना कर रही है: वे लाखों यूज़र्स के लिए सुरक्षा को कैसे अपग्रेड करें बिना उन्हें सामूहिक पासवर्ड रीसेट के लिए मजबूर किए? इसका शानदार समाधान: अगली बार जब कोई यूज़र लॉग इन करता है, तो सिस्टम उसके पासवर्ड को पुराने कॉस्ट-10 वाले हैश से वेरिफाई करता है। अगर यह सही है, तो वह तुरंत उसी पासवर्ड को 13 के नए कॉस्ट के साथ फिर से हैश करता है और डेटाबेस में पुराने हैश को बदल देता है।

सबक: पासवर्ड सिक्योरिटी "एक बार सेट करो और भूल जाओ" वाली चीज़ नहीं है। कॉस्ट फैक्टर एक जीवित सेटिंग है जिसकी समय-समय पर समीक्षा की जानी चाहिए और हमलावर की क्षमताओं के साथ तालमेल बनाए रखने के लिए इसे बढ़ाया जाना चाहिए।

आम गलतियाँ और जाल

• एक फास्ट हैश का उपयोग करना। ऐसा न करें। MD5, SHA-1, SHA-256, SHA-512... ये चेकसम के लिए हैं, पासवर्ड के लिए नहीं। उन्हें तेज़ होने के लिए डिज़ाइन किया गया है, जो ठीक वही है जो आप नहीं चाहते हैं।
• अपना खुद का क्रिप्टो बनाना। कभी भी अपनी खुद की हैशिंग स्कीम बनाने की कोशिश न करें, जैसे sha512(password + salt)। Bcrypt या Argon2 के लिए एक मानक, पीयर-रिव्यू की गई, युद्ध-परीक्षित लाइब्रेरी का उपयोग करें जो इसे सही तरीके से करती है।
• एक स्टैटिक या दोबारा इस्तेमाल किए गए सॉल्ट का उपयोग करना। एक सॉल्ट क्रिप्टोग्राफिक रूप से रैंडम और आपके द्वारा स्टोर किए गए हर एक पासवर्ड के लिए यूनिक होना चाहिए। प्रत्येक हैश के साथ एक यूनिक सॉल्ट स्टोर करना सही और मानक अभ्यास है।
• कॉस्ट बहुत कम सेट करना। 12 से नीचे का bcrypt कॉस्ट फैक्टर (2024 में) या कमज़ोर Argon2 पैरामीटर्स पूरे उद्देश्य को विफल कर देते हैं। आप बस हमलावर को एक आसान दिन दे रहे हैं। इसे उतना धीमा ट्यून करें जितना आप बर्दाश्त कर सकते हैं।
• कॉस्ट बहुत ज़्यादा सेट करना। अगर हैशिंग में 10 सेकंड लगते हैं, तो आपका लॉगिन फॉर्म टाइम आउट हो जाएगा और टूटा हुआ महसूस होगा। इससे भी बदतर, आप अपने सर्वर को डिनायल-ऑफ़-सर्विस (DoS) हमले के लिए खुला छोड़ देते हैं, जहाँ कोई केवल लॉगिन फॉर्म पर बार-बार पोस्ट करके आपके CPU को ठप कर सकता है।
• सिर्फ हैश डाइजेस्ट को स्टोर करना। Bcrypt और Argon2 द्वारा जेनरेट की गई स्ट्रिंग्स में एल्गोरिदम, कॉस्ट और सॉल्ट एक कारण से होते हैं। भविष्य में पासवर्ड वेरिफाई करने में सक्षम होने के लिए आपको उस पूरी स्ट्रिंग को (जैसे, एक VARCHAR(255) कॉलम में) स्टोर करना होगा।

यह आपके रडार पर क्यों होना चाहिए

अगर आपके काम में लॉगिन फॉर्म वाली कोई भी चीज़ बनाना शामिल है, तो आपको इसे समझने की ज़रूरत है।

• बैकएंड और फुल-स्टैक डेवलपर्स: यह आपकी सीधी ज़िम्मेदारी है। अगर आपने यह गलत किया, तो आप अपने हर यूज़र को जोखिम में डाल देंगे।
• सिक्योरिटी इंजीनियर्स और DevOps: आप ही पॉलिसी सेट करते हैं, ऑडिट करते हैं, और इंफ्रास्ट्रक्चर मैनेज करते हैं। आपको यह जानना होगा कि "अच्छा" कैसा दिखता है और इसे कैसे टेस्ट करना है।
• फ्रंटएंड डेवलपर्स: यह समझना कि एक सुरक्षित लॉगिन में कुछ सौ मिलीसेकंड लग सकते हैं, यह बताता है कि आपको यूज़र को फीडबैक (जैसे लोडिंग स्पिनर) क्यों देना चाहिए ताकि वे गुस्से में "लॉग इन" बटन पर बार-बार क्लिक न करें।

संक्षेप में, यदि आपके प्रोजेक्ट की ज़रूरतों में "यूज़र," "अकाउंट," या "पासवर्ड" शब्द कहीं भी आते हैं, तो पासवर्ड हैशिंग एक मौलिक कॉन्सेप्ट है जिसे आप नज़रअंदाज़ नहीं कर सकते।

और गहराई में जाएं

• OWASP Password Storage Cheat Sheet — डेवलपर्स के लिए ज़रूरी और आधिकारिक गाइड।
• Argon2 Specification — वह औपचारिक पेपर जो बताता है कि Argon2 कैसे काम करता है।
• How To Safely Store A Password by Coda Hale — एक क्लासिक 2010 का ब्लॉग पोस्ट जो डेवलपर्स की एक पूरी पीढ़ी को bcrypt के 'क्यों' को समझाता है।
• Bcrypt on Wikipedia — एल्गोरिदम के इतिहास और डिज़ाइन का एक ठोस अवलोकन।
• Argon2 on Wikipedia — पासवर्ड हैशिंग कॉम्पिटिशन और Argon2 के डिज़ाइन की पृष्ठभूमि।
• Password Hashing Competition — उस कॉम्पिटिशन की आधिकारिक साइट जिसने Argon2 को विजेता बनाया।