सुरक्षा में सॉल्टिंग क्या है? पासवर्ड हैशिंग की व्याख्या

जून 2012 में, एक हमलावर ने 117 मिलियन लिंक्डइन अकाउंट रिकॉर्ड एक रूसी फोरम पर लीक कर दिए। यह सूची बिना सॉल्ट वाले SHA-1 हैश का एक विशाल संग्रह थी। SHA-1 बहुत तेज़ है। एक जैसे पासवर्ड को अलग करने के लिए सॉल्ट के बिना, एक ही हैश हजारों बार एक दूसरे के बगल में मौजूद था। लगभग बहत्तर घंटों के भीतर, सुरक्षा शोधकर्ताओं ने फ़ाइल का लगभग 90 प्रतिशत हिस्सा क्रैक कर लिया था। जब मई 2016 में 167 मिलियन रिकॉर्ड के डेटासेट के हिस्से के रूप में यह डेटा लीक फिर से सामने आया, तो इन क्रेडेंशियल्स का इस्तेमाल कई सालों तक क्रेडेंशियल-स्टफिंग अभियानों में किया गया।

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

आधुनिक पासवर्ड संग्रहण में होने वाली अधिकांश विफलताओं का मूल कारण अभी भी एक ही है: किसी ने यह मान लिया कि "हम SHA-256 का उपयोग करते हैं" पर्याप्त है। यह लेख बताता है कि वास्तव में सॉल्टिंग क्या है, यह व्यवहार में कैसे काम करता है, यह किन चीज़ों से सुरक्षा प्रदान करता है और किनसे नहीं, और OWASP 2026 के डिफ़ॉल्ट के रूप में क्या अनुशंसा करता है।

सुरक्षा और पासवर्ड हैशिंग में सॉल्टिंग क्या है?

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

हैशिंग अपने आप में एकतरफा प्रक्रिया है। पासवर्ड को SHA-256 या Argon2id से गुजारने पर आपको एक निश्चित लंबाई का मान मिलता है जिसे कोई भी एल्गोरिदम उलट नहीं सकता। लेकिन "कोई एल्गोरिदम नहीं" का मतलब है एक आसान तरीका - पहले से तैयार डिक्शनरी में हैश को खोजना। सॉल्टिंग इस आसान तरीके को खत्म कर देता है। हैशिंग प्रक्रिया में सॉल्ट जोड़ने से प्रत्येक उपयोगकर्ता के लिए एक अद्वितीय हैश बनता है, भले ही उनके पासवर्ड का मूल पाठ शब्द-दर-शब्द समान हो। "password" और "qwerty" जैसे सामान्य पासवर्ड अब डेटाबेस में आपस में नहीं टकराते। सॉल्टिंग यह सुनिश्चित करता है कि एक पंक्ति के लीक होने से हमलावर को किसी अन्य के बारे में कुछ भी पता न चले।

तीन नियम उपयोगी सॉल्ट को अनुपयोगी सॉल्ट से अलग करते हैं। पहला नियम: प्रत्येक पासवर्ड को अपना एक यादृच्छिक सॉल्ट मिलता है, जो उपयोगकर्ता के साइन अप करने या रीसेट करने पर नया जनरेट होता है। खातों में बार-बार उपयोग किया जाने वाला सॉल्टेड पासवर्ड, बिना सॉल्ट वाले पासवर्ड से शायद ही बेहतर होता है - बल्क अटैक उसी तरह काम करता है। दूसरा नियम: सॉल्ट सार्वजनिक हो सकता है। केवल सॉल्ट जानने से हमलावर को अंतर्निहित हैश फ़ंक्शन के विरुद्ध कोई शॉर्टकट नहीं मिलता। इसलिए सॉल्ट डेटाबेस में हैश के साथ ही रहता है, और यह स्थान सुरक्षित है, बल्कि प्रोत्साहित भी किया जाता है। तीसरा नियम: सॉल्ट मान क्रिप्टोग्राफ़िक रूप से सुरक्षित स्यूडोरैंडम संख्या जनरेटर से प्राप्त होते हैं। Linux इसे `getrandom(2)` के माध्यम से उपलब्ध कराता है। Node इसे `crypto.randomBytes` कहता है। Python की मानक लाइब्रेरी इसे `secrets.token_bytes` में रैप करती है। गैर-क्रिप्टोग्राफ़िक `Math.random()` अनुपयुक्त है, भले ही यह वास्तविक ऑडिट किए गए कोड में अपेक्षित से कहीं अधिक बार दिखाई देता है।

दो लोग जो "hunter2" को अपना पासवर्ड चुनते हैं, उनके पास दो पूरी तरह से अलग-अलग हैश होने चाहिए। सॉल्टिंग ही ऐसा संभव बनाती है। यदि सॉल्ट का उपयोग नहीं किया जाता है, तो डेटाबेस न केवल हैश लीक करता है, बल्कि यह जानकारी भी लीक कर देता है कि कौन किसके साथ कौन सा पासवर्ड साझा करता है।

पासवर्ड सॉल्टिंग कैसे काम करता है?

यह तंत्र चार चरणों में विभाजित होता है, और पासवर्ड-भंडारण उल्लंघनों के दस वर्षों से पता चलता है कि लगभग हर विफलता इसलिए होती है क्योंकि किसी ने उनमें से एक चरण को छोड़ दिया था।

पहला चरण पंजीकरण के समय चलता है। एप्लिकेशन एक CSPRNG से सोलह से बत्तीस यादृच्छिक बाइट्स मांगता है। यही सॉल्ट कहलाता है। OWASP के 2025 के दिशानिर्देश सोलह बाइट्स (128 बिट्स) को न्यूनतम सीमा मानते हैं; auth0 और कई पासवर्ड-मैनेजर विक्रेता बत्तीस बाइट्स तक जाने की सलाह देते हैं। NIST का SP 800-63B-4 चार बाइट्स की न्यूनतम सीमा निर्धारित करता है, लेकिन चेतावनी देता है कि इस आकार पर लगभग पैंसठ हज़ार उपयोगकर्ताओं के आसपास जन्मदिन से संबंधित टकराव दिखाई देने लगते हैं, यही कारण है कि वास्तव में कोई भी चार बाइट्स का उपयोग नहीं करता है।

दूसरे चरण में नमक को उपयोगकर्ता द्वारा चुने गए पासवर्ड के साथ मिलाया जाता है। सबसे आम तरीका है पासवर्ड स्ट्रिंग से पहले या बाद में नमक को जोड़कर पासवर्ड को संयोजित करना। कुछ सिस्टम इसके बजाय HMAC का उपयोग करते हैं, जिसमें नमक को HMAC कुंजी के रूप में माना जाता है, जिससे सीधे संयोजन से उत्पन्न होने वाली लंबाई-विस्तार संबंधी कुछ अस्पष्ट समस्याओं से बचा जा सकता है।

तीसरे चरण में संयुक्त इनपुट को पासवर्ड-हैशिंग एल्गोरिदम से गुज़ारा जाता है—जिसे क्रिप्टोग्राफी की पाठ्यपुस्तकों में कुंजी व्युत्पत्ति फ़ंक्शन (KDF) कहा जाता है। यही वह चरण है जहाँ अधिकांश टीमें अक्सर गलती करती थीं, क्योंकि वे एक सामान्य हैश एल्गोरिदम का उपयोग करके काम को पूरा मान लेती थीं। साधारण SHA-256 अकेले पासवर्ड को संग्रहीत करने के लिए उपयुक्त नहीं है। 2026 में एक उपभोक्ता GPU प्रति सेकंड एक सौ अरब से अधिक SHA-256 हैश को संसाधित करता है, इसलिए सॉल्ट के साथ भी क्रिप्टोग्राफिक हैशिंग में प्रति अनुमान लागत नगण्य रहती है। सॉल्टिंग रेनबो टेबल अटैक वेक्टर को खत्म कर देता है। यह अकेले ब्रूट फ़ोर्स द्वारा पासवर्ड क्रैकिंग को धीमा नहीं करता है। यहाँ सही उपकरण जानबूझकर धीमा, मेमोरी-कठिन फ़ंक्शन है: OWASP द्वारा पसंदीदा डिफ़ॉल्ट Argon2id है, scrypt और bcrypt स्वीकार्य हैं, और PBKDF2 बहुत उच्च पुनरावृति गणनाओं के साथ अनुमत है जहाँ FIPS-140 अनुपालन विकल्प को बाध्य करता है।

चौथे चरण में हैश और सॉल्ट दोनों को स्टोर किया जाता है। आधुनिक लाइब्रेरी स्टोरेज फॉर्मेट को संभालती हैं, इसलिए आपको स्टोर किए गए सॉल्ट को मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं है। bcrypt का आउटपुट `$2b$12$9f4c8a7b...kQR8YZpL9` जैसा दिखता है — इस एक स्ट्रिंग में एल्गोरिदम पहचानकर्ता, लागत कारक, सॉल्ट और हैश मान होता है। Argon2id भी इसी तरह के PHC स्ट्रिंग फॉर्मेट का उपयोग करता है, `$argon2id$v=19$m=19456,t=2,p=1$$`। आप इस स्ट्रिंग को डेटाबेस कॉलम में लिखते हैं और निश्चिंत हो जाते हैं। लाइब्रेरी ने पासवर्ड को सुरक्षित रूप से स्टोर करने के लिए आवश्यक सभी कार्य कर दिए हैं — सॉल्ट के लिए रैंडम डेटा जनरेट किया, पासवर्ड को एक धीमे हैश एल्गोरिदम से गुजारा और परिणाम को पुनः प्राप्त करने के लिए बंडल किया।

लॉगिन प्रक्रिया उल्टे क्रम में इसी प्रक्रिया का अनुसरण करती है। एप्लिकेशन उपयोगकर्ता के सॉल्ट और संग्रहीत हैश को देखता है, सबमिट किए गए पासवर्ड को उसी सॉल्ट के साथ उसी एल्गोरिदम से गुजारता है, और स्थिर समय तुलना का उपयोग करके परिणाम की तुलना संग्रहीत हैश से करता है। स्थिर समय महत्वपूर्ण है: एक साधारण `==` मिलान किए गए बाइट्स की संख्या के बारे में जानकारी लीक कर देता है, जिससे वास्तविक समय-हमले की कमजोरियां उत्पन्न हो सकती हैं। `hmac.compare_digest`, `crypto.timingSafeEqual`, या आपके फ्रेमवर्क के समकक्ष का उपयोग करें।

नमक डालना क्यों महत्वपूर्ण है: इंद्रधनुषी भोजन की समस्या

रेनबो टेबल एक विशिष्ट प्रकार का हमला है जिसे रोकने के लिए सॉल्टिंग तकनीक का आविष्कार किया गया था। कल्पना कीजिए एक पूर्व-निर्मित लुकअप टेबल की, जो हर संभावित पासवर्ड—शब्दकोश के हर शब्द, सामान्य भिन्नता, लीक हुई सूची में मौजूद हर प्रविष्टि—को उसके SHA-256 हैश से मैप करती है। ये टेबल मौजूद हैं, क्रैकिंग फ़ोरम पर बेची जाती हैं, और इनका आकार टेराबाइट्स में होता है। एक बार हमलावर के पास अनसॉल्टेड हैश का डेटाबेस डंप आ जाए, तो रेनबो टेबल में हैश खोजना एक डेटाबेस क्वेरी बन जाता है, न कि क्रैकिंग का काम। लिंक्डइन 2012 का मामला ठीक इसी तरह का था: 117 मिलियन अनसॉल्टेड SHA-1 हैश को रेनबो टेबल के विरुद्ध परीक्षण किया गया, जिनमें से नब्बे प्रतिशत लगभग तीन दिनों में क्रैक हो गए।

प्रत्येक उपयोगकर्ता के लिए अलग-अलग सॉल्ट जोड़ने पर रेनबो टेबल काम करना बंद कर देती हैं। हमलावर को प्रत्येक अद्वितीय सॉल्ट मान के लिए एक अलग पूर्व-गणना की गई तालिका की आवश्यकता होगी। सोलह बाइट के यादृच्छिक सॉल्ट के साथ, इसका अर्थ है 117 मिलियन उपयोगकर्ताओं के लिए 117 मिलियन अलग-अलग तालिकाएँ - और प्रत्येक तालिका टेराबाइट में बड़ी होगी। केवल भंडारण लागत ही इसे अव्यवहारिक बना देती है। यह हमला खतरे के मॉडल से बाहर हो जाता है।

यही तो सॉल्ट का पूरा काम है। इसे जानबूझकर सीमित रखा जाता है। सॉल्टिंग किसी एक खास यूजर के खिलाफ किए गए ब्रूट-फोर्स हमले को धीमा नहीं करती। सॉल्टिंग पिछले लीक से हुई क्रेडेंशियल-स्टफिंग को भी नहीं रोकती। अगर पासवर्ड "123456" है, तो भी सॉल्टिंग मददगार नहीं होती - हमलावर आम तौर पर इस्तेमाल होने वाले पासवर्ड को आज़माता है, और हर अनुमान के लिए सॉल्ट की गणना दोबारा की जाती है, लेकिन इससे प्रति अनुमान लागत में कोई खास बदलाव नहीं आता।

सॉल्टिंग से रेनबो टेबल और एक ही डेटाबेस में मौजूद अलग-अलग उपयोगकर्ताओं के बीच पासवर्ड के पुन: उपयोग की जानकारी लीक होने जैसी समस्याओं को विश्वसनीय रूप से कम किया जा सकता है। स्लो हैशिंग से प्रति अनुमान लागत कम होती है। पेप्पर से डेटाबेस-आधारित चोरी कम होती है। मल्टी-फैक्टर ऑथेंटिकेशन (MFA) से क्रेडेंशियल स्टफिंग कम होती है। सॉल्टिंग सुरक्षा की एक परत है - पासवर्ड को क्रैक करना कठिन बनाने के लिए सॉल्ट जोड़ना, प्रत्येक पासवर्ड को व्यक्तिगत रूप से अनुमान लगाना कठिन बनाने के समान नहीं है। प्रत्येक उपयोगकर्ता के लिए एक अलग हैश बनाना सॉल्टिंग का लक्ष्य है; प्रत्येक अनुमान को महंगा बनाना एक अलग समस्या है।

हैशिंग बनाम एन्क्रिप्शन बनाम सॉल्टिंग

तीन ऐसे शब्द हैं जिनमें अक्सर भ्रम पैदा हो जाता है, खासकर गैर-विशेषज्ञों द्वारा लिखे गए लेखों में। ये शब्द एक दूसरे के स्थान पर प्रयोग नहीं किए जा सकते।

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

एडोब का 2013 का डेटा लीक यहाँ एक चेतावनी भरा उदाहरण है। एडोब ने 153 मिलियन उपयोगकर्ता रिकॉर्ड को 3DES का उपयोग करके ECB मोड में एक ही साइट-व्यापी कुंजी के तहत पासवर्ड एन्क्रिप्ट करके संग्रहीत किया था। यह विकल्प तीन गुना विफल रहा। पासवर्ड को सुरक्षित रखने के लिए एन्क्रिप्शन एक उपयुक्त विधि नहीं है। ECB मोड में समान इनपुट से समान आउटपुट लीक हो जाते हैं। पूरे डेटाबेस में एक ही कुंजी का पुन: उपयोग करने का मतलब था कि एक बार कुंजी को डिकोड करने से सभी 153 मिलियन रिकॉर्ड डिकोड हो जाते थे। श्नायर ने इसे इतिहास के सबसे खराब पासवर्ड लीक में से एक बताया। हर स्तर पर इसका समाधान सॉल्टेड, स्लो हैशिंग पर स्विच करना था।

नमक बनाम काली मिर्च: दोहरी रक्षा प्रणाली

पेपर, सॉल्ट का कम जाना-पहचाना रिश्तेदार है। अवधारणा यह है: एक अतिरिक्त गुप्त मान, जिसे एप्लिकेशन द्वारा प्रोसेस किए जाने वाले प्रत्येक पासवर्ड पर लागू किया जाता है, लेकिन डेटाबेस से बाहर संग्रहीत किया जाता है। यह एक पर्यावरण चर, एक कुंजी-प्रबंधन सेवा प्रविष्टि, या एक HSM-निवासी कुंजी हो सकती है। सॉल्ट, हैश के बगल में सादे पाठ में मौजूद होता है। पेपर ऐसा नहीं होता।

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

एक सामान्य कार्यान्वयन में `argon2id(salt + password + pepper)` चलाया जाता है या, अधिक सावधानी से, पहले `HMAC(pepper, password + salt)` की गणना की जाती है और परिणाम को Argon2id में फीड किया जाता है। OWASP उच्च-मूल्य वाले सिस्टमों के लिए pepper की अनुशंसा करता है, लेकिन इसके नुकसान को भी स्वीकार करता है: pepper को रोटेट करना परिचालन की दृष्टि से कठिन है। इसे रोटेट करने का अर्थ है अगले लॉगिन पर प्रत्येक उपयोगकर्ता के पासवर्ड को पुनः हैश करना, और यदि कभी भी बिना बैकअप के pepper खो जाता है, तो प्रत्येक खाता अप्रमाणित हो जाता है। अधिकांश उपभोक्ता अनुप्रयोग pepper का उपयोग नहीं करते हैं। बैंक, सरकार और स्वास्थ्य सेवा क्षेत्र के कार्यभार आमतौर पर इसका उपयोग करते हैं।

2026 में आधुनिक पासवर्ड हैशिंग

OWASP के 2025 पासवर्ड-स्टोरेज दिशानिर्देशों में चार एल्गोरिदम को प्राथमिकता के क्रम में रखा गया है। साल्ट इन सभी में अंतर्निहित है - आपको इसे मैन्युअल रूप से उत्पन्न करने की आवश्यकता नहीं है।

आर्गन2आईडी मेमोरी-हार्ड है, जिसका अर्थ है कि प्रत्येक अनुमान न केवल सीपीयू साइकल बल्कि रैम का एक निश्चित हिस्सा भी खर्च करता है। प्रति हैश 19 MiB की OWASP न्यूनतम आवश्यकता का मतलब है कि एक कस्टम ASIC बनाने वाले हमलावर को बहुत अधिक तेज़ मेमोरी भी बनानी होगी, और मेमोरी किसी भी रिग का सबसे महंगा हिस्सा होती है। "आईडी" वेरिएंट आर्गन2आई (साइड-चैनल प्रतिरोधी) और आर्गन2डी (जीपीयू प्रतिरोधी) को मिलाकर बनाया गया है, जिसमें पहले आधे हिस्से में आर्गन2आई और दूसरे आधे हिस्से में आर्गन2डी का उपयोग किया जाता है।

scrypt, Argon2id से पहले आया था और उसी मेमोरी-हार्ड सिद्धांत पर काम करता है। bcrypt उससे भी पुराना, सरल है और इसकी 72-बाइट की इनपुट सीमा है, जो कभी-कभी लंबे पासफ़्रेज़ का उपयोग करने वाले एप्लिकेशन को परेशान करती है। यदि आपको लंबे इनपुट की आवश्यकता है, तो SHA-256 के साथ प्री-हैश करें और बेस64-एनकोड करें। PBKDF2 धीमा है लेकिन FIPS के अनुरूप है; OWASP ने 2023 में SHA-256 के लिए इसके पुनरावृति की संख्या 310,000 से बढ़ाकर 600,000 कर दी।

इस सूची में शामिल नहीं हैं: सामान्य SHA-256, सामान्य SHA-512, MD5, SHA-1, और "+ salt" में समाप्त होने वाले कोई भी कस्टम फ़ंक्शन। गति ही इसका मुख्य कारण है। SHA-256 को सामान्य हार्डवेयर पर तेज़ चलने के लिए डिज़ाइन किया गया था। यह पासवर्ड स्टोरेज की ज़रूरतों के बिल्कुल विपरीत है।

वास्तविक ऑडिट में सामने आने वाली आम नमक डालने की गलतियाँ

वास्तविक दुनिया में सामने आने वाली डेटा लीक की रिपोर्टों में बार-बार कुछ चुनिंदा त्रुटियों को ही उजागर किया जाता है।

प्रत्येक उपयोगकर्ता के लिए एक ही सॉल्ट का पुनः उपयोग करने से पूरी प्रक्रिया विफल हो जाती है — रेनबो-टेबल समस्या फिर से उत्पन्न हो जाती है, बस एक अतिरिक्त चरण के साथ। उपयोगकर्ता नाम को सॉल्ट के रूप में उपयोग करना और भी बुरा है, क्योंकि उपयोगकर्ता नाम सिस्टम में दोहराए जाते हैं और लोकप्रिय उपयोगकर्ताओं के लिए रेनबो टेबल पहले से ही तैयार की जा सकती हैं। सोलह बाइट से कम लंबाई के सॉल्ट बड़े उपयोगकर्ता आधारों पर टकराव की संभावना पैदा करने लगते हैं। गैर-क्रिप्टोग्राफिक यादृच्छिक फ़ंक्शन — `Math.random()`, `time(0)` मॉड समथिंग, भाषा का डिफ़ॉल्ट RNG — का उपयोग करके सॉल्ट उत्पन्न करने से अनुमानित मान प्राप्त होते हैं जो सॉल्टिंग के लाभ को समाप्त कर देते हैं।

एक और सूक्ष्म गलती है "सुरक्षा के नाम पर" सॉल्ट को किसी दूसरे सर्वर पर स्टोर करना। सॉल्ट कोई गुप्त जानकारी नहीं है। इसे अलग-अलग सिस्टमों में बांटने से परिचालन संबंधी जटिलता तो बढ़ती है, लेकिन क्रिप्टोग्राफिक मजबूती में कोई वृद्धि नहीं होती। इसे हैश के साथ ही स्टोर करें। आधुनिक PHC स्ट्रिंग्स यह काम आपके लिए कर देती हैं।

2026 के ऑडिट में सबसे बड़ी समस्या, सादे SHA-256 प्लस सॉल्ट के साथ हैशिंग और शिपिंग से संबंधित है। सॉल्ट रेनबो टेबल को रोकता है। लेकिन यह एक ही खाते के विरुद्ध प्रति सेकंड दस अरब अनुमान लगाने वाले GPU फ़ार्म के बारे में कुछ नहीं करता। इसका समाधान दूसरा सॉल्ट जोड़ना नहीं है; बल्कि आर्गन2आईडी जैसे धीमे KDF पर स्विच करना है।

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

सिर्फ नमक डालना ही काफी क्यों नहीं है?

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

2026 में पासवर्ड की वास्तविक सुरक्षा चार सुरक्षा उपायों पर आधारित होगी। सोलह बाइट प्रति-उपयोगकर्ता सॉल्ट के साथ आर्गन2आईडी स्टोरेज को संभालता है। पेप्पर (वैकल्पिक लेकिन संवेदनशील सिस्टम के लिए उपयोगी) डेटाबेस-आधारित चोरी को रोकता है। मल्टी-फैक्टर ऑथेंटिकेशन क्रेडेंशियल स्टफिंग और अधिकांश फ़िशिंग हमलों को रोकता है। हैव आई बीन पवनेड और इसके एपीआई जैसी सेवाओं द्वारा निरंतर उल्लंघन निगरानी, उपयोगकर्ता के क्रेडेंशियल लीक होते ही उसे पकड़ लेती है ताकि उन्हें रीसेट करने के लिए बाध्य किया जा सके।

इनमें से किसी भी एक सुरक्षा परत को छोड़ देने पर हमलावर अंततः उस कमी का पता लगा लेता है। केवल सुरक्षा उपायों को सीमित करना, या किसी एक सुरक्षा उपाय को अकेले अपनाना, पिछले दशक में हुए हर सुरक्षा उल्लंघन विश्लेषण में विफलता का मुख्य कारण पाया गया है।

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.