{"componentChunkName":"component---src-templates-blog-template-js","path":"/hi/blog/password-policy-dos-donts-best-practices","result":{"data":{"markdownRemark":{"html":"<p>एक पासवर्ड नीति का उद्देश्य खातों को समझौता होने से कठिन बनाना होना चाहिए, न कि सुरक्षित व्यवहार को अनावश्यक रूप से कठिन बनाना। सबसे अच्छी नीतियाँ स्पष्ट, व्यावहारिक, और वास्तविक कामकाजी परिस्थितियों के अनुकूल होती हैं। वे लंबा, अनोखा पासवर्ड अपनाने, पासवर्ड मैनेजर का समर्थन करने, उपयुक्त स्थानों पर मल्टी-फैक्टर ऑथेंटिकेशन (MFA) अनिवार्य करने, और पुराने नियम हटाने को प्रोत्साहित करती हैं जो उपयोगकर्ताओं को अनुमान योग्य व्यवहार की ओर धकेलते हैं।</p>\n<p>यह लेख एक आधुनिक पासवर्ड नीति के क्या करें व क्या न करें, किन बातों से बचें, सर्वोत्तम अभ्यास, और एक तैयार उपयोगी टेम्प्लेट की आवश्यकता को स्पष्ट करता है, जिसे आप अपनी संस्था के अनुसार अनुकूलित कर सकते हैं।</p>\n<h2>पासवर्ड नीति क्या है?</h2>\n<p>पासवर्ड नीति एक नियमों का समूह है, जो पासवर्ड बनाने, संग्रहित करने, उपयोग करने, साझा करने, बदलने और सुरक्षित रखने के तरीके को परिभाषित करता है। यह कर्मचारियों, ठेकेदारों, प्रशासकों, सेवा खातों, और कभी-कभी ग्राहकों पर भी लागू होती है, यह निर्भर करता है कि किन सिस्टम्स को शामिल किया गया है।</p>\n<p>एक अच्छी पासवर्ड नीति व्यावहारिक प्रश्नों का उत्तर देनी चाहिए:</p>\n<ul>\n<li>पासवर्ड कितने लंबे होने चाहिए?</li>\n<li>क्या पासफ्रेज़ (Passphrases) की अनुमति है?</li>\n<li>क्या उपयोगकर्ता पासवर्ड मैनेजर से पासवर्ड पेस्ट कर सकते हैं?</li>\n<li>पासवर्ड कब बदला जाना चाहिए?</li>\n<li>क्या मल्टी-फैक्टर ऑथेंटिकेशन जरूरी है?</li>\n<li>साझा क्रेडेंशियल्स का अब क्या होगा?</li>\n<li>अगर किसी पासवर्ड के समझौता होने का संदेह है तो क्या किया जाएगा?</li>\n</ul>\n<p>लक्ष्य सबसे जटिल नियम बनाना नहीं है। लक्ष्य वास्तविक जोखिम को कम करना है।</p>\n<h2>एक आधुनिक पासवर्ड नीति में क्या करें</h2>\n<h2>पासवर्ड की पर्याप्त लंबाई अनिवार्य करें</h2>\n<p>लंबाई अनुमान लगाने और ब्रूट-फोर्स हमलों के विरुद्ध सबसे मजबूत रक्षा है। एक ही संगठन-स्तरीय न्यूनतम लंबाई नीति, विभिन्न उपयोगकर्ता प्रकारों के लिए अलग-अलग नियमों की तुलना में, समझना और लागू करना आसान होता है। व्यावहारिक रूप में सभी मानव-उपयोगकर्ता खातों के लिए कम से कम 16 अंकों का पासवर्ड अनिवार्य करें। जब उपयोगकर्ता पासवर्ड मैनेजर या यादृच्छिक पासफ्रेज़ का उपयोग करते हैं, तो और लंबा बेहतर है।</p>\n<h2>लंबे पासवर्ड और पासफ्रेज़ की अनुमति दें</h2>\n<p>उपयोगकर्ता बहुत अधिक न्यूनतम सीमा से लंबे पासवर्ड बना सकें, इसकी अनुमति होनी चाहिए। 16 या 20 अक्षर की नीचे की अधिकतम सीमा से बचें। कम से कम 64 अक्षर के अधिकतम की अनुमति देना एक अच्छा मापदंड है, और कई सिस्टम इससे अधिक का भी समर्थन कर सकते हैं।</p>\n<p>पासफ्रेज़ तब स्वीकार्य हैं यदि वे लंबे हों और आम कथनों, गीतों, कंपनी के नामों या अनुमाननीय वाक्यांशों पर आधारित न हों। उदाहरण के लिए, यादृच्छिक शब्दों से बना एक पासफ्रेज़ सामान्यतः छोटे एवं प्रतीक-आधारित पासवर्ड से बेहतर है।</p>\n<h2>अनूठापन अनिवार्य करें</h2>\n<p>हर खाते का पासवर्ड अद्वितीय होना चाहिए। पासवर्ड पुनः उपयोग करना प्रायः डेटा उल्लंघन के बाद अन्य खाता अधिग्रहण का मुख्य कारण होता है। पासवर्ड मैनेजरों से प्रत्येक खाते के लिए अलग पासवर्ड बनाना संभव और आसान हो जाता है।</p>\n<h2>पासवर्ड मैनेजर का समर्थन करें</h2>\n<p>आपकी नीति में मान्यता प्राप्त पासवर्ड मैनेजर के प्रयोग की अनुमति और प्रोत्साहन स्पष्ट रूप से लिखा हो। उपयोगकर्ता लॉगिन फॉर्म में पासवर्ड पेस्ट कर सकें, ऑटोफिल और यादृच्छिक पासवर्ड जनरेट कर सकें। पेस्टिंग को ब्लॉक करना ऊपर से सुरक्षा देने जैसा लगता है, लेकिन इससे मजबूत पासवर्ड मैनेजर का उपयोग हतोत्साहित होता है।</p>\n<h2>पासवर्ड को ज्ञात कम्प्रोमाइज़्ड पासवर्ड सूचियों से जांचें</h2>\n<p>यदि पासवर्ड ज्ञात डाटा उल्लंघन या सामान्य पासवर्ड सूची में दिखता है, तो उसे अस्वीकार करें। यह \"एक अपरकेस, एक नंबर, एक प्रतीक जरूरी है\" वाले जटिलता नियम से अधिक उपयोगी है।</p>\n<h2>जहाँ संभव हो, MFA अनिवार्य करें</h2>\n<p>जहाँ संभव हो वहां मल्टी-फैक्टर ऑथेंटिकेशन अनिवार्य होना चाहिए, खासतौर पर प्रशासकों, रिमोट एक्सेस, क्लाउड सेवाओं, ईमेल, पासवर्ड मैनेजर, फाइनेंस सिस्टम्स, और अन्य महत्वपूर्ण सिस्टम्स के लिए। MFA मजबूत पासवर्ड का विकल्प नहीं है, लेकिन यह चोरी हुए क्रेडेंशियल्स के प्रभाव को कम करता है।</p>\n<p>फिशिंग-प्रतिरोधी MFA पसंद करें, जैसे पासकी, हार्डवेयर सुरक्षा कुंजी, या प्लैटफॉर्म ऑथेंटिकेटर। ऐप आधारित ऑथेंटिकेटर, SMS से बेहतर हैं। कभी भी SMS MFA का विकल्प हो, तो SMS-आधारित MFA का उपयोग न करें, क्योंकि फोन नंबर इंटरसेप्ट, सिम-स्वैप्ड, पोर्ट या रिकवरी प्रक्रिया के जरिये दुरुपयोग किए जा सकते हैं।</p>\n<p>यह केवल सैद्धांतिक बात नहीं है। 2018 में Reddit ने स्वीकार किया कि हमलावरों ने SMS-आधारित टू-फैक्टर ऑथेंटिकेशन को इंटरसेप्ट कर आंतरिक सिस्टम एक्सेस कर लिया: <a href=\"https://www.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/\" rel=\"nofollow\">https://www.reddit.com/r/announcements/comments/93qnm5/we<em>had</em>a<em>security</em>incident<em>heres</em>what<em>you</em>need_to/</a>. 2021 में Coinbase ने सूचित किया कि हमलावरों ने SMS अकाउंट रिकवरी प्रक्रिया में कमजोरी का फायदा उठा कर कम-से-कम 6,000 ग्राहकों के क्रिप्टोकरंसी चुरा ली: <a href=\"https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/\" rel=\"nofollow\">https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/</a>.</p>\n<h2>समझौते के बाद पासवर्ड बदलें</h2>\n<p>जब पासवर्ड के समझौता होने के प्रमाण या उचित संदेह हों, तब पासवर्ड तुरंत बदलना चाहिए। उदाहरण: फिशिंग, डिवाइस में मालवेयर, किसी उल्लंघन में क्रेडेंशियल एक्सपोजर, संदिग्ध लॉगिन, या आकस्मिक प्रकटीकरण।</p>\n<h2>साझा क्रेडेंशियल्स का सही तरीके से प्रबंधन करें</h2>\n<p>जहाँ व्यक्तिगत खाते बनाना संभव हो, वहाँ साझा पासवर्ड से बचें। यदि साझा क्रेडेंशियल्स अनिवार्य हों, तो उन्हें स्वीकृत पासवर्ड मैनेजर में संग्रहित करें, केवल अधिकृत उपयोगकर्ताओं को एक्सेस दें, और संभव हो तो शेयरिंग को लॉग करें।</p>\n<h2>पासवर्ड रीसेट प्रक्रिया सुरक्षित करें</h2>\n<p>पासवर्ड रीसेट अक्सर खाता सुरक्षा की सबसे कमजोर कड़ी होता है। रीसेट प्रक्रिया में पहचान सत्यापन आवश्यक हो, लिंक शीघ्र समाप्त हों, केवल एक बार उपयोग हो सकें, और जब भी पासवर्ड बदला जाए तो उपयोगकर्ता को सूचित करें।</p>\n<h2>एक आधुनिक पासवर्ड नीति में क्या न करें</h2>\n<h2>बिना उचित कारण बार-बार पासवर्ड बदलना अनिवार्य न करें</h2>\n<p>हर 30, 60, या 90 दिन में पासवर्ड बदलने की अनिवार्यता से उपयोगकर्ता आमतौर पर पासवर्ड में सिर्फ छोटा, अनुमाननीय परिवर्तन करते हैं—जैसे नंबर या सीजन बदलना। NIST ने नियमित पासवर्ड परिवर्तन नीति समाप्त की है और अब केवल समझौते के संकेत पर पासवर्ड बदलना आवश्यक होता है (देखें: <a href=\"https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver\" rel=\"nofollow\">https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver</a>)। केवल संभावित समझौते, भूमिका परिवर्तन, खाता पुनर्प्राप्ति, या नीति न मानने वाले पासवर्ड पर ही पासवर्ड बदलें।</p>\n<h2>केवल जटिलता नियमों पर निर्भर न रहें</h2>\n<p>\"एक अपरकेस, एक लोअरकेस, एक नंबर, एक प्रतीक जरूरी\" जैसे नियम अकेले ताकत को गारंटी नहीं देते। <code>Password1!</code> इन नियमों पर खरा उतरता है, फिर भी कमजोर है। लंबाई, अनूठापन, यादृच्छिकता और उल्लंघन स्क्रीनिंग को प्राथमिकता दें।</p>\n<h2>कॉपी-पेस्ट ब्लॉक न करें</h2>\n<p>कॉपी-पेस्ट ब्लॉक करने से पासवर्ड मैनेजर का उपयोग मुश्किल होता है। इससे उपयोगकर्ता कमज़ोर, टाइप करने में आसान पासवर्ड चुन सकते हैं। जब तक कोई स्पष्ट सुरक्षा कारण न हो, पेस्ट और ऑटोफिल की अनुमति दें।</p>\n<h2>पासवर्ड हिन्ट्स न अनुमति दें</h2>\n<p>पासवर्ड हिन्ट्स अक्सर बहुत अधिक जानकारी उजागर कर देते हैं। यदि उपयोगकर्ता हिन्ट से उत्तर जान सकता है, तो हमलावर भी अनुमान लगा सकता है। सुरक्षित रीसेट प्रक्रिया का उपयोग करें।</p>\n<h2>पासवर्ड को प्लेन टेक्स्ट में न रखें</h2>\n<p>किसी भी सिस्टम में पासवर्ड प्लेन टेक्स्ट या पलटने योग्य (reversible) एनक्रिप्शन में नहीं रखना चाहिए। आधुनिक, धीमे, सॉल्टेड पासवर्ड हैशिंग एल्गोरिदम (जैसे Argon2id, bcrypt, scrypt, PBKDF2) का उपयोग करें।</p>\n<p>MD5, SHA-1, SHA-256, SHA-512 आदि तेज साधारण हैश एल्गोरिदम पासवर्ड हैशिंग के लिए उपयुक्त नहीं हैं, क्योंकि वे ब्रूट-फोर्स हमले को आसान बना देते हैं। अधिक विस्तार के लिए हमारा लेख पढ़ें: <a href=\"/blog/evolution-of-password-hashing\">पासवर्ड हैशिंग का विकास</a>।</p>\n<h2>पासवर्ड चैट या ईमेल पर साझा न करें</h2>\n<p>पासवर्ड ईमेल, चैट, टिकट, दस्तावेज़, स्क्रीनशॉट आदि से साझा न करें। पासवर्ड मैनेजर के सुरक्षित sharing व एक्सेस कंट्रोल का प्रयोग करें।</p>\n<h2>व्यक्तिगत जानकारी या अनुमान योग्य पैटर्न प्रयोग न करें</h2>\n<p>पासवर्ड में नाम, जन्मदिन, कंपनी का नाम, कीबोर्ड पैटर्न, रिपिटेड अक्षर, या आम रूपांतरण (<code>@</code> के लिए 'a', <code>0</code> के लिए 'o') शामिल न हों। हमलावर इनका अनुमान सबसे पहले लगाते हैं।</p>\n<h2>संस्थाओं के लिए सर्वोत्तम अभ्यास</h2>\n<h2>स्पष्ट न्यूनतम आवश्यकताएँ सेट करें</h2>\n<p>आसान नियमों का उपयोग करें:</p>\n<ul>\n<li>सभी मानव-उपयोगकर्ता खातों के लिए एक न्यूनतम लंबाई (जैसे 16 अक्षर)</li>\n<li>कम-से-कम 64 अक्षर की अनुमति दें</li>\n<li>स्पेस और आम प्रतीकों की अनुमति दें</li>\n<li>पासफ्रेज़ और पासवर्ड मैनेजर की अनुमति दें</li>\n<li>उक्त और सामान्य पासवर्ड अस्वीकार करें</li>\n</ul>\n<h2>प्रिविलेज्ड अकाउंट के लिए कड़े नियम रखें</h2>\n<p>प्रशासक, सेवा खाता, और प्रोडक्शन एक्सेस के लिए मजबूत पासवर्ड, MFA, सीमित एक्सेस, मॉनिटरिंग और तुरंत रोटेशन अनिवार्य करें।</p>\n<h2>रोल-बेस्ड एक्सेस और लीस्ट प्रिविलेज लागू करें</h2>\n<p>मजबूत पासवर्ड अत्यधिक अनुमतियों (permissions) का विकल्प नहीं हैं। उपयोगकर्ता को केवल उन्हीं सिस्टम/गुप्त जानकारी की अनुमति दें, जो उनकी भूमिका के लिए जरूरी है।</p>\n<h2>संदिग्ध गतिविधि की निगरानी करें</h2>\n<p>असामान्य लॉगिन, असंभव यात्रा, कई बार विफल प्रयास, नए देश से लॉगिन, और सामान्य कार्य समय के बाहर एक्सेस का पता लगाएं। पासवर्ड नीति को निगरानी और घटना प्रतिक्रिया के साथ मजबूत करें।</p>\n<h2>उपयोगकर्ताओं को वास्तविक खतरों के बारे में प्रशिक्षित करें</h2>\n<p>प्रशिक्षण पासवर्ड पुनः उपयोग, फिशिंग, नकली लॉगिन पेज, MFA थकावट, सुरक्षित साझाकरण, और समझौते की रिपोर्ट कैसे करें, इन विषयों पर केन्द्रित हो। उपयोगकर्ता को दोष न दें, सुरक्षित व्यवहार को आसान बनाएं।</p>\n<h2>नीति को इतना छोटा रखें कि सभी पालन कर सकें</h2>\n<p>पासवर्ड नीति समझने योग्य होनी चाहिए। बहुत लंबी, अस्पष्ट, या बहुत सख्त नीति से लोग उसे दरकिनार कर देते हैं। सर्वोत्तम नीति वही है, जिसे वाकई लागू और अनुसरण किया जा सके।</p>\n<h2>तैयार पासवर्ड नीति टेम्प्लेट</h2>\n<p>निम्न टेम्प्लेट को आरंभ बिंदु के रूप में उपयोग करें। हरे ब्रैकेट वाले हिस्से अपनी संस्था, सिस्टम, जोखिम स्तर और कानूनी आवश्यकताओं अनुसार बदलें।</p>\n<pre><code class=\"language-text\">पासवर्ड नीति\n\nसंस्करण: [1.0]\nमालिक: [सुरक्षा / आईटी विभाग]\nप्रभावी तिथि: [YYYY-MM-DD]\nसमीक्षा चक्र: [हर 12 महीने]\n\n1. उद्देश्य\n\nयह नीति [संगठन का नाम] के लिए पासवर्ड के निर्माण, उपयोग, भंडारण, साझा करने और बदलने की आवश्यकताओं को परिभाषित करती है। असंगत पहुँच, क्रेडेंशियल चोरी, खाता अधिग्रहण और डेटा हानि के जोखिम को कम करना उद्देश्य है।\n\n2. दायरा\n\nयह नीति सभी कर्मचारियों, ठेकेदारों, अस्थायी स्टाफ, सेवा प्रदाताओं, और अन्य सभी उपयोगकर्ताओं पर लागू होती है, जो [संगठन का नाम] के सिस्टम, एप्लिकेशन, नेटवर्क, क्लाउड सेवा या डेटा को एक्सेस करते हैं।\n\nयह नीति साधारण, प्रिविलेज्ड, सेवा, साझा खाते और उन सभी सिस्टम्स पर लागू होती है, जहाँ प्रमाणीकरण के लिए पासवर्ड का उपयोग किया जाता है।\n\n3. पासवर्ड निर्माण आवश्यकताएँ\n\nसभी पासवर्ड निम्नलिखित आवश्यकताओं को पूरा करें:\n\n- मानव-उपयोगकर्ता खाते कम से कम 16 अक्षर वाले पासवर्ड का उपयोग करें।\n- पासवर्ड अद्वितीय हो एवं कार्य या निजी खातों में पुनः उपयोग न हों।\n- पासवर्ड में नाम, उपयोगकर्ता नाम, कंपनी का नाम, जन्मदिन, कीबोर्ड पैटर्न, रिपीटेड कैरेक्टर, या अन्य अनुमान योग्य जानकारी न हो।\n- पासवर्ड आम वाक्यांश, कोट्स, गाने के बोल, या अनुमान योग्य बदलाव पर आधारित न हों।\n- पासवर्ड ज्ञात डेटा उल्लंघन या सामान्य पासवर्ड सूची में न हों।\n- पासवर्ड में स्पेस, प्रतीक, अंक, अपरकेस और लोअरकेस अक्षर हो सकते हैं।\n- पासफ्रेज़ स्वीकार्य हैं अगर वे लंबे, अद्वितीय, और सार्वजनिक या अनुमान योग्य वाक्यांशों पर आधारित न हों।\n\n4. पासवर्ड मैनेजर\n\n[संगठन का नाम] अनुमोदित पासवर्ड मैनेजर के उपयोग को पासवर्ड बनाने, संग्रहित करने, और साझा करने के लिए अनिवार्य या दृढ़ता से प्रोत्साहित करता है।\n\nउपयोगकर्ता स्वीकृत पासवर्ड मैनेजर की पासवर्ड जनरेट, ऑटोफिल, और कॉपी-पेस्ट सुविधा का उपयोग कर सकते हैं। ब्राउज़र, स्प्रेडशीट, दस्तावेज़, नोट्स ऐप्स, ईमेल, चैट मैसेज, स्क्रीनशॉट या अनधिकृत टूल्स में पासवर्ड स्टोर न करें।\n\n5. मल्टी-फैक्टर प्रमाणीकरण\n\nतकनीकी रूप से संभव हो, वहाँ मल्टी-फैक्टर प्रमाणीकरण अनिवार्य है, विशेषकर:\n\n- ईमेल खाते\n- रिमोट एक्सेस सिस्टम्स\n- पासवर्ड मैनेजर खाते\n- क्लाउड सेवाएँ\n- प्रशासनिक खाते\n- वित्त, मानव संसाधन, अन्य उच्च जोखिम वाले सिस्टम्स\n- [गोपनीय / महत्वपूर्ण] क्लासिफाइड कोई भी सिस्टम\n\nजहाँ उपलब्ध हो, वहाँ उपयोगकर्ता पासकी, हार्डवेयर सुरक्षा कुंजी, या प्लेटफॉर्म ऑथेंटिकेटर जैसे फिशिंग-प्रतिरोधी MFA का उपयोग करें। ऑथेंटिकेटर ऐप SMS से बेहतर है। SMS-आधारित MFA तभी अनुमति है जब कोई अन्य मजबूत MFA तकनीकी रूप से उपलब्ध न हो।\n\n6. पासवर्ड परिवर्तन\n\nपासवर्ड तुरंत बदलें जब:\n\n- पासवर्ड समझौता होना ज्ञात या संदिग्ध हो।\n- उपयोगकर्ता ने किसी संदिग्ध फिशिंग साइट में पासवर्ड दर्ज किया हो।\n- पासवर्ड अनधिकृत व्यक्ति के साथ साझा किया गया हो।\n- उपयोगकर्ता के डिवाइस में मैलवेयर या अनधिकृत एक्सेस मिला हो।\n- पासवर्ड किसी ज्ञात डेटा उल्लंघन में दिखा हो।\n- प्रिविलेज्ड उपयोगकर्ता की भूमिका या रोजगार स्थिति बदले।\n- आईटी/सुरक्षा द्वारा पासवर्ड बदलने का निर्देश मिले।\n\nरूटीन पासवर्ड एक्सपायरी केवल कानूनी, नियामक, अनुबंध या सिस्टम की बाध्यता होने पर आवश्यक है। पासवर्ड केवल छोटे, अनुमाननीय बदलाव करके न बदलें।\n\n7. पासवर्ड साझा करना\n\nपासवर्ड ईमेल, चैट, टिकट, दस्तावेज़, स्क्रीनशॉट, फोन कॉल या मौखिक तौर पर साझा न करें।\n\nसाझा क्रेडेंशियल्स केवल तब जब व्यक्तिगत खाता बनाना संभव न हो या [सुरक्षा/आईटी] द्वारा स्पष्ट स्वीकृति हो। मान्यता प्राप्त पासवर्ड मैनेजर द्वारा सुरक्षित तरीके से, सीमित अधिकृत उपयोगकर्ताओं तक ही साझा करें।\n\n8. प्रिविलेज्ड अकाउंट\n\nप्रिविलेज्ड खातों को ऐसे अद्वितीय पासवर्ड का उपयोग करना चाहिए, जो किसी भी सामान्य खाते में प्रयुक्त न हो। इन खातों में जहाँ संभव हो, वहाँ MFA अनिवार्य है और नियमित समीक्षा होनी चाहिए।\n\nप्रिविलेज्ड पासवर्ड तब बदलें जब कोई प्रशासक संस्थान छोड़े, भूमिका बदले, एक्सेस की आवश्यकता न रहे, या समझौते की आशंका हो।\n\n9. सेवा खाते और ऐप्लीकेशन सीक्रेट्स\n\nसेवा खातों के पासवर्ड, API कुंजी, टोकन, और एप्लिकेशन सीक्रेट्स स्वीकृत सीक्रेट्स मैनेजमेंट सिस्टम या पासवर्ड मैनेजर में संग्रहीत करें।\n\nसेवा खाता क्रेडेंशियल्स को सोर्स कोड, कन्फिगरेशन फाइल, इमेज, डाक्यूमेंटेशन, या स्क्रिप्ट्स में न डालें, जब तक कोई सुरक्षित प्रबंधन प्रक्रिया न हो।\n\n10. पासवर्ड रीसेट और खाता रिकवरी\n\nपासवर्ड रीसेट प्रक्रिया में उपयोगकर्ता की पहचान सत्यापित की जानी चाहिए। रीसेट लिंक और टेम्पररी पासवर्ड केवल एक बार उपयोग हेतु, शीघ्र समाप्त, तथा अनुमोदित माध्यम से प्रेषित हो।\n\nजब भी पासवर्ड बदला या रीसेट किया जाए, उपयोगकर्ता को सूचित करें। टेम्पररी पासवर्ड को पहले लॉगिन पर तुरंत बदलें।\n\n11. तकनीकी नियंत्रण\n\nजो सिस्टम पासवर्ड स्टोर या प्रोसेस करते हैं, वे:\n\n- कभी भी पासवर्ड प्लेन टेक्स्ट में न रखें।\n- पासवर्ड का हैशिंग मात्र स्वीकृत, आधुनिक, सॉल्टेड हैश एल्गोरिदम (PBKDF2, scrypt, bcrypt, Argon2) से करें।\n- केवल MD5, SHA-1, SHA-256, SHA-512 आदि फास्ट हैश एल्गोरिदम का अकेले प्रयोग न करें।\n- प्रमाणीकरण एंडपॉइंट को रेट लिमिटिंग या समकक्ष नियंत्रण से सुरक्षित करें।\n- सामान्य, कमजोर, और उल्लंघन में दिखे पासवर्ड अस्वीकार करें।\n- पासवर्ड मैनेजर से पासवर्ड पेस्ट करने की अनुमति दें।\n- तकनीकी रूप से संभव हो तो कम से कम 64 अक्षर की लंबाई तक पासवर्ड का समर्थन करें।\n- महत्वपूर्ण प्रमाणीकरण घटनाओं का लॉग रखें।\n\n12. समझौते का संदेह होने पर रिपोर्टिंग\n\nउपयोगकर्ता तुरंत [सुरक्षा / आईटी संपर्क] को पासवर्ड समझौते, फिशिंग, असामान्य लॉगिन प्रोम्प्ट, स्वयं द्वारा आरंभ नहीं किए गए MFA प्रोम्प्ट, या आकस्मिक पासवर्ड प्रकटीकरण की सूचना दें।\n\n13. अपवाद\n\nइस नीति के अपवाद लिखित, जोखिम-संवेदन, समयबद्ध और [सुरक्षा/आईटी नेतृत्व] की स्वीकृति से ही लागू हों। जहाँ संभव हो, पूरक नियंत्रक (compensating controls) लागू करें।\n\n14. प्रवर्तन\n\nइस नीति का पालन न करने पर एक्सेस हटाना, अनिवार्य सुरक्षा प्रशिक्षण, अनुशासनात्मक कार्रवाई, या अन्य [संगठन के नाम] की नीति व कानूनानुसार कदम उठाए जा सकते हैं।\n\n15. समीक्षा\n\nइस नीति की वार्षिक समीक्षा हो या सिस्टम, खतरे, कानूनी आवश्यकता, या व्यापार में महत्वपूर्ण परिवर्तन के बाद समीक्षा की जाए।\n</code></pre>\n<h2>अंतिम विचार</h2>\n<p>मजबूत पासवर्ड नीति का अर्थ पासवर्ड को कठिन बनाना नहीं है, बल्कि कमजोर आदतें हटाना, पासवर्ड मैनेजर का समर्थन, MFA का प्रयोग, और जब क्रेडेंशियल्स उजागर हों तो तुरंत प्रतिक्रिया देना है। नीति को व्यावहारिक, लागू करने योग्य और वास्तविक खतरों—जैसे फिशिंग, क्रेडेंशियल स्टफिंग, पासवर्ड पुनः उपयोग, और खातों के समझौते—पर केन्द्रित रखें।</p>","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"पासवर्ड नीति: क्या करें, क्या न करें, सर्वोत्तम अभ्यास, और एक तैयार टेम्प्लेट","description":"जानें कि एक आधुनिक पासवर्ड नीति में क्या होना चाहिए, किन पुराने नियमों से बचना चाहिए, और अपनी संस्था के लिए व्यावहारिक टेम्प्लेट कॉपी करें।","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"hi","langPathPrefix":"/hi"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}