bcrypt बनाम Argon2: पासवर्ड हैशिंग की सेटिंग्स कैसे चुनें

पासवर्ड हैशिंग किस समस्या को हल कर रही है\n\nपासवर्ड हैशिंग बैकएंड को पासवर्ड को सीधे स्टोर किए बिना उसे संभालने देती है। जब कोई साइन अप करता है, तो सर्वर पासवर्ड को एक वन‑वे फंक्शन में चलाता है और परिणाम (हैश) सेव करता है। लॉगिन पर, उपयोगकर्ता के टाइप किए पासवर्ड को फिर से हैश करके स्टोर किए परिणाम से तुलना की जाती है।\n\nहैश एन्क्रिप्शन नहीं है। इसे डिक्रिप्ट करने का कोई तरीका नहीं है। यही वन‑वे गुण पासवर्ड के लिए हैशिंग का कारण है।\n\nतो फिर सामान्य तेज़ हैश जैसे SHA‑256 क्यों नहीं? क्योंकि तेज़ वही चीज़ है जो हमलावर चाहते हैं। अगर डेटाबेस चोरी हो जाए, तो हमलावर पासवर्ड एक‑एक करके लॉगिन करके नहीं आज़माते। वे ऑफ़लाइन हैश लिस्ट पर अनुमान चलाते हैं और अपने हार्डवेयर की शक्ति जितनी तेज़ी से हो सके उतनी कोशिशें भेजते हैं। GPUs के साथ तेज़ हैश को बहुत बड़े पैमाने पर टेस्ट किया जा सकता है। यूनिक साल्ट के साथ भी, एक तेज़ हैश ब्रूट‑फोर्स करने में सस्ता रहता है।\n\nयहाँ वास्तविक विफलता का परिदृश्य है: एक छोटा वेब ऐप अपना यूज़र टेबल ब्रिच में खो देता है। हमलावर के पास ईमेल और पासवर्ड हैश आ जाते हैं। यदि वे हैश तेज़ फंक्शन से बने थे, तो सामान्य पासवर्ड और छोटे संशोधन जल्दी टूट जाते हैं। फिर हमलावर वही पासवर्ड अन्य साइट्स पर आज़माता है (क्रेडेंशियल स्टफिंग), या आपके ऐप के अंदर उच्च‑प्रिविलेज फीचर्स तक पहुँचने की कोशिश करता है।\n\nएक अच्छा पासवर्ड हैश अनुमान लगाने को महंगा बना देता है। लक्ष्य "अटूट" नहीं है—लक्ष्य यह है कि "इतना धीमा और महंगा कि इसे आजमाना फायदे का नहीं रहे।"\n\nएक पासवर्ड हैशिंग सेटअप को होना चाहिए:\n\n- वन‑वे (वेरिफाई करें, रिवर्स न करें)\n- प्रति अनुमान धीमा\n- समानांतर हार्डवेयर (खासकर GPUs) के लिए महंगा\n- इतना तेज़ कि असली लॉगिन सामान्य लगे\n- समायोज्य ताकि समय के साथ आप कॉस्ट बढ़ा सकें\n\n## एक मिनट में bcrypt और Argon2\n\nजब आप bcrypt बनाम Argon2 की तुलना करते हैं, आप यह चुन रहे होते हैं कि डेटाबेस लीक के बाद पासवर्ड अनुमान लगाने को किस तरह धीमा किया जाए।\n\nbcrypt पुराना और व्यापक रूप से सपोर्टेड विकल्प है। इसे CPU‑महंगा बनाने के लिए डिज़ाइन किया गया है, और इसका मुख्य ट्यूनिंग नॉब एक ही है: कॉस्ट फैक्टर। यह "बोरिंग" है, और अच्छी तरह से: लाइब्रेरी में आसानी से मिलता है, तैनाती आसान है, और अनुमान लगाना पूर्वानुमेय है।\n\nArgon2 नया है और मेमोरी‑हार्ड के रूप में डिज़ाइन किया गया था। यह हर पासवर्ड अनुमान के लिए RAM का एक महत्वपूर्ण हिस्सा इस्तेमाल करवा सकता है, सिर्फ़ CPU नहीं। यह महत्वपूर्ण है क्योंकि हमलावर अक्सर GPUs या स्पेशलाइज़्ड हार्डवेयर पर बड़े पैमाने पर अनुमान चलाकर जीतते हैं। मेमोरी उस तरह की समानांतरता पर स्केल करना कठिन और महंगा बनाती है।\n\nArgon2 के तीन वेरिएंट हैं:\n\n- Argon2i: कुछ साइड‑चैनल हमलों के खिलाफ रेसिस्टेंस पर जोर\n- Argon2d: GPU रेजिस्टेंस पर जोर, साइड‑चैनल पर कम फोकस\n- Argon2id: दोनों का व्यावहारिक मिश्रण, और पासवर्ड हैशिंग के लिए सामान्य डिफॉल्ट\n\nयदि आपका स्टैक Argon2id सपोर्ट करता है और आप मेमोरी सुरक्षित रूप से ट्यून कर सकते हैं, तो यह आमतौर पर आधुनिक डिफॉल्ट के रूप में सबसे अच्छा होता है। यदि आपको पुराने सिस्टम्स पर अधिकतम कम्पैटिबिलिटी चाहिए, तो bcrypt अभी भी एक ठोस विकल्प है जब इसे पर्याप्त उच्च कॉस्ट फैक्टर के साथ कॉन्फ़िगर किया जाए।\n\n## सुरक्षा गुण जो सबसे ज़्यादा मायने रखते हैं\n\nमूल सवाल सरल है: अगर कोई हमलावर पासवर्ड डेटाबेस चुरा लेता है, तो बड़े पैमाने पर पासवर्ड अनुमान कितने महंगे होंगे?\n\nbcrypt में आप कॉस्ट (वर्क फैक्टर) नियंत्रित करते हैं। अधिक कॉस्ट का मतलब है कि हर अनुमान में अधिक समय लगेगा। इससे हमलावर धीमे होंगे और आपकी अपनी लॉगिन जाँच भी धीमी होगी, इसलिए आप इसे उपयोगकर्ताओं के लिए स्वीकार्य सीमा पर सेट करते हैं।\n\nArgon2id के साथ आप टाइम कॉस्ट के साथ‑साथ मेमोरी‑हार्डनेस जोड़ सकते हैं। हर अनुमान को CPU समय और एक निर्धारित पैटर्न में RAM एक्सेस की आवश्यकता होती है। GPUs गणनात्मक काम में बहुत तेज़ हो सकते हैं, लेकिन जब हर समानांतर अनुमान को पर्याप्त मेमोरी चाहिए होती है तो उनका लाभ बहुत कम हो जाता है।\n\nसाल्ट्स गैर‑वार्तालाप हैं। प्रत्येक पासवर्ड के लिए एक यूनिक, रैंडम साल्ट:\n\n- प्रीकम्प्यूटेड टेबल्स को आपके डेटाबेस में फिर से उपयोग करने से रोकता है\n- सुनिश्चित करता है कि समान पासवर्ड विभिन्न यूज़र्स के लिए समान हैश न दें\n\nसाल्ट कमजोर पासवर्ड को मजबूत नहीं बनाते। वे मुख्य रूप से उस समय आपकी रक्षा करते हैं जब डेटाबेस लीक हो गया हो, क्योंकि वे हमलावरों को हर यूज़र के लिए असली काम करने पर मजबूर करते हैं।\n\n## bcrypt की ताकतें और सीमाएँ जो आपको जाननी चाहिए\n\nbcrypt अभी भी व्यापक रूप से उपयोग किया जाता है, मुख्यतः क्योंकि इसे हर जगह तैनात करना आसान है। यह तब अच्छा मेल खाता है जब आपको व्यापक इंटरऑपरेबिलिटी चाहिए, आपके स्टैक में क्रिप्टो ऑप्शन्स सीमित हों, या जब आप एक सरल ट्यूनिंग लीवर चाहते हों।\n\nसबसे बड़ा "गोटचा" है 72‑बाइट पासवर्ड सीमा। bcrypt केवल पासवर्ड के पहले 72 बाइट्स का उपयोग करता है और बाकी को अनदेखा कर देता है। यह उन लोगों को चौंका सकता है जो लंबे पासफ़्रेज़ या पासवर्ड मैनेजर इस्तेमाल करते हैं।\n\nअगर आप bcrypt चुनते हैं, तो पासवर्ड लंबाई व्यवहार को स्पष्ट करें। या तो एक अधिकतम लंबाई लागू करें (बाइट्स में, अक्षरों में नहीं) या लंबे इनपुट को सभी सेवाओं पर सुसंगत रूप से हैंडल करें। मुख्य बात यह है कि चुपचाप ट्रंकैशन से बचें जो उपयोगकर्ता की उम्मीद के अनुसार पासवर्ड बदल दे।\n\nbcrypt आधुनिक समानांतर क्रैकिंग हार्डवेयर के खिलाफ उतना प्रतिरोधी नहीं है जितना मेमोरी‑हार्ड विकल्प। इसकी रक्षा अभी भी मान्य है, पर यह काफी हद तक इस बात पर निर्भर करती है कि आप प्रत्येक अनुमान को महंगा रखने के लिए कितना कॉस्ट फैक्टर चुनते हैं।\n\nयदि आप नया सिस्टम बना रहे हैं या आपके पास उच्च‑मूल्य खाते हैं (पेड प्लान, एडमिन रोल), तो नए हैशों को Argon2id पर माइग्रेट करना जबकि मौजूदा bcrypt हैशों को तब तक स्वीकार करना जब तक उपयोगकर्ता लॉगिन नहीं करते, एक सामान्य और कम‑जोखिम वाला रास्ता है।\n\n## Argon2 की ताकतें और tradeoffs\n\nArgon2 पासवर्ड हैशिंग के लिए बनाया गया था। Argon2id वह वेरिएंट है जिसे अधिकांश टीमें चुनती हैं क्योंकि यह GPU‑रिसिस्टेंस और साइड‑चैनल सुरक्षा के बीच संतुलन देता है।\n\nArgon2id आपको तीन पैरामीटर देता है:\n\n- Memory (m): कितनी RAM हर हैश चलाते समय उपयोग होती है\n- Time/iterations (t): मेमोरी पर कितनी पास बनाता है\n- Parallelism (p): कितनी lanes इस्तेमाल करता है (मल्टी‑कोर CPU पर मददगार)\n\nमेमोरी मुख्य लाभ है। यदि हर अनुमान को महत्वपूर्ण मात्रा में RAM चाहिए, तो हमलावर बिना भारी RAM और बैंडविड्थ लागत के अधिक अनुमान समानांतर नहीं चला पाएंगे।\n\nनुकसान ऑपरेशनल है: हर हैश के लिए अधिक मेमोरी का मतलब है कि पीक टाइम पर आपके सर्वर कम समकक्ष लॉगिन संभाल पाएंगे। यदि आप मेमोरी बहुत ऊँचा सेट करते हैं, तो लॉगिन बर्स्ट क्व्यूइंग, टाइमआउट या ओवरफ्लो जैसी समस्याएँ कर सकते हैं। आपको दुरुपयोग के बारे में भी सोचना होगा: बहुत सारे समकक्ष लॉगिन प्रयास संसाधन समस्या बना सकते हैं अगर आप काम को सीमित नहीं करते।\n\nArgon2id को सुरक्षित और उपयोग योग्य रखने के लिए, इसे परफॉर्मेंस फीचर की तरह ट्यून करें:\n\n- प्रोडक्शन‑नुमा हार्डवेयर पर बेंचमार्क करें\n- समकक्ष हैशिंग वर्क को सीमित करें (वर्कर कैप्स, कतारें)\n- लॉगिन प्रयासों को रेट‑लिमिट करें और बार‑बार फेल्यर्स पर लॉक‑आउट रखें\n- सेटिंग्स को सेवाओं में संगत रखें ताकि एक कमजोर एंडपॉइंट लक्ष्य न बने\n\n## वास्तविक वेब बैकएंड में प्रदर्शन लागत\n\nपासवर्ड हैशिंग में "तेज़तर बेहतर" आमतौर पर गलत लक्ष्य है। आप चाहते हैं कि हर अनुमान हमलावरों के लिए महंगा हो जबकि असली यूज़र्स के लिए लॉगिन अभी भी स्मूथ रहे।\n\nएक व्यावहारिक तरीका है कि आप अपने वास्तविक प्रोडक्शन हार्डवेयर पर वेरिफिकेशन के लिए एक समय‑बजट तय करें। कई टीमें 100 से 300 ms प्रति हैश चेक के आसपास लक्ष्य रखती हैं, लेकिन सही संख्या आपके ट्रैफ़िक और सर्वरों पर निर्भर है। bcrypt और Argon2 के बीच फर्क यह है कि आप क्या खर्च कर रहे हैं: bcrypt ज्यादातर CPU समय खर्च करता है, जबकि Argon2 मेमोरी भी रिज़र्व कर सकता है।\n\n### लक्ष्य समय चुनें, फिर नापें\n\nएक लक्ष्य हैश समय चुनें और उसको प्रोडक्शन‑नुमा कंडीशन में टेस्ट करें। साइनअप/पासवर्ड‑चेंज हैशिंग और लॉगिन वेरिफिकेशन दोनों को मापें, पर लॉगिन को हॉट पाथ मानें।\n\nएक हल्का‑फुल्का माप योजना:\n\n- 1, 10, और 50 समकक्ष लॉगिन चेक टेस्ट करें और p50 तथा p95 लेटेंसी रिकॉर्ड करें\n- कैशिंग और CPU बूस्टिंग से हुए शोर को कम करने के लिए रन दोहराएँ\n- डेटाबेस कॉल को अलग से मापें ताकि आप जान सकें हैशिंग वास्तव में कितना लागत दे रही है\n- उसी कंटेनर और CPU लिमिट के साथ टेस्ट करें जो आप डिप्लॉय करने वाले हैं\n\n### स्पाइक्स औसत से ज़्यादा मायने रखते हैं\n\nअधिकांश सिस्टम पीक्स के दौरान फेल होते हैं। अगर एक मार्केटिंग ईमेल उपयोगकर्ताओं की एक लहर लॉगिन पेज पर भेज दे, तो आपके हैशिंग सेटिंग्स तय करेंगे कि सिस्टम रिस्पॉन्सिव रहता है या नहीं।\n\nयदि एक वेरिफिकेशन 250 ms लेता है और आपका सर्वर समानांतर में 40 हैंडल कर सकता है इससे पहले कि कतार लगे, तो 500 लॉगिन प्रयासों का बर्स्ट मल्टी‑सेकंड के इंतज़ार में बदल सकता है। ऐसी स्थिति में, थोड़ा सा कॉस्ट कम करना और मजबूत रेट‑लिमिट्स लगाना वास्तविक सुरक्षा में सुधार कर सकता है बनिस्बत पैरामीटर इतने बढ़ाने के कि लॉगिन एंडपॉइंट नाज़ुक बन जाए।\n\n### इंटरएक्टिव लॉगिन को पूर्वानुमेय रखें\n\nहर पासवर्ड ऑपरेशन को समान तात्कालिकता की ज़रूरत नहीं होती। इंटरएक्टिव लॉगिन कॉस्ट को स्थिर रखें, फिर भारी काम को क्रिटिकल पाथ के बाहर करें। एक सामान्य पैटर्न है rehash-on-login (सफल लॉगिन के तुरंत बाद यूज़र का हैश अपग्रेड करना) या माइग्रेशन और इम्पोर्ट के लिए बैकग्राउंड जॉब्स।\n\n## चरणबद्ध तरीके से पैरामीटर कैसे चुनें\n\nपैरामीटर ट्यूनिंग का लक्ष्य हमलावर पर प्रति अनुमान लागत बढ़ाना है बिना साइन‑इन्स को धीमा किए या सर्वरों को अस्थिर किए।\n\n1. ऐल्गोरिथ्म चुनें जिसे आपका स्टैक अच्छी तरह सपोर्ट करता हो। यदि Argon2id उपलब्ध और अच्छी तरह समर्थित है, तो यह सामान्य डिफॉल्ट है। यदि व्यापक कम्पैटिबिलिटी चाहिए तो bcrypt ठीक है।\n\n2. प्रोडक्शन‑नुमा हार्डवेयर पर प्रति हैश एक लक्ष्य समय सेट करें। ऐसा कुछ चुनें जो पीक लोड के दौरान लॉगिन को स्मूद रखे।\n\n3. उस समय को प्राप्त करने के लिए ट्यून करें। bcrypt में कॉस्ट फैक्टर बदलें। Argon2id में मेमोरी, इटरेशन्स और पैरेललिज्म का संतुलन करें। मेमोरी वह लीवर है जो हमलावर की अर्थव्यवस्था को सबसे ज़्यादा बदलता है।\n\n4. हैश के साथ ऐल्गोरिथ्म और सेटिंग्स स्टोर करें। अधिकांश स्टैंडर्ड हैश फॉर्मैट इन विवरणों को एम्बेड करते हैं। यह भी सुनिश्चित करें कि आपका डेटाबेस फील्ड लंबा genug हो ताकि हैश कभी कट न जाए।\n\n5. रिहैश‑ऑन‑लॉगिन के साथ अपग्रेड प्लान रखें। जब यूज़र लॉगिन करे, तो अगर उनका स्टोर्ड हैश आपकी वर्तमान नीति से कमजोर है तो नया हैश बनाकर उसे बदल दें।\n\n### एक व्यावहारिक प्रारंभिक बिंदु\n\nअगर आपको मापन से पहले एक बेसलाइन चाहिए, तो सुरक्षात्मक रूप से शुरुआत करें और समय के साथ समायोजित करें।\n\n- bcrypt के लिए, कई टीमें शुरुआत में cost 12 के आसपास से शुरू करती हैं और वास्तविक मापों के आधार पर बदलती हैं।\n- Argon2id के लिए, एक आम बेसलाइन है कुछ दसों से कुछ सौ MB मेमोरी, time cost 2 से 4, और parallelism 1 से 2।\n\nइन्हें नियम नहीं बल्कि प्रारंभिक बिंदु समझें। सही सेटिंग्स वही हैं जो आपके ट्रैफ़िक, हार्डवेयर और पीक लॉगिन बर्स्ट्स के अनुरूप बैठती हों।\n\n## पासवर्ड स्टोरेज को कमजोर करने वाली सामान्य गलतियाँ\n\nअधिकांश विफलताएँ सेटअप गैप से आती हैं, न कि किसी एल्गोरिथ्म की विफलता से।\n\nसाल्ट गलतियाँ बड़ी होती हैं। प्रत्येक पासवर्ड के लिए अपना यूनिक साल्ट होना चाहिए और उसे हैश के साथ स्टोर करें। साल्ट्स को रीयूज़ करना, या सभी यूज़र्स के लिए एक ग्लोबल साल्ट इस्तेमाल करना, हमलावरों को काम पुन: उपयोग करने और अकाउंट्स की तुलना करने में आसान बनाता है।\n\nकॉस्ट उपेक्षा एक अन्य है। टीमें अक्सर कम कॉस्ट के साथ शिप करती हैं क्योंकि लॉगिन तेज़ लगता है, फिर कभी इसकी समीक्षा नहीं करतीं। हार्डवेयर सुधरता है, हमलावर बड़े होते हैं, और आपकी कभी‑ठीक सेटिंग्स सस्ती हो जाती हैं।\n\nArgon2 ओवर‑ट्यूनिंग भी आम है। मेमोरी को बेहद ऊँचा सेट कर देना कागज़ पर अच्छा दिख सकता है, पर वास्तविक स्पाइक्स में धीरे‑धीरे लॉगिन, रिक्वेस्ट बैकलॉग या आउट‑ऑफ‑मेमोरी त्रुटियाँ पैदा कर सकता है।\n\nपासवर्ड लंबाई हैंडलिंग महत्वपूर्ण है, खासकर bcrypt की 72‑बाइट व्यवहार के साथ। अगर आप लंबी पासवर्ड की अनुमति देते हैं पर चुपचाप उन्हें ट्रंकैट करते हैं, तो आप भ्रम और सुरक्षा की कमी पैदा करते हैं।\n\nइनमें से अधिकतर रोकथाम के व्यावहारिक अभ्यास हैं:\n\n- यूनिक प्रति‑पासवर्ड साल्ट का उपयोग करें (लाइब्रेरी से जेनरेट कराएँ)\n- लोड‑टेस्ट और समय‑समय पर सेटिंग्स की समीक्षा करें\n- Argon2 मेमोरी को पीक ट्रैफ़िक के लिए ट्यून करें, सिर्फ़ सिंगल‑लॉगिन बेंचमार्क नहीं\n- पासवर्ड लंबाई सीमाएँ स्पष्ट और सुसंगत रखें\n- लॉगिन एंडपॉइंट के चारों ओर कॉन्करेंसी लिमिट और मॉनिटरिंग रखें\n\n## सुरक्षित सेटअप के लिए त्वरित चेकलिस्ट\n\nशिप करते समय और इन्फ्रास्ट्रक्चर बदलते समय यह शॉर्ट लिस्ट साथ रखें:\n\n- प्रति पासवर्ड यूनिक साल्ट, रैंडम रूप से जेनरेट और हैश के साथ स्टोर किया गया\n- हैशिंग कॉस्ट जो पीक ट्रैफ़िक सह सके, प्रोडक्शन‑नुमा हार्डवेयर पर लोड‑टेस्ट के साथ सत्यापित\n- हैश के साथ पैरामीटर स्टोर किए हुए, ताकि आप पुराने अकाउंट्स को वेरिफाई करके बाद में कॉस्ट बढ़ा सकें\n- ऑनलाइन अटैक नियंत्रण, जिनमें रेट‑लिमिट्स और बार‑बार फेल्यर्स के लिए छोटे लॉकआउट शामिल हों\n- एक अपग्रेड पथ, सामान्यतः rehash-on-login\n\nएक सरल सैनीटी चेक: स्टेजिंग टेस्ट चलाएँ जिसमें सफल और असफल दोनों प्रकार के लॉगिन बर्स्ट शामिल हों और एंड‑टू‑एंड लेटेंसी के साथ CPU और RAM उपयोग देखें। अगर लॉगिन पाथ संघर्ष कर रहा है, तो कॉस्ट और रेट‑लिमिट्स को ट्यून करें। इसे "ठीक" करने के लिए साल्ट जैसी अनिवार्य चीज़ों को काटें नहीं।\n\n## एक वास्तविक उदाहरण: एक छोटे वेब ऐप के लिए ट्यूनिंग\n\nकल्पना कीजिए एक छोटे SaaS ऐप की जिसके कुछ हज़ार यूज़र्स हैं। ज्यादातर दिन स्थिरता रहती है, पर न्यूज़लेट्टर भेजने के बाद या वर्क‑डे की शुरुआत में छोटे लॉगिन बर्स्ट्स आते हैं। यहाँ चुनाव क्षमता नियोजन बन जाता है।\n\nआप ऑफ़लाइन क्रैकिंग की लागत बढ़ाने के लिए Argon2id चुनते हैं। अपने असली सर्वर हार्डवेयर पर एक लक्ष्य वेरिफिकेशन समय चुनें (उदाहरण के लिए 100–250 ms), फिर पैरामीटर को इस पर ट्यून करें और RAM पर नज़र रखें, क्योंकि मेमोरी सेटिंग्स यह निर्धारित कर सकती हैं कि आप एक साथ कितने लॉगिन हैंडल कर सकते हैं।\n\nएक व्यावहारिक ट्यूनिंग लूप ऐसा दिखता है:\n\n- मामूली इटरेशन्स और पैरेललिज्म से शुरू करें\n- तब तक मेमोरी बढ़ाएँ जब तक कॉन्करेंसी असहज न लगे\n- समय कॉस्ट को फाइन‑ट्यून करने के लिए इटरेशन्स समायोजित करें\n- सिम्युलेटेड बर्स्ट्स के साथ फिर से टेस्ट करें, सिर्फ़ सिंगल रिक्वेस्ट नहीं\n\nअगर आपके पास पहले से कमजोर सेटिंग्स वाले पुराने हैश हैं, तो उन्हें वेरिफाई करना जारी रखें पर चुपचाप अपग्रेड करें। सफल लॉगिन पर rehash करके नया वैल्यू सेव करें। समय के साथ सक्रिय उपयोगकर्ता मजबूत हैशों पर आ जाएंगे बिना फोर्स्ड रिसेट के।\n\nरिलीज़ के बाद लॉगिन की निगरानी किसी अन्य महत्वपूर्ण एंडपॉइंट की तरह करें: लेटेंसी (p95/p99), बर्स्ट्स के दौरान CPU और RAM, फेल्ड‑लॉगिन स्पाइक्स, और कितनी तेज़ी से पुराने हैश रिप्लेस हो रहे हैं।\n\n## अगले कदम: सुरक्षित तैनाती और सतत सुधार\n\nअपनी नीति लिखकर रखें और इसे एक जीवित सेटिंग मानें। उदाहरण के लिए: “Argon2id with X memory, Y iterations, Z parallelism” या “bcrypt cost factor N,” साथ में तारीख जब आपने इसे चुना और कब समीक्षा करेंगे (हर 6–12 महीने अच्छा प्रारंभिक अंतराल है)।\n\nअपग्रेड पथ रखें ताकि आप पुराने हैशों के साथ फंस न जाएँ। rehash-on-login सरल है और अधिकांश सिस्टम में अच्छी तरह काम करता है।\n\nएक मजबूत हैश मददगार है, पर यह ऑनलाइन अटैक नियंत्रण की जगह नहीं लेता। रेट‑लिमिट्स, लॉकआउट्स, और सावधान पासवर्ड‑रीसेट फ्लोज़ असली‑दुनिया की सुरक्षा के लिए उतने ही महत्वपूर्ण हैं।\n\nयदि आप अपना बैकएंड no-code प्लेटफ़ॉर्म जैसे AppMaster पर बना रहे हैं, तो यह जांचने लायक है कि आपका ऑथेंटिकेशन मॉड्यूल डिफॉल्ट रूप से मजबूत पासवर्ड हैशिंग का उपयोग करता है और कि आपकी हैशिंग कॉस्ट उसी तरह के इन्फ्रास्ट्रक्चर पर ट्यून की गई है जहां आप तैनात करेंगे। यह छोटा‑सा प्रारंभिक परीक्षण अक्सर “सिक्योर और स्मूद” और “सिक्योर पर लोड पर अनुपयोगी” के बीच फर्क तय कर देता है।