हर डिवाइस को लॉक आउट किए बिना VPN पासवर्ड बदलें

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

मिथक: एक परिवर्तन, हर जगह एक साथ

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

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

रोटेशन से पहले प्रतियों की सूची बनाएँ

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

ऑफ़लाइन डिवाइस चिरपरिचित चूक हैं। दराज़ में रखा लैपटॉप तीन सप्ताह बाद लौटता है और सबसे बुरे क्षण पर पुराना मान प्रस्तुत करता है। उसका स्थान और समय-सारिणी भी लिखें, क्योंकि उसका इंतज़ार करने के बजाय आपको उसका पीछा करना होगा।

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

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

प्रतियों को उनके स्वामियों के विरुद्ध तौलें। जिस डिवाइस का दावा कोई नहीं करता, वह ऐसा डिवाइस है जिसे कोई अपडेट नहीं करेगा, और वही फिर प्रयास जारी रखने की सर्वाधिक संभावना रखता है।

आप वास्तव में कौन-सा रहस्य घुमा रहे हैं

खाता पासवर्ड VPN परिनियोजन में केवल एक क्रेडेंशियल है। कुंजी पासफ़्रेज़, प्रमाणपत्र पहचान और वैकल्पिक पीयर रहस्य—हर एक का अपना प्रतिस्थापन मार्ग और अपना स्वामी है। खाता पासवर्ड बदलने से प्रमाणपत्र से प्रमाणित होने वाले डिवाइस के लिए कुछ नहीं होता, और प्रमाणपत्र फिर जारी करने से सहेजा पासवर्ड रखने वाले क्लाइंट के लिए कुछ नहीं होता। समाधान का नाम लेने से पहले रहस्य का नाम लें।

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

सहेजा मान वहीं बदलें जहाँ वह रहता है

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

पासवर्ड फ़ाइल सहेजने वाले क्लाइंट को फ़ाइल फिर से लिखी हुई चाहिए, जबकि पूछने वाले क्लाइंट को पूर्ण साइन-इन चाहिए। NetworkManager रहस्य कनेक्शन प्रोफ़ाइल के भीतर रखता है, इसलिए परिवर्तन टेक्स्ट संपादक के बजाय nmcli से जाता है:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

क्रेडेंशियल फ़ाइल पढ़ने वाली प्रोफ़ाइल तीसरा मामला है। उस फ़ाइल की सामग्री बदलें, उसकी अनुमतियाँ बंद रखें, और उसकी ओर संकेत करने वाली प्रोफ़ाइल संपादित करने के बजाय क्लाइंट फिर लोड करें। प्रोफ़ाइल नहीं बदली; केवल वह रहस्य बदला जो वह पढ़ती है।

हर इच्छित डिवाइस को एक बार जानबूझकर फिर जोड़ें और देखें कौन विफल होते हैं। यदि कोई डिवाइस विफल होता रहे, तो पासवर्ड फिर बदलने से पहले उस खाते को देखें जिसकी ओर वह संकेत करता है और उस भंडार को देखें जो वह पढ़ता है, क्योंकि दूसरा परिवर्तन अपडेट करने योग्य प्रतियों को कई गुना बढ़ा देता है। दो बार विफल होने वाला डिवाइस आम तौर पर गलत खाते की ओर संकेत करता है या ऐसा भंडार पढ़ता है जो आपने अभी नहीं खोजा। उसे ठीक करें, फिर दोबारा जोड़ें।

सत्र और टोकन पासवर्ड से अधिक जीते हैं

पासवर्ड बदलना यह सिद्ध नहीं करता कि मौजूदा सत्र या अलग प्रमाणपत्र रद्द किए गए। कुछ सेवाएँ सत्र को तब तक जीवित रखती हैं जब तक वह समाप्त न हो या स्पष्ट रूप से बंद न किया जाए, और जारी किए गए टोकन अपनी आयु लेकर चलते हैं। परिवर्तन वैश्विक था यह मानने के बजाय जाँचें कि सेवा वास्तव में क्या करती है। यदि परिवर्तन संदेह से प्रेरित था, तो सत्र स्पष्ट रूप से समाप्त करें और परिणाम की पुष्टि करें।

NIST SP 800-63B में क्रेडेंशियल जीवनचक्र मार्गदर्शन प्रमाणकों और सत्रों को अलग श्रेणियों में रखता है, इसीलिए पासवर्ड परिवर्तन और वैश्विक लॉगआउट अलग-अलग कार्रवाइयाँ हैं। इन्हें दो पूर्णता मानदंडों वाले दो कार्य मानें। पहला तब पूरा होता है जब नया मान काम करता है, और दूसरा तब पूरा होता है जब पुराने सत्र चले जाते हैं।

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