संक्षेप में: लंबाई जटिलता से ज़्यादा मायने रखती है — मौजूदा NIST पासवर्ड गाइडेंस (SP 800-63B) स्पष्ट रूप से जबरदस्ती सिंबल/नंबर संयोजनों की बजाय लंबे पासफ़्रेज़ को तरजीह देती है, और पासवर्ड को तय समय-सारणी पर समाप्त करने के बजाय जाने-माने कॉम्प्रोमाइज़्ड पासवर्ड लिस्ट के मुक़ाबले जाँचने की सिफ़ारिश करती है। इस गाइड को Character Counter, Text Encryption, Duplicate Finder और AI Hidden Characters के साथ जोड़ें।
पासवर्ड की मज़बूती मूल रूप से एन्ट्रॉपी के बारे में है — औसतन एक अटैकर को कितने अनुमान चाहिए — और लंबाई एन्ट्रॉपी को एक्सपोनेंशियल रूप से बढ़ाती है, जबकि एक अनिवार्य सिंबल जोड़ना इसे केवल रैखिक रूप से बढ़ाता है।
जटिलता के नियमों से लंबाई क्यों बेहतर है
किसी पासवर्ड की खोज स्पेस उसकी लंबाई की घात तक कैरेक्टर सेट के आकार के साथ बढ़ती है: सिर्फ़ लोअरकेस वाले 8-कैरेक्टर पासवर्ड में लगभग 26⁸ (~2×10¹¹) संभावित संयोजन होते हैं, लेकिन सिर्फ़ लोअरकेस वाले 16-कैरेक्टर पासफ़्रेज़ में 26¹⁶ होते हैं — बहुत सारे ऑर्डर ऑफ़ मैग्निट्यूड ज़्यादा — एक छोटे, सरल कैरेक्टर सेट का उपयोग करने के बावजूद। यही मुख्य कारण है कि NIST SP 800-63B छोटी, जटिल स्ट्रिंग्स की बजाय लंबे पासफ़्रेज़ की सिफ़ारिश करता है: चार यादृच्छिक असंबंधित शब्द "P@ssw0rd1!" की तुलना में याद रखने में आसान और ब्रूट-फ़ोर्स करने में मुश्किल दोनों होते हैं।
NIST ने वास्तव में क्या सिफ़ारिश करना बंद कर दिया है
दो लंबे समय से चली आ रही "बेस्ट प्रैक्टिस" अब मौजूदा NIST गाइडेंस में स्पष्ट रूप से हतोत्साहित की जाती हैं: अनिवार्य नियमित पासवर्ड समाप्ति (जो लोगों को बार-बार बदलने पर मजबूर करने पर कमज़ोर, अधिक अनुमानित पासवर्ड चुनने की ओर ले जाती है — एक आम पैटर्न अंत में एक नंबर बढ़ाना है), और विशिष्ट कैरेक्टर क्लास की मांग करने वाले जबरदस्ती जटिलता नियम, जो अनुमानित प्रतिस्थापन (@ के लिए a, 0 के लिए o) की ओर धकेलते हैं जिन्हें अटैकर के डिक्शनरी पहले से ध्यान में रखते हैं। मौजूदा सिफ़ारिश इसके बजाय है: लंबे पासवर्ड (64+ कैरेक्टर) की अनुमति दें, मनमानी जटिलता न थोपें, और नए पासवर्ड को जाने-माने कॉम्प्रोमाइज़्ड क्रेडेंशियल लिस्ट के मुक़ाबले जाँचें।
लीक लिस्ट के मुक़ाबले जाँच स्ट्रेंथ मीटर से ज़्यादा क्यों मायने रखती है
किसी पासवर्ड में उच्च सैद्धांतिक एन्ट्रॉपी हो सकती है — लंबा, यादृच्छिक दिखने वाला, मिश्रित केस — फिर भी अगर यह किसी जाने-माने डेटा लीक में दिखता है तो यह ख़तरनाक हो सकता है, क्योंकि अटैकर इन लीक हुई लिस्ट को अपने पहले प्रयास के रूप में उपयोग करते हैं, ब्रूट फ़ोर्स नहीं। यही कारण है कि Have I Been Pwned पासवर्ड API जैसी सेवाएँ मौजूद हैं: किसी नए पासवर्ड को जाने-माने लीक लिस्ट के मुक़ाबले जाँचना एक असली जोखिम पकड़ता है जिसे एक सामान्य स्ट्रेंथ अनुमान, जो सिर्फ़ सैद्धांतिक यादृच्छिकता मापता है, नहीं देख सकता।
एक व्यावहारिक दृष्टिकोण
- छोटे जटिल पासवर्ड के बजाय 4+ असंबंधित शब्दों का पासफ़्रेज़, या 16+ कैरेक्टर की यादृच्छिक स्ट्रिंग उपयोग करें।
- कभी भी कई साइटों पर पासवर्ड दोबारा उपयोग न करें — एक सेवा में लीक उसी पासवर्ड का उपयोग करने वाले हर अकाउंट पर हमला बन जाता है।
- सिर्फ़ एक विज़ुअल "स्ट्रेंथ" मीटर पर भरोसा करने के बजाय नए पासवर्ड को जाने-माने लीक लिस्ट के मुक़ाबले जाँचें।
- हर साइट के लिए अनूठे पासवर्ड जनरेट और स्टोर करने के लिए पासवर्ड मैनेजर उपयोग करें — जैसे ही आप इन्हें याद करना बंद कर देते हैं, लंबाई और अनूठापन मेमोरी बोझ नहीं रहते।
- किसी पासवर्ड को केवल किसी ख़ास कारण (संदिग्ध लीक) से बदलें, मनमाने कैलेंडर के अनुसार नहीं।
बचने योग्य आम गलतियाँ
- कच्ची लंबाई पर सिंबल/नंबर जटिलता को प्राथमिकता देना — हर जोड़े गए कैरेक्टर के लिए लंबाई कहीं ज़्यादा एन्ट्रॉपी योगदान करती है।
- कई अकाउंट पर एक मज़बूत पासवर्ड दोबारा उपयोग करना, जो उस पल उद्देश्य को विफल कर देता है जब कोई साइट कॉम्प्रोमाइज़ होती है।
- किसी पासवर्ड पर भरोसा करना क्योंकि यह "यादृच्छिक दिखता है" बिना यह जाँचे कि क्या यह किसी जाने-माने लीक में दिखता है।
- आदत से एक निश्चित कैलेंडर पर पासवर्ड घुमाना — मौजूदा NIST गाइडेंस स्पष्ट रूप से इस प्रथा को हतोत्साहित करती है।
आज एक मज़बूत पासवर्ड लंबा और अनूठा है — जाने-माने लीक के मुक़ाबले जाँचा गया, मनमाने जटिलता नियमों के ज़रिए ज़बरदस्ती बनाई गई स्ट्रिंग नहीं जो ज़्यादातर उसे याद रखना कठिन बनाती है, लेकिन उसका अनुमान लगाना अधिक कठिन नहीं बनाती।