पासवर्ड या कुकी साझा किए बिना ब्राउज़र काम कैसे सौंपें

टीम अक्सर कहती है कि उसे ‘लॉगिन साझा करना’ है, जबकि असली ज़रूरत छोटी होती है: ड्राफ़्ट जाँचना, अधिकृत स्टोर अपडेट करना, क्षेत्रीय बग दोहराना या सहायता का काम जारी रखना। पासवर्ड के बजाय काम से शुरुआत करने पर अधिक विकल्प मिलते हैं।

कौन-सी चीज़ वास्तविक क्रेडेंशियल है

स्पष्ट उदाहरण हैं पासवर्ड, रिकवरी कोड, एकबारगी पासवर्ड बनाने का सीड, निजी कुंजी और प्रॉक्सी पासवर्ड। ब्राउज़र काम में कम दिखने वाले क्रेडेंशियल भी आते हैं:

• प्रमाणीकरण कुकी और सत्र पहचानकर्ता;
• OAuth ऐक्सेस और रीफ़्रेश टोकन;
• पासवर्ड मैनेजर रिकॉर्ड और ऑटोफ़िल डेटा;
• पासकी की निजी कुंजी या उसे रखने वाले प्रमाणीकरण साधन की पहुँच;
• विश्वसनीय डिवाइस और पुनर्प्राप्ति स्थिति; और
• इनमें कुछ भी रखने वाला प्रोफ़ाइल आर्काइव।

NIST सत्र मार्गदर्शन ब्राउज़र सत्र को सत्र रहस्य के कब्ज़े पर आधारित निरंतरता बताता है। OWASP सत्र प्रबंधन गाइड इसका व्यावहारिक परिणाम स्पष्ट करती है: वैध रहते समय सत्र टोकन उसे बनाने वाले सबसे मज़बूत प्रमाणीकरण के बराबर हो सकता है।

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

काम और अधिकार अलग करें

साझाकरण विधि चुनने से पहले छोटा पहुँच कथन लिखें:

नामित ऑपरेटर A, स्वीकृत डिवाइस D से, समय E तक, स्वीकृति और ऑडिट नियम F के अंतर्गत, संसाधन C पर कार्रवाइयाँ B कर सकता है।

इस वाक्य से अनावश्यक अधिकार दिखते हैं। काम ‘यह ड्राफ़्ट मंज़ूर करना’ हो तो पूरा प्रशासनिक सत्र बहुत अधिक है। लक्ष्य सेवा में समीक्षक भूमिका पहले से हो तो ब्राउज़र स्थिति साझा करना क्षमता बढ़ाए बिना जोखिम जोड़ता है।

NIST की ज़ीरो ट्रस्ट संरचना काम के लिए आवश्यक न्यूनतम अधिकार से प्रति सत्र अलग संसाधन की पहुँच सुझाती है। ‘ज़ीरो ट्रस्ट’ नाम का उत्पाद अपनाए बिना भी यह सिद्धांत लागू है। हर ब्राउज़र हैंडऑफ़ के डिज़ाइन को परखने में यह उपयोगी है।

इन मॉडलों को इस क्रम में प्राथमिकता दें

1. लक्ष्य सेवा पर व्यक्तिगत पहुँच

वेबसाइट या ऐप की अपनी टीम, संगठन, भूमिका, प्रतिनिधि पहुँच या स्वीकृति सुविधा उपलब्ध हो तो वही लें। हर व्यक्ति अपने खाते और प्रमाणीकरण साधन से साइन इन करे। तब लक्ष्य सेवा अनुमतियाँ लागू कर सकती है, ऑपरेटर को कार्रवाई से जोड़ सकती है, अपने जोखिम नियंत्रण लगा सकती है और सबका क्रेडेंशियल बदले बिना एक व्यक्ति की पहुँच हटा सकती है।

यह सामान्यतः सबसे मज़बूत मॉडल है क्योंकि अधिकार वहीं तय होता है जहाँ कार्रवाई का अर्थ समझा जाता है। ब्राउज़र मैनेजर किसी साइट के साझा व्यवस्थापक सत्र को भरोसेमंद तरीके से साइट की समीक्षक भूमिका नहीं बना सकता।

साझा और समूह खाते जवाबदेही घटाते हैं। NIST SP 800-53 संशोधन 5 उनका उपयोग सीमित रखने और अनुमति से पहले स्पष्ट शर्तें तय करने की सलाह देता है।

2. लक्ष्य सेवा के सीमित प्रतिनिधि अधिकार

सेवा OAuth या दूसरा प्रतिनिधि प्रोटोकॉल दे तो क्लाइंट या कर्ता को केवल ज़रूरी संसाधन, कार्रवाइयाँ और अवधि दें। RFC 9700 टोकन अधिकार न्यूनतम और ऑडियंस इच्छित संसाधन सर्वर तक सीमित रखने को कहता है।

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

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

3. सहेजे रहस्य का नियंत्रित उपयोग

कुछ पुरानी सेवाओं में केवल साझा क्रेडेंशियल होता है। नियंत्रित क्रेडेंशियल ब्रोकर या पासवर्ड मैनेजर स्वीकृत ब्राउज़र प्रक्रिया को रहस्य इस्तेमाल करने दे सकता है, बिना उसे चैट, टिकट, दस्तावेज़ या सामान्य ऐप आउटपुट में दिखाए। इससे कॉपी करना घटता है।

यह सुरक्षा अभिरक्षा, रहस्य बदलना और पहुँच समीक्षा बेहतर करता है, लेकिन लक्ष्य सेवा का खाता मॉडल नहीं बदलता। लॉगिन के बाद हर ऑपरेटर वही साइट पहचान इस्तेमाल कर सकता है। बना सत्र संवेदनशील रहता है और उसे अपनी समय सीमा, निरस्तीकरण व डिवाइस नियंत्रण चाहिए।

OWASP रहस्य प्रबंधन गाइड बारीक पहुँच, रहस्य मानों से न्यूनतम मानव संपर्क, जीवनचक्र नियंत्रण और किसने रहस्य माँगा व इस्तेमाल किया इसका ऑडिट सुझाती है। जहाँ संभव हो ब्राउज़र उत्पाद गुप्त संदर्भ से जुड़े, दूसरा सामान्य रहस्य भंडार न बने।

4. सुरक्षित ब्राउज़र सत्र हैंडऑफ़

साझा प्रमाणित प्रोफ़ाइल तभी लें जब लक्ष्य सेवा में पर्याप्त प्रतिनिधि पहुँच न हो और अधिकृत काम को सच में सत्र निरंतरता चाहिए। सामान्य हैंडऑफ़ में इसका जोखिम सबसे अधिक है क्योंकि प्राप्तकर्ता सक्रिय खाते से कार्रवाई कर सकता है।

न्यूनतम नियंत्रण में शामिल हैं:

• स्पष्ट स्वामी और स्वीकृत प्राप्तकर्ता;
• तय काम, संसाधन और समाप्ति समय;
• एक सक्रिय लेखक या जाँचा टकराव मॉडल;
• क्लाउड अपलोड से पहले क्लाइंट पर एन्क्रिप्शन;
• प्राप्तकर्ता डिवाइस का प्राधिकरण और स्थानीय सुरक्षा;
• एक साथ काम की अस्पष्टता रोकने वाला लॉक;
• अधिकार देना, डाउनलोड, खोलना, संवेदनशील कार्रवाई, बंद, निरस्तीकरण और पुनर्प्राप्ति के ऑडिट रिकॉर्ड;
• सामान्य इंटरफ़ेस में कुकी या टोकन के बजाय संवेदनशील जानकारी हटाई स्थिति; और
• लक्ष्य सेवा में सत्र निरस्त करने की योजना।

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

5. वास्तविक क्रेडेंशियल सौंपना

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

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

केवल सुविधा नहीं, अधिकार की तुलना करें

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

इसलिए ‘पासवर्ड कोई नहीं देख सकता’ अधूरा सफलता मानदंड है। महत्वपूर्ण है कि प्राप्तकर्ता कितना अधिकार इस्तेमाल कर सकता है, कितनी देर और कौन-सी प्रणाली उसे निरस्त कर सकती है।

पासकी प्रमाणीकरण सुधारती हैं, पर साझाकरण की सीमा है

WebAuthn सेवा तक सीमित सार्वजनिक कुंजी क्रेडेंशियल बनाता है। WebAuthn Level 3 विनिर्देश के अनुसार प्रमाणीकरण साधन निजी कुंजी रखता है और वेबसाइट स्क्रिप्ट को हस्ताक्षरित परिणाम मिलते हैं, निजी क्रेडेंशियल नहीं। सही लागूकरण में इससे फ़िशिंग प्रतिरोधी प्रमाणीकरण मिलता है।

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

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

ब्राउज़र हैंडऑफ़ के स्पष्ट नियम बनाएँ

प्रोफ़ाइल स्थिति भेजने से पहले नियंत्रित हैंडऑफ़ इन सवालों का उत्तर दे:

1. कौन काम कर रहा है? संगठन की व्यक्तिगत पहचान लें, सामान्य ऑपरेटर लेबल नहीं।
2. किसने अधिकृत किया? स्वीकृति रहस्य रखे बिना स्वामी या नीति निर्णय दर्ज करें।
3. क्या साझा है? प्रोफ़ाइल और काम बताएँ; कुकी या क्रेडेंशियल की वास्तविक सूची न दें।
4. प्राप्तकर्ता क्या कर सकता है? लॉन्च, संपादन, निर्यात, ऑटोमेशन, साझाकरण और प्रशासन अलग रखें।
5. कहाँ चल सकता है? डेटा के लिए उपयुक्त पंजीकृत भरोसेमंद डिवाइस तक पहुँच सीमित करें।
6. कितनी देर? समाप्ति तय करें और निष्क्रिय सत्र बंद करें।
7. क्या दो लेखक काम कर सकते हैं? टकराव व्यवहार जानबूझकर डिज़ाइन व परीक्षण न हो तो एक सक्रिय लेखक रखें।
8. क्या दर्ज होगा? कर्ता, डिवाइस, प्रोफ़ाइल संदर्भ, काम, परिणाम और समय लिखें। डिफ़ॉल्ट रूप से रहस्य और पेज सामग्री बाहर रखें।
9. कैसे निरस्त होगा? ब्राउज़र साझाकरण अधिकार और लक्ष्य सेवा सत्र दोनों कवर करें।
10. कैसे बहाल होगा? निरस्त अधिकार गलती से लौटाए बिना आखिरी ज्ञात सही संस्करण रखें।

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

ऑटोमेशन को रहस्य की सीमा से बाहर रखें

API, SDK, कमांड लाइन टूल और एजेंट को अक्सर प्रोफ़ाइल शुरू करना या स्वीकृत जीवनचक्र कार्रवाई करनी होती है। उन्हें शायद ही कभी कुकी मान, पासवर्ड, पासकी, प्रॉक्सी क्रेडेंशियल या कच्चा आर्काइव चाहिए।

सीमित इंटरफ़ेस गुप्त प्रोफ़ाइल या रहस्य संदर्भ स्वीकार करके लौटा सकता है:

• कार्रवाई अधिकृत हुई या नहीं;
• संवेदनशील जानकारी रहित स्थिति, जैसे तैयार, लॉक, समाप्त या निरस्त;
• सीमित अवधि का प्रक्रिया या सत्र संदर्भ;
• संरचित त्रुटि और पुनर्प्राप्ति कदम; और
• ऑडिट घटना संदर्भ।

केवल लॉन्च अधिकार होने से क्रेडेंशियल नहीं लौटना चाहिए। निर्यात, सामूहिक साझाकरण या दूसरी रहस्य वाली कार्रवाई के लिए अलग नीति और जहाँ उचित हो स्पष्ट स्वीकृति चाहिए।

वेबसाइट सामग्री और ऑटोमेशन इनपुट भी अविश्वसनीय हैं। पेज का निर्देश एजेंट को लॉग, टूल आउटपुट, स्क्रीनशॉट या सहायता माध्यम से सत्र सामग्री निकालने के लिए नहीं मना सके।

निरस्तीकरण के दो स्तर हैं

ब्राउज़र वर्कस्पेस से सहयोगी हटाने पर उस वर्कस्पेस से आगे की अधिकृत पहुँच रुकती है। इससे लक्ष्य सेवा का सत्र अमान्य होना सिद्ध नहीं होता। डिवाइस पर खुली स्थिति पहले से हो सकती है और कॉपी या चल रहा सत्र जारी रह सकता है।

सामान्य रूप से पहुँच खत्म होने पर:

1. टीम अधिकार हटाएँ और प्रोफ़ाइल लीज़ बंद करें;
2. प्रतिधारण नीति के अनुसार स्थानीय एन्क्रिप्टेड सामग्री हटाएँ;
3. जहाँ समर्थित हो लक्ष्य सेवा में संबंधित सत्र समाप्त करें;
4. सेवा की सदस्यता या प्रतिनिधि अधिकार हटाएँ; और
5. स्वीकृत अवधि तक संवेदनशील जानकारी रहित ऑडिट प्रमाण रखें।

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

सावधानी से हैंडऑफ़ के बाद भी बची सीमाएँ

• क्लाइंट एन्क्रिप्शन सहेजे और भेजे डेटा को बचाता है, लेकिन अधिकृत डिवाइस को ब्राउज़र की आवश्यक सामग्री खोलनी पड़ती है।
• ब्राउज़र लॉक उत्पाद के समवर्ती उपयोग को नियंत्रित करता है, लक्ष्य सेवा की हर कार्रवाई को नहीं।
• ब्राउज़र का ऑडिट विस्तृत हो, फिर भी साझा सत्र लक्ष्य सेवा को सामान्यतः एक खाता पहचान देता है।
• प्रभावित डिवाइस या एक्सटेंशन पढ़ने योग्य पासवर्ड निकाले बिना वैध सत्र से काम कर सकता है।
• वर्कस्पेस अधिकार हटाना और वेबसाइट सत्र निरस्त करना अलग काम हैं।
• सेवा शर्तें, क्लाइंट अनुबंध और लागू कानून अब भी तय करते हैं कि काम सौंपा जा सकता है या नहीं।
• कुछ सेवाओं में व्यक्तिगत पहुँच का सुरक्षित विकल्प नहीं है। वहाँ दायरा घटाना या हैंडऑफ़ से इनकार ज़िम्मेदार परिणाम हो सकता है।

RFC 6265 कुकी को स्वतः लागू अधिकार के रूप में समझाता है: अनुरोध करवाने वाले को कुकी का मान पता न हो, फिर भी ब्राउज़र उसे अनुरोध में जोड़ सकता है। सत्र साझाकरण की यही केंद्रीय सीमा है। क्रेडेंशियल छिपाने से उनका खुलना घटता है; ब्राउज़र के इस्तेमाल कर सकने वाले अधिकार नहीं घटते।