bcrypt से Argon2id पर जाएँ—गलत पैरामीटर सुरक्षा लाभ घटा देते हैं

bcrypt से Argon2id पर जाने के लिए नए खातों, पासवर्ड रीसेट और पासवर्ड परिवर्तन पर Argon2id हैश बनाएं। पुराने खाते में पहले संग्रहित bcrypt हैश से दर्ज पासवर्ड सत्यापित करें। सत्यापन सफल हो तो उसी दर्ज पासवर्ड का Argon2id हैश बनाकर पुराना रिकॉर्ड बदलें। इस तरह सभी उपयोगकर्ताओं से एक साथ पासवर्ड रीसेट कराने की जरूरत नहीं पड़ती।

नए एल्गोरिदम का नाम चुनना ही पर्याप्त नहीं है। Argon2id की स्मृति, चक्र और समांतरता इतनी होनी चाहिए कि चोरी हुए हैश पर पासवर्ड आजमाना महंगा पड़े, लेकिन वैध प्रवेश के समय सर्वर की क्षमता न चुक जाए। पुराने bcrypt रिकॉर्ड तब तक बने रहेंगे जब तक संबंधित उपयोगकर्ता दोबारा प्रवेश नहीं करता; इसलिए संक्रमण की समाप्ति के लिए निष्क्रिय खातों की नीति भी तय करनी होगी।

पुराने और नए हैश की पहचान करें

प्रवेश सेवा को संग्रहित रिकॉर्ड से उसका एल्गोरिदम पहचानना चाहिए। यदि मौजूदा हैश स्वरूप में विधि और उसके पैरामीटर दर्ज हैं, तो सत्यापनकर्ता वही जानकारी पढ़े। यदि पुराना भंडारण विधि नहीं बताता, तो स्थानांतरण से पहले अलग विधि पहचान जोड़ें और मौजूदा रिकॉर्ड सही ढंग से चिह्नित करें। केवल लंबाई देखकर हैश की विधि का अनुमान लगाना भरोसेमंद आधार नहीं है।

संक्रमण के दौरान प्रवेश सेवा दोनों विधियों से बने रिकॉर्ड स्वीकार करेगी, जबकि नया खाता और पासवर्ड बदलने का हर रास्ता केवल चुने हुए Argon2id विन्यास से हैश बनाएगा। संग्रहित हैश के साथ एल्गोरिदम और लागत के मान सुरक्षित रखने से पुराने रिकॉर्ड का सत्यापन और बाद में कमजोर Argon2id विन्यास का उन्नयन संभव रहता है। पासवर्ड या पूरा हैश अनुप्रयोग के लॉग में दर्ज न करें।

स्मृति, चक्र और समांतरता के मान चुनें

OWASP की पासवर्ड भंडारण सलाह Argon2id का एक शुरुआती विन्यास 19 MiB स्मृति, दो चक्र और एक समांतरता बताती है; वह bcrypt को उन पुराने तंत्रों तक सीमित रखती है जहाँ Argon2 या scrypt उपलब्ध नहीं हैं। यह किसी खास उत्पादन सर्वर पर सुरक्षित विलंब की गारंटी नहीं है। पुस्तकालय में स्मृति की इकाई भी देखें: कुछ विन्यास इसे KiB में लेते हैं, जहाँ 19 MiB के लिए मान 19456 होगा।

RFC 9106 का सीमित स्मृति वाला विकल्प Argon2id के लिए 64 MiB स्मृति, तीन चक्र और चार लेन देता है। दोनों सिफारिशें अलग उद्देश्य वाले शुरुआती विकल्प हैं; किसी एक को बिना मापे हर सेवा पर लागू नहीं किया जा सकता। स्मृति का मान एक हैश गणना की कुल निर्धारित स्मृति बताता है, हर लेन के लिए अलग आवंटन नहीं। समांतरता की लेन और एक साथ आने वाले प्रवेश अनुरोध भी अलग चीजें हैं।

पहले तय करें कि प्रवेश अनुरोध के लिए कितना समय और कितनी स्मृति स्वीकार्य है। फिर वास्तविक उत्पादन मशीन जैसी क्षमता पर उम्मीदवार विन्यास से हैश बनाने और सत्यापित करने का समय मापें। केवल खाली सर्वर पर एक गणना का समय पर्याप्त नहीं: समवर्ती अनुरोध अपनी-अपनी स्मृति लेते हैं और उसी मशीन पर अनुप्रयोग की दूसरी प्रक्रियाएँ भी चलती हैं। यदि सीमित स्मृति वाला इंस्टेंस बार-बार सीमा छूता है, तो अनुरोधों की समवर्ती संख्या, सेवा क्षमता और विन्यास को साथ देखकर निर्णय लें।

सफल प्रवेश पर bcrypt रिकॉर्ड बदलें

पुराना हैश देखकर मूल पासवर्ड वापस नहीं निकाला जा सकता। उपयोगकर्ता के उसे दर्ज करने पर ही नए एल्गोरिदम से सीधा हैश बनाया जा सकता है। संग्रहित bcrypt हैश को Argon2id का इनपुट बनाकर स्थायी रिकॉर्ड रखना इस लक्ष्य को पूरा नहीं करता: पुरानी हैश परत बनी रहती है और बाद में सीधे पासवर्ड से बना हैश फिर भी चाहिए होगा।

1. रिकॉर्ड की विधि पहचान पढ़ें और उसी विधि से दर्ज पासवर्ड सत्यापित करें। गलत पासवर्ड पर रिकॉर्ड न बदलें; उपयोगकर्ता को मिलने वाला त्रुटि संदेश संग्रहित विधि उजागर न करे।
2. bcrypt सत्यापन सफल हो तो दर्ज पासवर्ड से चुने गए स्मृति, चक्र और समांतरता मानों पर Argon2id हैश बनाएं। पुस्तकालय को प्रत्येक पासवर्ड के लिए अलग सॉल्ट बनाने दें और सत्यापन के लिए जरूरी पूरा हैश स्वरूप सहेजें।
3. डेटाबेस में नया मान तभी लिखें जब रिकॉर्ड अभी भी वही bcrypt हैश हो जिसका सत्यापन किया गया था। यह सशर्त अद्यतन लगभग एक साथ हुए प्रवेश या पासवर्ड परिवर्तन में नए मान को पुराने अनुरोध से मिटने से बचाता है।
4. यदि सशर्त अद्यतन विफल हो, तो दोबारा रिकॉर्ड पढ़ें। हाल में पासवर्ड बदला गया हो तो पुराने सत्यापन के आधार पर प्रवेश पूरा न करें; वर्तमान रिकॉर्ड के विरुद्ध पासवर्ड फिर जांचें या उपयोगकर्ता से दोबारा प्रवेश कराएं।

डेटाबेस की अस्थायी लिखने की त्रुटि को गलत पासवर्ड बताकर छिपाने के बजाय उसे दर्ज करें और अगली सफल प्रवेश पर उन्नयन दोहराएं। साथ ही शेष bcrypt रिकॉर्ड की गिनती और सफल उन्नयन की दर देखें। इन मापों के लिए पासवर्ड या पूरा हैश संग्रहित करने की जरूरत नहीं है।

उत्पादन भार और कमजोर पासवर्ड का जोखिम

चुने हुए मानों की जाँच प्रवेश, पासवर्ड रीसेट और पासवर्ड परिवर्तन के वास्तविक रास्तों पर करें। सामान्य तथा व्यस्त समय का विलंब, उपलब्ध स्मृति और साथ चल रही हैश गणनाएँ देखें। विफल प्रवेश प्रयास भी सत्यापन पर संसाधन खर्च करते हैं; इसलिए प्रवेश प्रयासों की बाढ़ में व्यवहार मापना जरूरी है। अधिक लागत वाला विन्यास वैध प्रवेश को धीमा करे तो पहले सेवा की क्षमता और समवर्ती अनुरोधों की सीमा जांचें, फिर पैरामीटर समायोजित करें।

वास्तविक परियोजनाओं पर Argon2 अध्ययन में सार्वजनिक सॉफ्टवेयर भंडारों की जाँची गई तैनातियों में 46.6% के पैरामीटर OWASP की सिफारिश से कमजोर मिले। उसी अध्ययन के आर्थिक मॉडल में स्मृति बहुत बढ़ाने पर अतिरिक्त सुरक्षा लाभ घटा और कमजोर पासवर्ड अधिक मजबूत विन्यास के साथ भी जोखिम में रहे। यह प्रतिशत जाँचे गए भंडारों का परिणाम है, सभी उत्पादन सेवाओं का अनुमान नहीं। हैश लागत तय करने के साथ सामान्य तथा पहले से उजागर पासवर्ड रोकने की नीति भी रखें।

निष्क्रिय खातों के लिए समाप्ति नीति तय करें

जो उपयोगकर्ता लौटता ही नहीं, उसके रिकॉर्ड को सफल प्रवेश के जरिए बदला नहीं जा सकता। पुराने bcrypt रिकॉर्ड कितने समय तक स्वीकार होंगे, यह पहले तय करें। अवधि पूरी होने पर निष्क्रिय खाते का पुराना हैश समाप्त करके अगले प्रवेश पर पासवर्ड रीसेट मांगना एक विकल्प है। इस फैसले में सहायता टीम पर पड़ने वाला भार और उपयोगकर्ता को दी जाने वाली सूचना भी शामिल करें, ताकि क्रमिक स्थानांतरण अनिश्चितकाल तक अधूरा न रहे।

यह भी पढ़ें:

• Substack Creator Kit मिला? 100 सशुल्क सदस्य सिर्फ प्रवेश-द्वार हैं
• Qwen3.8-Flash-Next खुला—Qwen4 की झलक में सिर्फ 6 अरब सक्रिय पैरामीटर
• विदेश से दूरस्थ काम: 182 दिन अकेले आपका कर उत्तर नहीं देते