ढंग से बनी वेबसाइट को आपका पासवर्ड पता नहीं होता। ऐसा नहीं कि वह जानना नहीं चाहती: वह जान ही नहीं सकती।
यह बात चालबाज़ी जैसी लगती है, क्योंकि जब भी आप पासवर्ड टाइप करते हैं, सिस्टम आपको भीतर आने देता है, और भीतर आने देने के लिए उसे कुछ तो जाँचना ही पड़ता है। लेकिन जाँचना जानना नहीं है। सर्वर आपके पासवर्ड से बना एक निशान सहेजता है; जब आप टाइप करते हैं, वह निशान दोबारा बनाता है और मिलान करता है। मिल गया तो आइए। किसी भी क्षण यह ज़रूरी नहीं कि पासवर्ड कहीं लिखा हुआ हो।
इसी से वह सबसे साफ़ पहचान निकलती है कि कौन सी सेवा गंभीर है और कौन नहीं: अगर पासवर्ड भूलने पर वे उसे ईमेल में भेज देते हैं, तो उनके पास वह सहेजा हुआ था। और जो सहेजा हुआ है, वह देर-सबेर किसी और के हाथ लगता ही है।
1979 न सहेजने का विचार — और धीरे-धीरे करने का भी
1979 में Robert Morris और Ken Thompson ने Communications of the ACM में “Password Security: A Case History” छापा, जिसमें उन्होंने बताया कि उन्होंने Unix में क्या किया था। यह सीखे हुए का ब्योरा है, और इसी में वे दो विचार जमकर बैठ जाते हैं जिन्हें आज हम ज़ाहिर मान लेते हैं।
पहला उन्होंने ईजाद नहीं किया — पासवर्ड की जगह हैश सहेजना पहले से होता था — लेकिन समझाया उन्होंने सबसे बेहतर: पासवर्ड मत सहेजो, उसका हैश सहेजो। एक ऐसा फ़ंक्शन जो आपके पासवर्ड को बेतरतीब दिखने वाली एक क़ीमत में बदल देता है और जिसे उलटा नहीं चला सकते: हैश से पासवर्ड पर वापस नहीं लौटा जा सकता।
दूसरा विचार सचमुच उन्हीं का है: सॉल्ट। हर उपयोगकर्ता के लिए अलग एक यादृच्छिक क़ीमत, जो हैश बनाने से पहले पासवर्ड में मिला दी जाती है। सॉल्ट के बिना, एक ही पासवर्ड वाले दो लोगों का हैश एक जैसा होता है — चुराई हुई फ़ाइल एक जैसे जोड़े ढूँढ़ने का खेल बन जाती है — और उससे भी बुरा, कोई एक बार एक विशाल तालिका पहले से बनाकर दुनिया भर के डेटाबेस पर आज़मा सकता है। सॉल्ट आपके पासवर्ड का अंदाज़ा लगाना मुश्किल नहीं करता: वह यह करता है कि आपका अंदाज़ा किसी और के काम न आए।
लेकिन उसी लेख में एक तीसरा विचार भी है, जिसका ज़िक्र कहीं कम होता है, और यहाँ मतलब उसी का है: उन्होंने फ़ंक्शन को जानबूझकर धीमा बनाया। लापरवाही से नहीं। इरादतन। एक पासवर्ड को एन्क्रिप्ट करना तकनीकी ज़रूरत से कहीं ज़्यादा महँगा पड़ता था, क्योंकि जो रोज़ सुबह एक बार भीतर आता है उसे फ़र्क़ नहीं पड़ता, और जो लाखों उम्मीदवार आज़माता है उसे पड़ता है।
लगभग पचास साल पुराने एक वाक्य में पूरा मामला यही है।
धीमापन ही इकलौता ईमानदार बचाव क्यों है
कंप्यूटर सुरक्षा के लगभग सारे बचाव असमान होते हैं: बचाव करने वाले को सस्ते पड़ते हैं, हमला करने वाले को महँगे। एन्क्रिप्ट करना सस्ता है; बिना चाबी डिक्रिप्ट करना नामुमकिन। बचाव करने वाले के पास ढाँचागत बढ़त होती है।
पासवर्ड सहेजने में ऐसा नहीं है। यहाँ बचाव करने वाला और हमलावर बिल्कुल एक ही फ़ंक्शन चलाते हैं। आप हैश बनाते हैं यह जाँचने को कि आपने सही टाइप किया; वह हैश बनाता है यह जाँचने को कि उसका अंदाज़ा सही बैठा या नहीं। सुरक्षा की यह इकलौती दौड़ है जिसमें दोनों एक ही टाँगों से दौड़ते हैं।
जब आप अपने प्रतिद्वंद्वी से तेज़ नहीं दौड़ सकते, तो एक ही चाल बचती है: दोनों के लिए मैदान महँगा कर दो। यह क़ीमत आप हर लॉगिन पर एक बार चुकाते हैं। वह हर कोशिश पर एक बार। चूँकि उसे आपसे कई गुना ज़्यादा कोशिशें चाहिए, वही एक बिल आप दोनों पर बिल्कुल अलग असर डालता है। पासवर्ड हैश यही करता है।
इसीलिए वे फ़ंक्शन जो तेज़ हैं और बाक़ी कामों के लिए बढ़िया हैं — मसलन SHA-256 — यहाँ बेहद ख़राब चुनाव हैं। वे तेज़ हैं। और तेज़ ठीक वही है जो हमें नहीं चाहिए।
1999 bcrypt, और लागत एक घुमाने लायक़ घुंडी बनी
धीमे फ़ंक्शन की दिक़्क़त यह है कि हार्डवेयर एक जगह नहीं ठहरता। जो 1979 में धीमा था, बाद में पलक झपकते हो जाता है। एक दशक के कंप्यूटरों के हिसाब से नापा गया बचाव अपने आप बूढ़ा हो जाता है, बिना किसी के छुए।
1999 में Niels Provos और David Mazières ने USENIX Annual Technical Conference में bcrypt पेश किया, और शीर्षक ही सब कह देता है: A Future-Adaptable Password Scheme।
विचार यह: लागत फ़ंक्शन में न हो, एक पैरामीटर में हो। bcrypt में एक कॉस्ट फ़ैक्टर होता है जो आप तय करते हैं और जो हैश के साथ ही सहेजा जाता है। हार्डवेयर बहुत तेज़ हो जाए, तो आप वह संख्या बढ़ा देते हैं और नए पासवर्ड फिर उतने ही महँगे पड़ने लगते हैं जितने पड़ने चाहिए — बिना एल्गोरिद्म बदले।
यह ऐसा डिज़ाइन है जो अपना ही पुराना पड़ जाना मान लेता है और उसके लिए तैयारी करता है। ऐसा करने वाला सॉफ़्टवेयर बहुत ही कम है।
2009 scrypt, और यह पता चलना कि सिर्फ़ समय काफ़ी नहीं
bcrypt गणना का समय महँगा करता है, और यह चला भी। तब तक, जब तक हमलावर ने वही मशीन इस्तेमाल करना छोड़ नहीं दिया जो बचाव करने वाले के पास थी।
एक सर्वर में गिने-चुने तेज़ और सामान्य कामकाज वाले कोर होते हैं। एक GPU में छोटे-छोटे कोरों की भरमार होती है जो एक साथ एक ही काम समांतर करते रहते हैं, और ASIC तो और आगे जाता है: सिलिकॉन जो सिर्फ़ एक ही ऑपरेशन चलाने के लिए बना है। अगर आपका बचाव यह है कि “इस ऑपरेशन की क़ीमत X है”, तो कोई ऐसा हार्डवेयर बना सकता है जो एक साथ बहुत सारे X कर डाले। बचाव करने वाला अपने सर्वर के साथ ही खड़ा रह जाता है।
2009 में Colin Percival ने scrypt एक अलग दलील के साथ पेश किया: Stronger Key Derivation via Sequential Memory-Hard Functions। अगर लागत सिर्फ़ गणना में है, तो उसे समांतर किया जा सकता है। लेकिन मेमोरी मुफ़्त नहीं मिलती। फ़ंक्शन को खूब सारी RAM इस्तेमाल करने पर मजबूर कीजिए, और उसे इस तरह टहलाइए कि बचकर निकला न जा सके — और अचानक हमलावर कोर गुणा नहीं कर सकता: हर कोर को अपनी अलग मेमोरी चाहिए होगी। और GPU के कोरों में ताक़त बहुत है, पर हर एक के हिस्से RAM बहुत कम।
Percival ने ऑपरेशन महँगा नहीं किया। उसे थोक में दोहराने के लिए ज़रूरी हार्डवेयर महँगा कर दिया। यह स्तर का बदलाव है: वार हमलावर की घड़ी पर नहीं, उसके बजट पर होता है।
2015 Argon2, और बहस का अंत
कई ठीक-ठाक विकल्पों का होना किसी को चुनने में मदद नहीं करता था। तो क्रिप्टोग्राफ़ी समुदाय ने वही किया जो वह किसी बात को निपटाने के लिए आम तौर पर करता है: एक खुली प्रतियोगिता। Password Hashing Competition ने उम्मीदवार लिए, उन्हें सालों तक खुले विश्लेषण से गुज़ारा और 2015 में Argon2 को विजेता घोषित किया।
Argon2 दोनों सबक़ अपने साथ लेता है: समय की लागत और मेमोरी की लागत, दोनों अलग-अलग घुमाई जा सकती हैं, और साथ में थ्रेड की संख्या भी। यह जादू नहीं है। यह 1979, 1999 और 2009 का सलीक़े से किया गया निचोड़ है, जिसे उन लोगों ने परखा जिनका काम ही उसे तोड़ने की कोशिश करना था।
आपके लिए इसका मतलब क्या है
इसमें से लगभग कुछ भी आपके हाथ में नहीं है, और यह कह देना ठीक रहेगा: हैश वेबसाइट चुनती है, आप नहीं। आपके पास दुनिया का सबसे बढ़िया पासवर्ड हो सकता है और वे उसे किसी Excel में सादे टेक्स्ट में सहेज सकते हैं।
लेकिन समीकरण का दूसरा पलड़ा आप पर ही टिका है। यह पूरी इमारत — सॉल्ट, लागत, मेमोरी — हमलावर की हर कोशिश को महँगा करने के लिए है। उसे कितनी कोशिशें चाहिए, यह तय आपका पासवर्ड करता है। अगर वह किसी शब्दकोश में है, तो कोई भी धीमा फ़ंक्शन आपको नहीं बचाएगा: वह पहली कुछ कोशिशों में ही गिर जाएगा। अगर वह लंबा है और किसी चीज़ से मिलता-जुलता नहीं है, तो हर कोशिश की वह क़ीमत कोशिशों की एक ऐसी संख्या से गुणा हो जाती है जो उपलब्ध समय में समाती ही नहीं।
इसीलिए हमारा जनरेटर एंट्रॉपी के बिट नापता है, प्रतिशत नहीं, और इसीलिए चेकर चिह्न गिनने से पहले आपका पासवर्ड शब्दकोशों में ढूँढ़ता है। क़ीमत प्रति कोशिश वे तय करते हैं; कोशिशों की संख्या आप। दोनों आधे हिस्सों में से कोई भी दूसरे के बिना काम नहीं करता।
और हाँ: सवाल वही पुराना का पुराना है। बस अब दूसरी तरफ़ कोई उसका जवाब सेकंड में कई-कई बार देने की कोशिश कर रहा है, और 1979 से हम यही कोशिश कर रहे हैं कि उसकी हर कोशिश उसे पैसे में पड़े।
स्रोत: R. Morris और K. Thompson, “Password Security: A Case History”, Communications of the ACM, 1979 · N. Provos और D. Mazières, “A Future-Adaptable Password Scheme”, USENIX Annual Technical Conference, 1999 (bcrypt) · C. Percival, “Stronger Key Derivation via Sequential Memory-Hard Functions”, 2009 (scrypt) · Password Hashing Competition, विजेता Argon2, 2015.