पासवर्ड के कई प्रचलित नियम उपयोगकर्ताओं की परेशानी बढ़ाते हैं, पर आधुनिक हमलों को नहीं रोकते। जानें कि NIST, NCSC और Microsoft के मौजूदा दिशानिर्देश किन सुरक्षा उपायों का समर्थन करते हैं।
पासवर्ड नीति को अक्सर नियमों की एक सूची मान लिया जाता है: एक बड़ा अक्षर, एक अंक और एक चिह्न अनिवार्य करें, और हर 60 या 90 दिन में पासवर्ड बदलवाएँ। इन नियमों का पालन दिखता है और इनकी जाँच करना आसान है, लेकिन कोई नियम दिखाई दे रहा हो, तो इसका मतलब यह नहीं कि वह प्रभावी भी है। हमलावर लोगों के अनुमानित चुनावों, दोबारा इस्तेमाल किए गए क्रेडेंशियल, खाते तक पहुँच बहाल करने की कमज़ोर प्रक्रियाओं और अपर्याप्त सुरक्षा वाले पासवर्ड डेटाबेस का फ़ायदा उठाते हैं।
एक उपयोगी नीति को इन ठोस जोखिमों को कम करना चाहिए। साथ ही, उसका पालन इतना आसान होना चाहिए कि लोग उससे बचने के तरीके न ढूँढ़ें।
न्यूनतम लंबाई
लंबाई बढ़ने से संभावित पासवर्ड के संयोजनों की संख्या बढ़ती है, लेकिन तभी जब पासवर्ड कोई आम वाक्यांश या अनुमानित पैटर्न न हो। NIST के मौजूदा दिशानिर्देशों के अनुसार, जब पासवर्ड ही प्रमाणीकरण का एकमात्र कारक हो, तो उसमें कम-से-कम 15 वर्ण होने चाहिए। जब पासवर्ड बहु-कारक प्रमाणीकरण का हिस्सा हो, तो आठ वर्ण की कम न्यूनतम सीमा की अनुमति है। प्रणालियों को कम-से-कम 64 वर्ण तक के पासवर्ड स्वीकार करने चाहिए, ताकि पासवर्ड मैनेजर और पासफ़्रेज़ ठीक से काम कर सकें।
लंबाई एक बुनियादी शर्त है, मज़बूती का प्रमाण नहीं। जिन पासवर्ड की सुरक्षा भंग हो चुकी है, उन्हें रोकने वाली सूची ज़रूरी है, क्योंकि कोई लंबा पासवर्ड भी असुरक्षित रहता है अगर हमलावर उसे पहले से जानते हों।
नियमित अंतराल पर पासवर्ड की वैधता समाप्त करना
तय समय पर पासवर्ड बदलने की बाध्यता के कारण लोग अक्सर छोटे और अनुमानित बदलाव करते हैं। इससे हर उपयोगकर्ता पर अतिरिक्त बोझ भी पड़ता है, जबकि इस बात का कोई प्रमाण नहीं होता कि हर पासवर्ड उजागर हो चुका है। NIST, ब्रिटेन का NCSC और Microsoft नियमित अंतराल पर पासवर्ड की वैधता समाप्त करने की सलाह नहीं देते। इसके बजाय, पासवर्ड तब बदलना चाहिए जब उसकी सुरक्षा भंग होने का प्रमाण या उचित संदेह हो, उसके भंडारण में सुरक्षा की कमज़ोरी का पता चले, या खाते तक पहुँच बहाल करने से जुड़ी किसी घटना के कारण इसकी ज़रूरत हो।
संगठनों को फिर भी सुरक्षा भंग होने का जल्द पता लगाने और पासवर्ड रीसेट करने की क्षमता चाहिए। तय अंतराल पर पासवर्ड बदलने की व्यवस्था हटाने का मतलब यह नहीं है कि ऐसे पासवर्ड को बनाए रखा जाए जिसकी सुरक्षा भंग होने की जानकारी है।
पासवर्ड की संरचना के नियम
बड़े अक्षर, छोटे अक्षर, अंक और चिह्न अनिवार्य करने वाले नियम ऐसे पैटर्न को बढ़ावा देते हैं जिनमें पहला अक्षर बड़ा होता है और अंत में कोई अंक या चिह्न होता है। हमले के उपकरण पहले से ही ऐसे बदलावों को ध्यान में रखते हैं। सेवाओं को स्पेस और कई तरह के वर्ण स्वीकार करने चाहिए, मनमाने संरचना-संबंधी नियमों से बचना चाहिए और प्रस्तावित पूरे पासवर्ड को आम तथा सुरक्षा भंग हो चुके पासवर्ड की सूची से मिलाकर जाँचना चाहिए।
विराम चिह्नों पर इसलिए रोक लगाना कि उनका इस्तेमाल SQL इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग में हो सकता है, एक चेतावनी का संकेत है। एप्लिकेशन कोड में पैरामीटरयुक्त डेटाबेस क्वेरी और आउटपुट को सुरक्षित ढंग से संभालने के तरीके इस्तेमाल होने चाहिए। उपयोगकर्ता के पासवर्ड पर पाबंदियाँ लगाना, इंजेक्शन संबंधी सुरक्षा कमज़ोरियाँ दूर करने का विकल्प नहीं है।
पासवर्ड का दोबारा इस्तेमाल और लीक हुए क्रेडेंशियल
पासवर्ड का दोबारा इस्तेमाल सबसे गंभीर जोखिमों में से एक है, क्योंकि एक सेवा प्रदाता के यहाँ हुई सेंध से दूसरे प्रदाता के खातों तक पहुँच मिल सकती है। नीति में सेवा के लिए अलग पासवर्ड की आवश्यकता होनी चाहिए, पासवर्ड मैनेजर का समर्थन होना चाहिए और गोपनीयता बनाए रखने वाले तरीके से प्रस्तावित पासवर्ड को उन पासवर्ड से मिलाकर जाँचना चाहिए जिनकी सुरक्षा भंग होने की जानकारी है। संगठनों को क्रेडेंशियल स्टफ़िंग के पैटर्न और असामान्य लॉगिन गतिविधि पर भी नज़र रखनी चाहिए।
पुराने पासवर्ड का रिकॉर्ड किसी एक सेवा में ठीक उसी पासवर्ड का दोबारा इस्तेमाल रोक सकता है, लेकिन बहुत लंबी सूचियाँ केवल दिखावटी बदलावों को बढ़ावा दे सकती हैं। यह रिकॉर्ड असंबंधित सेवा प्रदाताओं के यहाँ पासवर्ड के दोबारा इस्तेमाल का पता नहीं लगा सकता और इसे मुख्य सुरक्षा उपाय नहीं माना जाना चाहिए।
पासवर्ड का सुरक्षित भंडारण
पासवर्ड केवल सुरक्षित TLS कनेक्शन के ज़रिए सेवा तक भेजे जाने चाहिए और उन्हें कभी भी लॉग में दर्ज नहीं करना चाहिए। सर्वर पर हर पासवर्ड को एक अलग रैंडम सॉल्ट और इस उद्देश्य के लिए बनाए गए धीमे पासवर्ड-हैशिंग फ़ंक्शन के साथ संसाधित करना चाहिए। OWASP आम तौर पर Argon2id की अनुशंसा करता है; बताई गई सीमाओं के तहत scrypt, bcrypt या PBKDF2 उपयुक्त हो सकते हैं। हार्डवेयर बेहतर होने के साथ वर्क फ़ैक्टर की समय-समय पर समीक्षा ज़रूरी है।
पासवर्ड डेटाबेस के बाहर रखा गया पेपर सुरक्षा की एक और परत जोड़ सकता है, लेकिन इसके साथ कुंजी प्रबंधन और कुंजी बदलने की ज़िम्मेदारियाँ भी आती हैं। यह सॉल्ट या मज़बूत पासवर्ड-हैशिंग फ़ंक्शन का विकल्प नहीं है। MD5 और साधारण SHA-1/SHA-2 जैसे तेज़, सामान्य उपयोग वाले हैश अपने आप में पासवर्ड भंडारण के लिए उपयुक्त नहीं हैं।
एक प्रभावी नीति में क्या शामिल होता है
जोखिम के अनुरूप न्यूनतम लंबाई और लंबे पासवर्ड का समर्थन।
आम या अपेक्षित पासवर्ड और ऐसे पासवर्ड पर रोक जिनकी सुरक्षा भंग होने की जानकारी है।
पासवर्ड मैनेजर, पेस्ट और ऑटोफ़िल का समर्थन।
अलग-अलग सॉल्ट के साथ धीमी पासवर्ड हैशिंग और वर्क फ़ैक्टर की समीक्षा।
कई स्तरों पर अनुरोधों की दर सीमित करना और पासवर्ड का अनुमान लगाने, पासवर्ड स्प्रेइंग तथा क्रेडेंशियल स्टफ़िंग का पता लगाना।
फ़िशिंग-प्रतिरोधी MFA या पासकी, ख़ासकर विशेषाधिकार वाले और संवेदनशील खातों के लिए।
खाते तक पहुँच सुरक्षित रूप से बहाल करना, प्रमाणीकरण साधन बदलना, सत्र रद्द करना और सुरक्षा भंग होने पर रीसेट करना।
