8 से 20 अक्षरों की लंबाई वाला एक नया रैंडम पासवर्ड बनाएँ और अनुमत वर्ण समूहों का चयन करें: लोअरकेस और अपरकेस लैटिन अक्षर, अंक और विशेष प्रतीक। सामान्य व्यक्तिगत खाते के लिए, सेवा द्वारा समर्थित अधिकतम लंबाई चुनें (इस उपकरण में 16–20 अक्षर) और प्राप्त पासवर्ड का पुनः उपयोग न करें।
पासवर्ड को मजबूत क्या बनाता है
रैंडम रूप से उत्पन्न पासवर्ड के लिए विशेष रूप से महत्वपूर्ण हैं:
- लंबाई। जितने अधिक स्वतंत्र रैंडम वर्ण होंगे, संभावित संयोजनों की संख्या उतनी ही अधिक होगी।
- अप्रत्याशितता। नाम, जन्म तिथि, साइट का नाम, कीबोर्ड अनुक्रम या जाना-माना उद्धरण रैंडम स्ट्रिंग की तुलना में आसानी से अनुमानित किए जाते हैं।
- अद्वितीयता। एक ही पासवर्ड का उपयोग कई सेवाओं में नहीं किया जा सकता है।
- सुरक्षित भंडारण। एक जटिल पासवर्ड बेकार है यदि वह खुली फ़ाइल में पड़ा है या तीसरे पक्षों को प्रेषित किया गया है।
- लीक के बाद पुनः उपयोग से सुरक्षा। समझौता किए गए पासवर्ड को हर जगह बदला जाना चाहिए जहाँ इसका उपयोग किया गया था।
विभिन्न प्रकार के वर्णों को जोड़ने से संभावित संयोजनों का सेट बढ़ जाता है। हालाँकि, आधुनिक सिफारिश यह है कि "एक बड़ा अक्षर, एक अंक और एक प्रतीक" जैसी अनिवार्य योजना के साथ छोटी लंबाई की भरपाई करने की कोशिश न करें। रैंडम पासवर्ड के लिए, लंबाई और अद्वितीयता आमतौर पर कृत्रिम रूप से जटिल पैटर्न से अधिक महत्वपूर्ण होती हैं।
कौन सी लंबाई चुनें
वर्तमान NIST SP 800-63B-4 प्रकाशन के अनुसार सिस्टम को एकल-कारक पासवर्ड के लिए कम से कम 15 अक्षर स्वीकार करने की आवश्यकता है; जब पासवर्ड का उपयोग केवल बहु-कारक प्रमाणीकरण के कारकों में से एक के रूप में किया जाता है, तो न्यूनतम 8 की अनुमति है। सेवाओं को कम से कम 64 अक्षरों तक के पासवर्ड की भी अनुमति देनी चाहिए।
ये सिस्टम के लिए आवश्यकताएँ हैं, न कि यह दावा कि कोई भी 15 अक्षरों का पासवर्ड स्वचालित रूप से सुरक्षित है। 20 अक्षरों तक की सीमा वाले जनरेटर के लिए व्यावहारिक विकल्प इस प्रकार है:
- 16–20 अक्षर — अधिकांश नए खातों के लिए पसंदीदा सीमा;
- 20 अक्षर — एक उचित डिफ़ॉल्ट विकल्प यदि साइट इस लंबाई को स्वीकार करती है;
- 8–14 अक्षर — केवल विशिष्ट सिस्टम बाधाओं या विशेष बहु-कारक परिदृश्य में उपयोग करें, यह समझते हुए कि लंबा पासवर्ड बेहतर है।
विशेष रूप से महत्वपूर्ण सिस्टम के लिए, पासवर्ड प्रबंधक का उपयोग करना बेहतर होता है जो लंबे मान बना और संग्रहीत कर सकता है, यदि सेवा उनका समर्थन करती है।
क्या सभी वर्ण समूहों को शामिल करना आवश्यक है?
पहले विशिष्ट साइट के नियमों पर विचार करें। कुछ सिस्टम:
- कम से कम एक अंक या विशेष प्रतीक की आवश्यकता होती है;
- केवल सीमित वर्ण सूची की अनुमति देते हैं;
- स्पेस, उद्धरण या अन्य चिह्नों को गलत तरीके से संसाधित करते हैं;
- अप्रचलित अधिकतम लंबाई सीमा रखते हैं।
लोअरकेस और अपरकेस अक्षर, अंक और विशेष प्रतीकों को शामिल करें यदि सेवा उन्हें स्वीकार करती है। लेकिन सभी आवश्यकताओं को मैन्युअल रूप से पूरा करने के लिए पासवर्ड को छोटा न करें।
पासवर्ड का पुनः उपयोग क्यों नहीं करना चाहिए
एक साइट के लीक होने के बाद, हमलावर स्वचालित रूप से अन्य सेवाओं पर समान ईमेल और पासवर्ड युग्म की जाँच कर सकते हैं। एक अद्वितीय पासवर्ड क्षति को एक खाते तक सीमित करता है।
इस प्रकार के वेरिएंट न बनाएँ:
मेरापासवर्ड-ईमेल
मेरापासवर्ड-दुकान
मेरापासवर्ड-बैंक
सामान्य आधार पूर्वानुमानित रहता है। प्रत्येक सेवा के लिए पूरी तरह से स्वतंत्र मान उत्पन्न करें।
उत्पन्न पासवर्ड कैसे संग्रहीत करें
सबसे अच्छा व्यावहारिक विकल्प पासवर्ड प्रबंधक है। यह अनुमति देता है:
- प्रत्येक खाते के लिए एक अलग पासवर्ड संग्रहीत करना;
- केवल संबंधित डोमेन पर डेटा को स्वचालित रूप से भरना;
- लंबे रैंडम मान उत्पन्न करना;
- पुनः उपयोग किए गए या समझौता किए गए पासवर्ड देखना;
- एन्क्रिप्टेड भंडारण को उपकरणों के बीच सिंक्रनाइज़ करना।
प्रबंधक का मास्टर पासवर्ड लंबा, यादगार और अद्वितीय होना चाहिए। जहाँ उपलब्ध हो, बहु-कारक प्रमाणीकरण या एक्सेस कुंजी सक्षम करें।
पासवर्ड कब बदलना चाहिए
पासवर्ड बदलें:
- यदि सेवा लीक की सूचना देती है;
- यदि आपने इसे किसी संदिग्ध साइट पर दर्ज किया है;
- यदि इसे असुरक्षित तरीके से भेजा गया था;
- यदि इसे कोई ऐसा व्यक्ति जानता है जिसे अब पहुँच की आवश्यकता नहीं है;
- यदि डिवाइस या भंडारण से समझौता हो सकता है;
- यदि पासवर्ड किसी अन्य खाते में दोहराया जाता है।
NIST समझौता के संकेतों के बिना आवधिक परिवर्तन की अनुशंसा नहीं करता है। कैलेंडर के अनुसार लगातार जबरन बदलाव अक्सर पासवर्डमई → पासवर्डजून जैसे पूर्वानुमानित वेरिएंट की ओर ले जाते हैं। अद्वितीयता, पर्याप्त लंबाई और वास्तविक जोखिम के बाद त्वरित परिवर्तन अधिक महत्वपूर्ण हैं।
अस्थायी पासवर्ड और ठेकेदार पहुँच
अस्थायी पहुँच के लिए, मालिक के मुख्य पासवर्ड को प्रेषित करने के बजाय न्यूनतम अधिकारों और समाप्ति तिथि वाला एक अलग खाता बनाना अधिक सुरक्षित है।
यदि सिस्टम अस्थायी पासवर्ड का उपयोग करता है:
- इसे सहमत सुरक्षित चैनल के माध्यम से प्रेषित करें;
- उपयोगकर्ता नाम और पासवर्ड को एक खुले संदेश में न भेजें;
- पहले लॉगिन पर बदलाव की आवश्यकता करें;
- कार्य समाप्त होने के तुरंत बाद पहुँच रद्द करें;
- लॉग इन लॉग और सक्रिय सत्रों की जाँच करें।
जनरेटर स्ट्रिंग बनाता है, लेकिन अधिकारों, प्रसारण या निरसन का प्रबंधन नहीं करता है।
"अद्वितीय पासवर्ड" का क्या अर्थ है
पृष्ठ पर इसे "एक नया स्वतंत्र रूप से उत्पन्न पासवर्ड" के रूप में समझना चाहिए। एक ऑनलाइन जनरेटर यह साबित नहीं कर सकता कि यह संयोजन कभी भी किसी के पास नहीं आया है। पर्याप्त रूप से बड़े रैंडम वेरिएंट स्थान के साथ, मिलान अत्यंत असंभव है, लेकिन सेवा पूर्ण वैश्विक अद्वितीयता की जाँच नहीं करती है।
तकनीकी जाँच के बिना उपकरण को क्या वादा नहीं करना चाहिए
यदि कार्यान्वयन द्वारा इसकी पुष्टि नहीं की गई है तो स्वचालित रूप से यह दावा नहीं किया जा सकता कि पासवर्ड क्रिप्टोग्राफिक रूप से सुरक्षित रैंडम संख्या जनरेटर द्वारा बनाया गया है। ऐसे वादे के लिए, डेवलपर्स को यह जाँचना चाहिए कि ब्राउज़र क्रिप्टोग्राफिक API का उपयोग करता है, उदाहरण के लिए crypto.getRandomValues(), न कि सामान्य Math.random()।
कार्यान्वयन के लिए अनुशंसित आंतरिक जाँच:
- ब्राउज़र के CSPRNG के माध्यम से जनरेशन;
- बिना पूर्वाग्रह के समान वर्ण चयन;
- पासवर्ड की एनालिटिक्स, लॉग और URL में कोई रिकॉर्डिंग नहीं;
- सर्वर को मान न भेजना;
- रीसेट करने पर DOM से संवेदनशील मान को साफ़ करना;
- प्रत्येक वर्ण समूह को अक्षम करने पर सही कार्य करना।
जब तक इसकी पुष्टि नहीं हो जाती, उपयोगकर्ता पाठ में "क्रिप्टोग्राफिक रूप से सुरक्षित" के बजाय "रैंडम पासवर्ड" लिखना अधिक सुरक्षित है।
खाते के लिए अतिरिक्त सुरक्षा
पासवर्ड सुरक्षा की केवल एक परत है। महत्वपूर्ण खातों के लिए:
- बहु-कारक प्रमाणीकरण सक्षम करें;
- यदि सेवा समर्थन करती है तो एक्सेस कुंजी, हार्डवेयर कुंजी या प्रमाणक ऐप का उपयोग करना पसंद करें;
- बैकअप कोड को सुरक्षित स्थान पर रखें;
- पासवर्ड दर्ज करने से पहले डोमेन की जाँच करें;
- अप्रत्याशित लॉगिन अनुरोधों की पुष्टि न करें;
- अज्ञात सक्रिय सत्रों को समाप्त करें।
सामान्य प्रश्न
लंबा पासवर्ड छोटे जटिल पासवर्ड से बेहतर क्यों है?
लंबाई संभावित रैंडम संयोजनों की संख्या को बढ़ाती है। a → @ जैसे पूर्वानुमानित प्रतिस्थापन वाला एक छोटा पासवर्ड कमजोर रह सकता है, भले ही वह औपचारिक रूप से विभिन्न प्रकार के वर्णों को शामिल करता हो।
क्या मुझे हर 30 या 90 दिनों में पासवर्ड बदलना चाहिए?
बिना कारण के नहीं। लीक, संदिग्ध प्रविष्टि, तीसरे पक्ष को प्रेषण, या समझौता के किसी अन्य संकेत के बाद इसे बदलें। नियमित कैलेंडर परिवर्तन अद्वितीयता और लंबाई का विकल्प नहीं है।
क्या मैं पासवर्ड को ब्राउज़र में सहेज सकता हूँ?
आधुनिक ब्राउज़र का अंतर्निहित प्रबंधक आमतौर पर सरल पासवर्डों का पुनः उपयोग करने या खुली फ़ाइल में संग्रहीत करने की तुलना में अधिक सुरक्षित होता है। डिवाइस को स्वयं, सिंक्रनाइज़ेशन खाते को सुरक्षित रखें और अतिरिक्त प्रमाणीकरण सक्षम करें।
साइट एक विशेष वर्ण को स्वीकार क्यों नहीं करती?
सेवा के पास अनुमत वर्णों का सीमित सेट या अप्रचलित सत्यापन हो सकता है। केवल समर्थित समूहों के साथ एक नया वेरिएंट उत्पन्न करें, अधिकतम संभव लंबाई बनाए रखें।
क्या मैं पासवर्ड को सामान्य मैसेंजर में भेज सकता हूँ?
संवेदनशील पहुँच के लिए, एक सुरक्षित गुप्त स्थानांतरण फ़ंक्शन, एक अलग खाता और पहले लॉगिन के बाद अस्थायी पासवर्ड बदलने का उपयोग करना बेहतर है। साझा चैट इतिहास में स्थायी पासवर्ड न छोड़ें।
क्या जनरेटर गारंटी देता है कि पासवर्ड कहीं भी संग्रहीत नहीं है?
यह पृष्ठ के तकनीकी कार्यान्वयन पर निर्भर करता है। ऐसा वादा डेवलपर्स द्वारा नेटवर्क अनुरोधों, एनालिटिक्स और लॉगिंग की जाँच के बाद ही प्रकाशित किया जाना चाहिए।
संबंधित उपकरण: Base64; टेक्स्ट संपादक।
आधिकारिक अनुशंसा:
- NIST SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management: https://pages.nist.gov/800-63-4/sp800-63b.html
