डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) की व्याख्या

Enterprise Passkey व्हाइटपेपर. passkey कार्यक्रमों के लिए व्यावहारिक मार्गदर्शन, रोलआउट पैटर्न और KPIs।

व्हाइटपेपर पाएं

ब्राउज़र सपोर्ट की स्थिति

लीजेंड: ✅ सामान्य रूप से उपलब्ध | 🚧 घोषित / विकास में | ⏸️ ट्रायल समाप्त | 🔄 मूल्यांकन/निगरानी | ❌ अभी तक उपलब्ध नहीं

नोट: Chrome 146 (अप्रैल 2026) तक विंडोज़ पर TPM के साथ DBSC GA है। सिक्योर एन्क्लेव के माध्यम से macOS सपोर्ट इसके बाद रोल आउट हो रहा है। Google के बताए गए रोडमैप में सुरक्षित हार्डवेयर के बिना डिवाइस तक सुरक्षा का विस्तार करने के लिए सॉफ़्टवेयर-आधारित की भी शामिल हैं।

प्रमुख लाभ: DBSC बनाम वर्तमान मॉडल

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

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

जैसे-जैसे उद्योग FIDO (Fast Identity Online) मानकों और पासकीज़ को अपनाकर प्रमाणीकरण के "सामने के दरवाजे" को सफलतापूर्वक मज़बूत कर रहा है, हमलावर अपना ध्यान "पीछे के दरवाजे": सक्रिय सेशन पर केंद्रित कर रहे हैं। पासवर्ड की फ़िशिंग करना कठिन होता जा रहा है, लेकिन सेशन कुकी चुराना खतरनाक रूप से प्रभावी बना हुआ है। इस बढ़ते खतरे के लिए उद्योग की प्रतिक्रिया डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) है।

DBSC वेब सेशन को बनाए रखने के तरीके में एक आदर्श बदलाव का प्रतिनिधित्व करता है। यह सरल बियरर टोकन से ऐसे मॉडल की ओर बढ़ने का प्रस्ताव करता है जहां सेशन क्रिप्टोग्राफ़िक रूप से डिवाइस से बाउंड होता है। Chrome 146 (अप्रैल 2026) द्वारा विंडोज़ पर DBSC को GA में शिप करने के साथ, मानक प्रयोगात्मक से एक उत्पादन क्षमता में चला गया है जिसे वेब टीमें आज तैनात कर सकती हैं। Chrome विंडोज़ पर TPMs का उपयोग करता है और इसके बाद macOS पर सिक्योर एन्क्लेव के लिए सपोर्ट रोल आउट कर रहा है; मानक स्वयं की स्टोरेज के बारे में अज्ञेयवादी है, केवल यह आवश्यकता है कि यह "वर्णित खतरे के खिलाफ मज़बूत" हो। यह चोरी की कुकीज़ को बहुत कम मूल्यवान बनाता है। उन्हें बाउंड की के बिना किसी अन्य डिवाइस से रिफ्रेश नहीं किया जा सकता है।

यह लेख DBSC का एक संपूर्ण विश्लेषण प्रदान करता है, जिसे सुरक्षा आर्किटेक्ट, उत्पाद प्रबंधकों और डेवलपर्स के लिए डिज़ाइन किया गया है। यह तकनीकी वास्तुकला, "घर्षण रहित सुरक्षा" के व्यावसायिक निहितार्थ, शेयर्ड सिग्नल्स (CAEP/RISC) जैसे उभरते मानकों के साथ संबंध और Corbado जैसे प्लेटफ़ॉर्म का उपयोग करके संगठन इस भविष्य की तैयारी कैसे कर सकते हैं, इसका पता लगाता है।

प्रमुख प्रश्न जिनका उत्तर यह लेख देता है

1. अकाउंट टेकओवर को रोकने में वर्तमान सेशन प्रबंधन क्यों विफल हो रहा है?
2. DBSC मौजूदा "Secure" कुकीज़ और HttpOnly फ़्लैग से कैसे भिन्न है?
3. मज़बूत फ़िशिंग प्रतिरोध के लिए DBSC और पासकीज़ एक साथ कैसे काम करते हैं?
4. टोकन बाइंडिंग का क्या हुआ, और DBSC वहां क्यों सफल हो रहा है जहां यह विफल रहा?
5. उत्पाद प्रबंधकों के लिए व्यावसायिक निहितार्थ और ROI क्या हैं?
6. आज कौन से ब्राउज़र और ऑपरेटिंग सिस्टम DBSC का समर्थन करते हैं?
7. संगठन स्क्रैच से निर्माण किए बिना DBSC को कैसे लागू कर सकते हैं?
8. DBSC, DPoP और OAuth 2.0 के बीच क्या संबंध है?
9. वास्तविक समय के खतरे की प्रतिक्रिया के लिए DBSC शेयर्ड सिग्नल्स (CAEP/RISC) के साथ कैसे एकीकृत होता है?

इस नए मानक की जटिलता को नेविगेट करने के लिए, हमें सबसे पहले वर्तमान सेशन प्रबंधन की मूलभूत समस्याओं को समझना चाहिए और यह भी समझना चाहिए कि DBSC कैसे समाधान प्रदान करता है। इनमें से प्रत्येक क्षेत्र एक महत्वपूर्ण कमज़ोरी या सीमा का प्रतिनिधित्व करता है जिसे DBSC संबोधित करता है।

वर्तमान सेशन प्रबंधन की मूलभूत विफलता विश्वास की "पोर्टेबिलिटी" है। जब कोई सर्वर सेशन कुकी जारी करता है, तो वह अनिवार्य रूप से एक पासपोर्ट जारी कर रहा होता है जो इसे रखने वाले किसी भी व्यक्ति के लिए काम करता है। जबकि ब्राउज़रों ने HttpOnly और Secure फ़्लैग (JavaScript एक्सेस को रोकना और HTTPS पर ट्रांसमिशन सुनिश्चित करना) जैसे बचाव लागू किए हैं, ये बचाव केवल क्रॉस-साइट स्क्रिप्टिंग (XSS) या नेटवर्क स्निफ़िंग जैसे विशिष्ट निष्कर्षण वैक्टर से रक्षा करते हैं। वे होस्ट डिवाइस पर चल रहे मैलवेयर के खिलाफ कोई सुरक्षा प्रदान नहीं करते हैं। "इन्फोस्टीलर्स" विशेष रूप से डिस्क पर ब्राउज़र की कुकी स्टोरेज फ़ाइल का पता लगाने, उसे डिक्रिप्ट करने (अक्सर उपयोगकर्ता के स्वयं के OS-स्तर क्रेडेंशियल्स का उपयोग करके), और कमांड-एंड-कंट्रोल सर्वर को सामग्री निकालने के लिए डिज़ाइन किए गए मैलवेयर हैं। एक बार जब हमलावर के पास कुकी आ जाती है, तो वे एक पास-द-कुकी हमला कर सकते हैं, सेशन को हाईजैक करने के लिए अपने स्वयं के ब्राउज़र में चोरी किए गए टोकन को इंजेक्ट कर सकते हैं। सर्वर, एक मान्य कुकी को देखकर, मान लेता है कि अनुरोध वैध है।

DBSC सेशन रखरखाव लूप में ही प्रमाणीकरण का दूसरा कारक पेश करता है। एक मानक सुरक्षित कुकी के विपरीत, जो एक स्थिर रहस्य है, DBSC सेशन में एक अल्पकालिक बियरर टोकन और कब्जे का क्रिप्टोग्राफ़िक प्रमाण होता है। ब्राउज़र डिवाइस पर सुरक्षित रूप से संग्रहीत एक पब्लिक-प्राइवेट की पेयर उत्पन्न करता है। सर्वर सेशन को पब्लिक की से बाइंड करता है। समय-समय पर, ब्राउज़र को यह साबित करना होगा कि उसके पास अभी भी सर्वर से एक चुनौती पर हस्ताक्षर करके प्राइवेट की है। मानक को की स्टोरेज की आवश्यकता है "वर्णित खतरे के खिलाफ मज़बूत"। उपलब्ध होने पर Chrome विंडोज़ पर TPM का उपयोग करता है। यदि कोई हमलावर किसी भिन्न डिवाइस से कुकी चुराता है, तो वे इसे रिफ्रेश नहीं कर सकते क्योंकि वे आवश्यक क्रिप्टोग्राफ़िक सिग्नेचर उत्पन्न नहीं कर सकते। "बियरर" पहलू को एक बहुत छोटी विंडो तक कम कर दिया जाता है, जबकि "बाइंडिंग" पहलू दीर्घकालिक निरंतरता प्रदान करता है।

पासकीज़ और DBSC पूरक प्रौद्योगिकियां हैं जो उपयोगकर्ता जीवनचक्र के विभिन्न चरणों को सुरक्षित करती हैं। पासकीज़ (FIDO2) प्रमाणीकरण समस्या को हल करती हैं पासवर्ड के बिना सेशन शुरू करने के लिए पहचान साबित करती हैं, इस प्रकार क्रेडेंशियल फ़िशिंग को समाप्त करती हैं। DBSC पोस्ट-प्रमाणीकरण समस्या को संबोधित करता है जिससे कुकी चोरी के माध्यम से सेशन हाइजैकिंग काफी कठिन हो जाती है। FIDO एलायंस DBSC को एक पूरक तकनीक के रूप में प्रस्तुत करता है जो सेशन हाइजैकिंग के खिलाफ "बार बढ़ाता है"। एक साथ, वे लॉगिन और सेशन जीवनचक्र में हमले की सतह को कम करते हैं हालांकि DBSC चल रहे डिवाइस एक्सेस वाले मैलवेयर या उसी डिवाइस पर वास्तविक समय के ब्राउज़र-इन-द-मिडल हमलों से बचाव नहीं करता है।

पासकीज़ और DBSC एक साथ कैसे काम करते हैं

DBSC इस समस्या को हल करने का पहला प्रयास नहीं है। "टोकन बाइंडिंग" एक पिछला मानक था जिसने कुकीज़ को अंतर्निहित TLS (Transport Layer Security) कनेक्शन से बाइंड करने का प्रयास किया था। हालांकि क्रिप्टोग्राफ़िक रूप से मज़बूत, टोकन बाइंडिंग TLS लेयर पर अपनी भारी निर्भरता के कारण अपनाने में विफल रहा। आधुनिक वेब में, TLS कनेक्शन अक्सर लोड बैलेंसर, CDNs, या रिवर्स प्रॉक्सी पर समाप्त हो जाते हैं, जबकि एप्लिकेशन लॉजिक उनके पीछे सर्वर पर रहता है। इन जटिल नेटवर्क लेयर्स के माध्यम से टोकन बाइंडिंग जानकारी का प्रचार करना बहुत कठिन साबित हुआ। DBSC इस विफलता से पूरी तरह से एप्लिकेशन लेयर (HTTP) पर काम करके सीखता है। यह अंतर्निहित नेटवर्क कनेक्शन पर निर्भर नहीं करता है, जो इसे मौजूदा लोड बैलेंसर, प्रॉक्सी और क्लाउड बुनियादी ढांचे के साथ संगत बनाता है।

उत्पाद लीडरों के लिए, DBSC उपयोगकर्ता अनुभव (UX) में सुधार करते हुए सुरक्षा में सुधार करने का एक अवसर प्रदान करता है। परंपरागत रूप से, उच्च सुरक्षा का मतलब छोटे सेशन टाइमआउट था, जिससे उपयोगकर्ताओं को बार-बार लॉग इन करने के लिए मजबूर होना पड़ता था (घर्षण)। सेशन को डिवाइस से बाइंड करके, रिमोट कुकी चोरी का जोखिम काफी कम हो जाता है। व्यवसाय लंबी सेशन अवधि पर विचार कर सकते हैं, यह जानकर कि चोरी की कुकीज़ को किसी अन्य डिवाइस से रिफ्रेश नहीं किया जा सकता है। हालांकि, DBSC डिवाइस की चोरी, डिवाइस पर लगातार मैलवेयर, या किसी दुर्भावनापूर्ण उपयोग द्वारा दुरुपयोग से रक्षा नहीं करता है, इसलिए सेशन जीवनकाल नीतियों को अभी भी इन अवशिष्ट जोखिमों को प्रतिबिंबित करना चाहिए।

DBSC के पीछे की तात्कालिकता को समझने के लिए, किसी को आधुनिक खतरे के परिदृश्य की जटिलता की सराहना करनी चाहिए। सेशन कुकीज़ की चोरी एक विशिष्ट हैकर ट्रिक से एक स्केलेबल, स्वचालित उद्योग में स्नातक हो गई है।

graph TD
    A[उपयोगकर्ता दुर्भावनापूर्ण सॉफ़्टवेयर<br/>डाउनलोड करता है] -->|निष्पादन| B[इन्फोस्टीलर डिवाइस पर<br/>सक्रिय हो जाता है]
    B --> C[ब्राउज़र डेटा का पता लगाता है]
    C --> D[Chrome/Edge/Firefox<br/>कुकी स्टोरेज]
    C --> E[पासवर्ड डेटाबेस]
    C --> F[क्रिप्टो वॉलेट]

    D --> G[OS क्रेडेंशियल्स का उपयोग<br/>करके डिक्रिप्ट करता है]
    E --> G
    F --> G

    G --> H[चोरी किए गए डेटा के साथ<br/>लॉग फ़ाइल बनाता है]
    H --> I[C2 सर्वर पर निकालता है]
    I --> J[डार्क वेब मार्केटप्लेस]

    J --> K[हमलावर लॉग खरीदता है]
    K --> L[स्वयं के ब्राउज़र में<br/>कुकी इम्पोर्ट करता है]
    L --> M[MFA बायपास करता है]
    M --> N[अकाउंट टेकओवर<br/>पूर्ण]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

मैलवेयर-एज़-ए-सर्विस (MaaS) ने साइबर अपराधियों के लिए प्रवेश की बाधा को कम कर दिया है। RedLine, Raccoon, Vidar और Taurus जैसे "इन्फोस्टीलर्स" व्यावसायिक रूप से उपलब्ध मैलवेयर स्ट्रेन हैं जिन्हें एक प्राथमिक लक्ष्य के साथ डिज़ाइन किया गया है: वेब ब्राउज़रों से डेटा निकालना। ये स्टीलर फ़िशिंग ईमेल, क्रैक किए गए सॉफ़्टवेयर, या दुर्भावनापूर्ण विज्ञापनों के माध्यम से वितरित किए जाते हैं। एक बार स्थापित होने के बाद, वे उन विशिष्ट फ़ाइल पथों को लक्षित करते हैं जहां Chrome, Edge और Firefox जैसे ब्राउज़र अपना डेटा संग्रहीत करते हैं।

• लक्ष्य: कुकीज़ डेटाबेस (आमतौर पर एक SQLite फ़ाइल) और लॉगिन डेटा डेटाबेस (सहेजे गए पासवर्ड)।
• तंत्र: ब्राउज़र डेटा प्रोटेक्शन APIs (विंडोज़ पर DPAPI) का उपयोग करके इन डेटाबेस को उपयोगकर्ता के OS लॉगिन से जोड़कर एन्क्रिप्ट करते हैं। चूंकि मैलवेयर उपयोगकर्ता के रूप में चलता है, इसलिए यह आसानी से इन फ़ाइलों के डिक्रिप्शन का अनुरोध कर सकता है।
• आउटपुट: मैलवेयर एक "लॉग" उत्पन्न करता है - एक ज़िप फ़ाइल जिसमें डिक्रिप्टेड कुकीज़, पासवर्ड, सिस्टम जानकारी और कभी-कभी क्रिप्टो-वॉलेट की शामिल होती हैं।

इन लॉग्स को एकत्र किया जाता है और (इसके बंद होने से पहले) जेनेसिस मार्केट और रशियन मार्केट जैसे डार्क वेब मार्केटप्लेस पर बेचा जाता है। खरीदार विशिष्ट उच्च-मूल्य वाले लक्ष्यों के लिए सक्रिय कुकीज़ वाले लॉग की खोज कर सकते हैं: "Salesforce," "Gmail," "Bank of America," या "AWS Console।"

बायपास: एक कुकी लॉग का मूल्य मल्टी-फैक्टर प्रमाणीकरण (MFA) को बायपास करने की उसकी क्षमता में निहित है। अधिकांश MFA चुनौतियां (SMS, TOTP, Push) केवल लॉगिन इवेंट के दौरान होती हैं। एक बार सेशन स्थापित हो जाने और कुकी जारी हो जाने के बाद, सर्वर मान लेता है कि उपयोगकर्ता विश्वसनीय है। एक वैध सेशन कुकी आयात करने वाला हमलावर सीधे MFA गेट से आगे निकल जाता है, सर्वर को सक्रिय टैब पर लौटने वाले उपयोगकर्ता के रूप में दिखाई देता है।

क्लाउड उत्पादकता सूट प्रमुख लक्ष्य हैं। Google Workspace या Microsoft Entra ID (पूर्व में Azure AD) खाते के लिए एक चोरी की गई सेशन कुकी एक हमलावर को कॉर्पोरेट ईमेल, दस्तावेज़ों और आंतरिक सिस्टम तक पहुंच प्रदान कर सकती है। Google की अपनी खतरे की खुफिया जानकारी ने Google खातों तक पहुंचने के लिए प्राथमिक वेक्टर के रूप में कुकी चोरी में भारी वृद्धि की सूचना दी है, स्पष्ट रूप से इसे DBSC में उनके निवेश के लिए ड्राइवर के रूप में नामित किया है। वे ध्यान देते हैं कि जैसे-जैसे वे 2-स्टेप वेरिफिकेशन (2SV) और पासकीज़ को बलपूर्वक सक्षम करते हैं, हमलावरों ने क्रेडेंशियल फ़िशिंग (जिसे 2SV / पासकीज़ रोकता है) से कुकी चोरी (जिसे 2SV / पासकीज़ अक्सर नहीं रोकता है) में रणनीति बदल दी है।

ऐतिहासिक रूप से, जोखिम इंजन ने User-Agent स्ट्रिंग, स्क्रीन रिज़ॉल्यूशन, स्थापित फ़ॉन्ट और IP पते को देखकर, डिवाइस फ़िंगरप्रिंट का विश्लेषण करके सेशन चोरी का पता लगाने की कोशिश की है। यदि कोई सेशन कुकी अचानक थोड़े भिन्न कैनवास फ़िंगरप्रिंट के साथ एक नए IP से दिखाई देती है, तो सर्वर इसे अमान्य कर सकता है। समस्या: ब्राउज़रों में गोपनीयता पहल (जैसे Safari की Intelligent Tracking Prevention और Chrome का Privacy Sandbox) विज्ञापन-ट्रैकिंग को रोकने के लिए सक्रिय रूप से इन फ़िंगरप्रिंट की एन्ट्रॉपी को कम कर रही हैं। यह सुरक्षा के लिए "अच्छी" फ़िंगरप्रिंटिंग को तेजी से कठिन बना देता है। इसके अलावा, हमलावर अब "एंटी-डिटेक्ट ब्राउज़र" का उपयोग करते हैं जो उन्हें पीड़ित की प्रोफ़ाइल से पूरी तरह मेल खाने के लिए इन फ़िंगरप्रिंट को खराब करने की अनुमति देते हैं, जिससे अनुमानित पहचान अप्रभावी हो जाती है। DBSC इस संभाव्य अनुमान लगाने के खेल को नियतात्मक क्रिप्टोग्राफ़िक प्रमाण के साथ बदल देता है।

डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) क्लाइंट डिवाइस पर की से बाउंड सेशन बनाने के लिए एक मानकीकृत API और प्रोटोकॉल पेश करता है। मानक को "वर्णित खतरे के खिलाफ मज़बूत" की स्टोरेज की आवश्यकता है लेकिन कार्यान्वयन के बारे में अज्ञेयवादी है। उपलब्ध होने पर Chrome विंडोज़ पर TPM का उपयोग करता है। यह अनुभाग W3C वर्किंग ड्राफ्ट और Chrome के दस्तावेज़ीकरण में परिभाषित तंत्र का विवरण देता है।

DBSC जीवनचक्र एक मानक सेशन से बाउंड सेशन में एक सहज संक्रमण की अनुमति देता है, जिससे पश्चगामी संगतता और क्रमिक वृद्धि सुनिश्चित होती है।

sequenceDiagram
    participant उपयोगकर्ता
    participant ब्राउज़र
    participant HSM as HSM (TPM/सिक्योर एन्क्लेव)
    participant सर्वर

    Note over उपयोगकर्ता,सर्वर: चरण 1: प्रमाणीकरण और बाइंडिंग
    उपयोगकर्ता->>ब्राउज़र: क्रेडेंशियल्स/पासकी के साथ लॉगिन करें
    ब्राउज़र->>सर्वर: प्रमाणीकरण अनुरोध
    सर्वर->>ब्राउज़र: सफलता + DBSC रजिस्ट्रेशन हेडर
    ब्राउज़र->>HSM: की पेयर जनरेट करें
    HSM->>ब्राउज़र: पब्लिक/प्राइवेट की (प्राइवेट गैर-निर्यात योग्य)
    ब्राउज़र->>सर्वर: पब्लिक की रजिस्टर करें (JWT हस्ताक्षरित)
    सर्वर->>सर्वर: सेशन को पब्लिक की से बाइंड करें
    सर्वर->>ब्राउज़र: अल्पकालिक कुकी (5 मिनट)

    Note over उपयोगकर्ता,सर्वर: चरण 2: सामान्य उपयोग
    loop 5 मिनट के भीतर हर अनुरोध
        ब्राउज़र->>सर्वर: कुकी के साथ अनुरोध
        सर्वर->>ब्राउज़र: प्रतिक्रिया
    end

    Note over उपयोगकर्ता,सर्वर: चरण 3: रिफ्रेश (समाप्ति के बाद)
    ब्राउज़र->>सर्वर: समाप्त हो चुकी कुकी के साथ अनुरोध
    सर्वर->>ब्राउज़र: 401 + चुनौती नॉनस
    ब्राउज़र->>HSM: चुनौती पर हस्ताक्षर करें
    HSM->>ब्राउज़र: सिग्नेचर
    ब्राउज़र->>सर्वर: सिग्नेचर प्रमाण
    सर्वर->>सर्वर: संग्रहीत पब्लिक की के साथ सत्यापित करें
    सर्वर->>ब्राउज़र: नई अल्पकालिक कुकी
    ब्राउज़र->>सर्वर: मूल अनुरोध का पुनः प्रयास करें
    सर्वर->>ब्राउज़र: सफलता प्रतिक्रिया

मानक विधियों (पासवर्ड, पासकी, आदि) का उपयोग करके उपयोगकर्ता के प्रमाणीकरण के तुरंत बाद बाइंडिंग प्रक्रिया शुरू होती है।

1. सर्वर सिग्नल: सफल लॉगिन पर, सर्वर एक सेशन कुकी (हमेशा की तरह) सेट करता है लेकिन DBSC समर्थन को इंगित करने वाला एक विशिष्ट हेडर जोड़ता है।

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • Secure-Session-Registration हेडर ब्राउज़र को बताता है: "मैं ES256 और RS256 एल्गोरिदम का समर्थन करता हूं। कृपया एंडपॉइंट /auth/dbsc/register पर एक बाउंड सेशन रजिस्टर करें।"

2. की जनरेशन: ब्राउज़र इस हेडर को पार्स करता है। यह डिवाइस पर सुरक्षित रूप से संग्रहीत एक नई असममित की पेयर (जैसे, एलिप्टिक कर्व P-256) उत्पन्न करता है।

   • कार्यान्वयन नोट: उपलब्ध होने पर Chrome विंडोज़ पर TPM का उपयोग करता है; मानक स्टोरेज तंत्र के बारे में अज्ञेयवादी है, केवल यह आवश्यक है कि यह "वर्णित खतरे के खिलाफ मज़बूत" हो।
   • गोपनीयता का दायरा: की को वेब ओरिजिन (जैसे, bank.com) तक स्कोप किया जाता है। ब्राउज़र यह सुनिश्चित करता है कि इस की का उपयोग कभी भी retailer.com के लिए नहीं किया जाता है, जिससे क्रॉस-साइट ट्रैकिंग को रोका जा सके।

3. रजिस्ट्रेशन अनुरोध: ब्राउज़र निर्दिष्ट रजिस्ट्रेशन पथ पर एक अनुरोध भेजता है। इस अनुरोध में JSON वेब टोकन (JWT) के अंदर नव निर्मित पब्लिक की शामिल है, जो प्राइवेट की (सेल्फ-साइंड अटेस्टेशन) द्वारा हस्ताक्षरित है।

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<JWT Header\>.\<JWT Payload containing Public Key\>.\<Signature\>
   

4. सेशन बाइंडिंग: सर्वर यह सुनिश्चित करने के लिए सिग्नेचर को मान्य करता है कि पब्लिक की कार्यात्मक है। इसके बाद यह उपयोगकर्ता के सेशन (session_id=xyz123) को इस विशिष्ट पब्लिक की के साथ जोड़ने के लिए अपने डेटाबेस को अपडेट करता है। इस क्षण से, सेशन "बाउंड" हो जाता है।

सुरक्षा को प्रदर्शन के साथ संतुलित करने के लिए (सुरक्षित की संचालन विलंबता जोड़ सकते हैं), DBSC डुअल-टोकन सिस्टम का उपयोग करता है।

1. जारी करना: सर्वर एक नई, अल्पकालिक कुकी (जैसे, 5 मिनट के लिए वैध) जारी करता है। इसे access_token कहते हैं।
2. उपयोग: ब्राउज़र सभी सामान्य अनुरोधों (छवियां प्राप्त करना, API कॉल, पृष्ठों को नेविगेट करना) के लिए इस access_token का उपयोग करता है। जब तक कुकी वैध है, कोई क्रिप्टोग्राफ़िक संचालन नहीं किया जाता है। यह सुनिश्चित करता है कि ब्राउज़िंग तेज़ बनी रहे।
3. समाप्ति: 5 मिनट के बाद, access_token समाप्त हो जाता है।

यह सुरक्षा तंत्र का दिल है। जब अल्पकालिक कुकी समाप्त हो जाती है, तो किसी भिन्न डिवाइस पर एक हमलावर को बाहर कर दिया जाता है, लेकिन वैध उपयोगकर्ता (बाउंड की तक पहुंच के साथ) जारी रख सकता है।

1. पता लगाना: ब्राउज़र एक अनुरोध का प्रयास करता है। यह नोटिस करता है कि कुकी समाप्त हो गई है (या सर्वर 401 या एक विशिष्ट Secure-Session-Challenge हेडर देता है)।
2. अवरोधन: ब्राउज़र नेटवर्क अनुरोध को रोक देता है। यह उपयोगकर्ता को कोई त्रुटि नहीं दिखाता है।
3. रिफ्रेश अनुरोध: ब्राउज़र स्वचालित रूप से सेशन कॉन्फ़िगरेशन में परिभाषित रिफ्रेश एंडपॉइंट को कॉल करता है।
   • सर्वर एक क्रिप्टोग्राफ़िक चुनौती (एक नॉनस) भेजता है।
   • ब्राउज़र इस चुनौती पर हस्ताक्षर करने के लिए बाउंड की का उपयोग करता है।
   • सिग्नेचर प्राइवेट की के कब्जे को साबित करता है।
4. सबमिशन: ब्राउज़र हस्ताक्षरित चुनौती को वापस सर्वर पर भेजता है।

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

5. सत्यापन: सर्वर सिग्नेचर को सत्यापित करने के लिए संग्रहीत पब्लिक की का उपयोग करता है।
   • यदि मान्य है: सर्वर जानता है कि अनुरोध उसी भौतिक डिवाइस से आ रहा है जिसने सेशन शुरू किया था। यह एक नया अल्पकालिक access_token जारी करता है (जो अगले 5 मिनट के लिए वैध है)।
   • यदि अमान्य है: अनुरोध अस्वीकार कर दिया जाता है। सेशन समाप्त कर दिया जाता है।
6. पुनरारंभ: ब्राउज़र नई कुकी लेता है और मूल रोके गए अनुरोध को पारदर्शी रूप से पुनः प्रयास करता है। उपयोगकर्ता को कोई रुकावट अनुभव नहीं होती है।

graph LR
    subgraph "पीड़ित का डिवाइस"
        A[DBSC के साथ<br/>उपयोगकर्ता सेशन]
        B[HSM/TPM<br/>प्राइवेट की]
        C[कुकी +<br/>सेशन ID]
        A --> B
        A --> C
        B -.->|गैर-निर्यात योग्य| X[प्राइवेट की<br/>निकाल नहीं सकता]
    end

    subgraph "हमले का परिदृश्य"
        D[RedLine स्टीलर<br/>डिवाइस को संक्रमित करता है]
        D --> E[कुकी और<br/>सेशन ID चुराता है]
        E --> F[हमलावर को<br/>निर्यात करता है]
    end

    subgraph "हमलावर का डिवाइस"
        G[चोरी की गई कुकी<br/>इम्पोर्ट करता है]
        H[सेशन का उपयोग<br/>करने का प्रयास करता है]
        I[सर्वर DBSC रिफ्रेश<br/>का अनुरोध करता है]
        J[चुनौती पर हस्ताक्षर<br/>नहीं कर सकता]
        K[सेशन अस्वीकृत]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|चोरी हो गई| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

एक हमलावर पर विचार करें जो उपयोगकर्ता के PC को RedLine स्टीलर से संक्रमित करता है। वे access_token और session_id चुरा लेते हैं। वे इन्हें अपने स्वयं के ब्राउज़र में आयात करते हैं।

• परिदृश्य A (5 मिनट के भीतर): हमलावर को अल्पकालिक टोकन समाप्त होने तक कुछ मिनटों के लिए पहुंच मिल सकती है।
• परिदृश्य B (समाप्ति के बाद): हमलावर का ब्राउज़र (भिन्न डिवाइस पर) टोकन का उपयोग करने का प्रयास करता है। सर्वर इसे अस्वीकार कर देता है और रिफ्रेश की मांग करता है। हमलावर का ब्राउज़र DBSC हेडर देखता है लेकिन रिफ्रेश नहीं कर सकता क्योंकि उसके पास बाउंड प्राइवेट की नहीं है। हमला विफल हो जाता है।

गोपनीयता DBSC का एक केंद्रीय डिज़ाइन लक्ष्य है। W3C विनिर्देश स्पष्ट रूप से वैश्विक पहचानकर्ताओं के उपयोग पर रोक लगाता है जो साइटों के पार उपयोगकर्ताओं को ट्रैक कर सकते हैं।

• प्रति-ओरिजिन की: ब्राउज़र प्रत्येक साइट के लिए एक अद्वितीय की पेयर उत्पन्न करता है। google.com Key A देखता है; amazon.com Key B देखता है। उनके बीच कोई संबंध नहीं है।
• उपयोगकर्ता क्लीयरिंग: यदि उपयोगकर्ता अपनी कुकीज़/साइट डेटा साफ़ करता है, तो ब्राउज़र संबंधित DBSC की भी हटा देता है। यह सुनिश्चित करता है कि DBSC का उपयोग हटाए गए पहचान को पुनर्जीवित करने के लिए "सुपर-कुकी" के रूप में नहीं किया जा सकता है।

DBSC को लागू करने के लिए सर्वर को पब्लिक की के बारे में स्थिति बनाए रखने की आवश्यकता होती है।

• डेटाबेस स्कीमा: सेशन तालिका को user_id और session_expiry के साथ public_key और last_challenge संग्रहीत करने के लिए अपडेट किया जाना चाहिए।
• प्रदर्शन: रिफ्रेश ऑपरेशन में क्रिप्टोग्राफ़िक सत्यापन (जैसे, ECDSA सिग्नेचर को सत्यापित करना) शामिल है। तेज़ होते हुए भी, यह एक साधारण स्ट्रिंग की जाँच करने की तुलना में अधिक CPU-गहन है। हालांकि, क्योंकि रिफ्रेश केवल हर कुछ मिनटों में होता है (हर अनुरोध पर नहीं), इसलिए ओवरहेड नगण्य है।

तकनीकी विशिष्टताओं से परे, DBSC व्यापार रणनीति, उत्पाद रोडमैप और अनुपालन मुद्राओं के लिए महत्वपूर्ण निहितार्थ रखता है।

सुरक्षा पहलों को अक्सर लागत केंद्र या घर्षण जनरेटर के रूप में देखा जाता है। DBSC इस कथा को पलट देता है। निम्नलिखित आरेख स्पष्ट करता है कि डिवाइस-बाइंडिंग व्यावसायिक लाभों का एक झरना कैसे बनाता है:

• धोखाधड़ी में कमी: अकाउंट टेकओवर (ATO) के प्राथमिक वेक्टर को बेअसर करके, व्यवसाय धोखाधड़ी के नुकसान में लाखों बचा सकते हैं।
• सपोर्ट लागत: अकाउंट रिकवरी महंगी है। पहली जगह में हैक को रोकना सीधे इस परिचालन बोझ को कम करता है।
• रूपांतरण अनुकूलन: ई-कॉमर्स में, हर लॉगिन प्रॉम्प्ट एक संभावित ड्रॉप-ऑफ़ पॉइंट है। DBSC आक्रामक "मुझे लॉग इन रखें" नीतियों की अनुमति देता है, जिससे पासवर्ड प्रॉम्प्ट के बिना त्वरित चेकआउट सक्षम होता है।

यूरोप में GDPR (जनरल डेटा प्रोटेक्शन रेगुलेशन) जैसे विनियामक ढांचे सुरक्षा सुनिश्चित करने के लिए संगठनों को "उचित तकनीकी और संगठनात्मक उपायों" को लागू करने की आवश्यकता रखते हैं।

• बचाव योग्य सुरक्षा: जैसे-जैसे DBSC एक मानक बन जाता है, इसे संभवतः सेशन प्रबंधन के लिए "स्टेट ऑफ द आर्ट" के रूप में व्याख्यायित किया जाएगा। उल्लंघन की स्थिति में, यह प्रदर्शित करना कि DBSC लागू किया गया था, लापरवाही के दावों के खिलाफ एक मज़बूत बचाव हो सकता है।
• बैंकिंग मानक (PSD2): पेमेंट सर्विसेज डायरेक्टिव 2 के लिए "स्ट्रॉन्ग कस्टमर ऑथेंटिकेशन" (SCA) की आवश्यकता होती है। जबकि SCA लॉगिन पर केंद्रित है, डिवाइस के साथ सेशन की गतिशील लिंकिंग प्रमाणीकरण को विशिष्ट राशियों और भुगतानकर्ताओं से बाइंड करने के निर्देश के लक्ष्यों के साथ पूरी तरह से मेल खाती है।

FIDO एलायंस श्वेतपत्र "आश्वासन स्तर" की अवधारणा पर प्रकाश डालते हैं।

• मध्यम आश्वासन: सिंक किए गए पासकीज़ (जैसे iCloud Keychain में) का उपयोग करता है। उपभोक्ता ऐप्स के लिए बढ़िया, पुनर्प्राप्त करने योग्य, उपयोग करने में आसान।
• उच्च आश्वासन: डिवाइस-बाउंड की की आवश्यकता होती है। यह वह जगह है जहां DBSC चमकता है। एंटरप्राइज़ संसाधनों (HR पोर्टल, कोड रिपॉजिटरी) या उच्च-मूल्य वाले बैंकिंग के लिए, संगठन एक नीति लागू कर सकता है जो केवल एक विशिष्ट प्रबंधित डिवाइस से बाउंड सेशन से पहुंच की अनुमति देती है। DBSC इस नीति के लिए तकनीकी प्रवर्तन तंत्र प्रदान करता है।

DBSC की पूरी तरह से सराहना करने के लिए, हमें इसकी तुलना उन अन्य तकनीकों से करनी चाहिए जिन्होंने समान समस्याओं को हल करने का प्रयास किया है।

graph RL
    subgraph "पारंपरिक कुकीज़"
        TC1[केवल बियरर टोकन]
        TC2[चोरी के प्रति संवेदनशील]
        TC3[लंबे सेशन = जोखिम]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "टोकन बाइंडिंग"
        TB1[TLS लेयर बाइंडिंग]
        TB2[❌ विफल: जटिल इन्फ्रास्ट्रक्चर]
        TB3[लोड बैलेंसर्स पर टूट गया]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[OAuth टोकन बाइंडिंग]
        DP2[✅ API सुरक्षा]
        DP3[ब्राउज़र सेशन के लिए नहीं]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[HTTP लेयर बाइंडिंग]
        D2[✅ हार्डवेयर की सुरक्षा]
        D3[✅ CDNs/LBs के साथ काम करता है]
        D4[✅ ब्राउज़र सेशन]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

जैसा कि उल्लेख किया गया है, टोकन बाइंडिंग ने सेशन को TLS लेयर से बाइंड करने का प्रयास किया।

• टोकन बाइंडिंग: क्लाइंट, सर्वर, और बीच के हर हॉप (लोड बैलेंसर, TLS टर्मिनेटर) से समर्थन की आवश्यकता थी। जब कोई कनेक्शन समाप्त और पुनः एन्क्रिप्ट किया जाता था तो यह टूट जाता था।
• DBSC: HTTP एप्लिकेशन लेयर पर काम करता है। यह मानक हेडर/कुकीज़ के रूप में लोड बैलेंसर के माध्यम से पारदर्शी रूप से गुजरता है। आधुनिक क्लाउड आर्किटेक्चर (AWS/GCP/Azure) में तैनात करना बहुत आसान है जहां TLS अक्सर क्लाउड प्रदाता के एज नेटवर्क द्वारा नियंत्रित किया जाता है।

DPoP (RFC 9449) "सेंडर-कन्स्ट्रेंड" OAuth टोकन के लिए मानक है। यह एक्सेस टोकन और रिफ्रेश टोकन दोनों को एक पब्लिक की से बाइंड करता है - महत्वपूर्ण है क्योंकि रिफ्रेश टोकन स्वयं लंबे समय तक चलने वाले बियरर क्रेडेंशियल्स हैं। प्रत्येक API अनुरोध में एक DPoP प्रमाण शामिल होता है: HTTP विधि, URL, टाइमस्टैम्प और अद्वितीय पहचानकर्ता के साथ एक हस्ताक्षरित JWT। उच्च-आश्वासन विनिर्देश जैसे FAPI 2.0 सेंडर-कन्स्ट्रेंड टोकन अनिवार्य करते हैं; जब mTLS अनुपलब्ध हो तो DPoP अनुशंसित विधि है।

मुख्य अंतर: DPoP की एप्लिकेशन संदर्भ में रहती हैं। सर्वोत्तम अभ्यास गैर-निष्कर्षण योग्य भंडारण के लिए OS APIs का उपयोग करना है, लेकिन यह लागू नहीं किया गया है - कई कार्यान्वयन JavaScript-सुलभ मेमोरी में की रखते हैं। यदि कोई हमलावर मनमाना कोड (XSS, मैलवेयर) निष्पादित कर सकता है, तो वे DPoP की तक पहुंच सकते हैं या मांग पर प्रमाण उत्पन्न कर सकते हैं। DPoP विभिन्न क्लाइंट के बीच टोकन रीप्ले को रोकता है, लेकिन समझौता किए गए ब्राउज़र संदर्भ की रक्षा नहीं कर सकता है।

DBSC प्रूफ-ऑफ-पजेशन को ब्राउज़र और हार्डवेयर में ले जाता है। प्राइवेट की एक TPM या सुरक्षित एन्क्लेव में रहती है जिसे JavaScript पढ़ या निर्यात नहीं कर सकता है। ब्राउज़र एप्लिकेशन कोड के लिए की को उजागर किए बिना प्रोटोकॉल को संभालता है और सिग्नेचर उत्पन्न करता है। यहां तक ​​कि अगर वेब ऐप पूरी तरह से समझौता कर लेता है, तो भी कोई हमलावर किसी अन्य मशीन पर चोरी की गई कुकीज़ के लिए नए प्रमाण नहीं बना सकता है।

तालमेल: जैसा कि FIDO एलायंस नोट करता है, पासकीज़ लॉगिन पर फ़िशिंग को खत्म कर देती हैं, जबकि DBSC/DPoP पोस्ट-प्रमाणीकरण टोकन की रक्षा करते हैं। एक आधुनिक वास्तुकला दोनों को जोड़ती है: OAuth APIs के लिए DPoP (विशेष रूप से विनियमित ओपन बैंकिंग), ब्राउज़र सेशन के लिए DBSC। साथ में वे पूरे सेशन जीवनचक्र में "लिफ्ट और शिफ्ट" हमले के वेक्टर को बंद कर देते हैं।

कुकी के जीवनकाल को कम करना (जैसे, 15 मिनट तक) सुरक्षा में सुधार करता है लेकिन UX को नष्ट कर देता है। उपयोगकर्ताओं को लगातार लॉग इन करने के लिए मजबूर किया जाता है। DBSC 30-दिन की कुकी के उपयोगकर्ता अनुभव के साथ 5-मिनट की कुकी की प्रभावी सुरक्षा की अनुमति देता है।

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as सुरक्षा उपकरण<br/>(CrowdStrike, Defender)
    participant IdP as आइडेंटिटी प्रोवाइडर<br/>(Okta, Google, Azure)
    participant SP1 as सर्विस प्रोवाइडर 1<br/>(Slack)
    participant SP2 as सर्विस प्रोवाइडर 2<br/>(Salesforce)
    participant SP3 as सर्विस प्रोवाइडर 3<br/>(बैंकिंग ऐप)
    participant Session as उपयोगकर्ता सेशन<br/>(DBSC संरक्षित)

    Note over ST,Session: खतरा पहचान चरण
    ST->>ST: उपयोगकर्ता के डिवाइस पर<br/>मैलवेयर का पता लगाता है
    ST->>IdP: RISC सिग्नल:<br/>"डिवाइस समझौता हुआ"

    Note over IdP,SP3: सिग्नल प्रसार चरण
    IdP->>SP1: CAEP इवेंट:<br/>"डिवाइस समझौता हुआ"
    IdP->>SP2: CAEP इवेंट:<br/>"डिवाइस समझौता हुआ"
    IdP->>SP3: CAEP इवेंट:<br/>"डिवाइस समझौता हुआ"

    Note over SP1,Session: प्रवर्तन चरण (DBSC के साथ)
    Session->>SP1: अगला रिफ्रेश प्रयास<br/>(मिनटों के भीतर)
    SP1-->>Session: x सिग्नेचर अस्वीकार करें
    Session->>SP2: अगला रिफ्रेश प्रयास
    SP2-->>Session: x सिग्नेचर अस्वीकार करें
    Session->>SP3: अगला रिफ्रेश प्रयास
    SP3-->>Session: x सिग्नेचर अस्वीकार करें

    Note over Session: अगले रिफ्रेश प्रयास पर सेशन समाप्त किए जा सकते हैं

DBSC की क्षमता तब बढ़ जाती है जब इसे शेयर्ड सिग्नल्स फ्रेमवर्क (SSF), विशेष रूप से Continuous Access Evaluation Profile (CAEP) और Risk Management (RISC) के साथ जोड़ा जाता है। नोट: SSF/CAEP एक उभरती हुई पारिस्थितिकी तंत्र क्षमता है - वास्तुकला पैटर्न परिभाषित है, लेकिन व्यापक क्रॉस-वेंडर डिप्लॉयमेंट अभी भी परिपक्व हो रहा है।

पुराने मॉडल में, यदि उपयोगकर्ता के डिवाइस से समझौता किया गया था, तो आइडेंटिटी प्रोवाइडर (IdP) के पास सर्विस प्रोवाइडर (SP) को अभी सेशन समाप्त करने के लिए कहने का कोई तरीका नहीं था। SP को कुकी के समाप्त होने की प्रतीक्षा करनी होगी।

परिकल्पित DBSC + CAEP प्रवाह:

1. ट्रिगर: एक एंडपॉइंट सुरक्षा उपकरण (जैसे CrowdStrike या Microsoft Defender) उपयोगकर्ता के लैपटॉप पर मैलवेयर का पता लगाता है।
2. सिग्नल: सुरक्षा उपकरण आइडेंटिटी प्रोवाइडर (जैसे, Okta/Google) को एक RISC सिग्नल भेजता है।
3. प्रसार: IdP कनेक्टेड ऐप्स पर एक CAEP इवेंट पुश करता है: "डिवाइस समझौता हुआ।"
4. प्रवर्तन (DBSC): अगली बार जब ब्राउज़र DBSC अल्पकालिक कुकी को रिफ्रेश करने का प्रयास करता है, तो सर्वर सिग्नेचर को अस्वीकार कर देता है और सेशन को समाप्त कर देता है।
   यह वास्तुकला पैटर्न तेज़ रद्दीकरण को सक्षम करता है - वास्तविक विलंबता साइट की रिफ्रेश अवधि और इस बात पर निर्भर करती है कि उन्होंने DBSC और SSF दोनों को लागू किया है या नहीं।

DBSC को अपनाना ब्राउज़र विक्रेताओं पर निर्भर करता है। 2026 में परिदृश्य भौतिक रूप से बदल गया है: Chrome ने अप्रैल 2026 में विंडोज़ पर DBSC को ओरिजिन ट्रायल से सामान्य उपलब्धता में स्थानांतरित कर दिया, इसके बाद macOS आएगा। अन्य ब्राउज़र अभी भी मूल्यांकन कर रहे हैं।

Google DBSC का प्राथमिक ड्राइवर है और इसे व्यापक रूप से शिप करने वाला पहला ब्राउज़र है।

• स्थिति (अप्रैल 2026): Chrome 146 विंडोज़ पर DBSC को सामान्य उपलब्धता में शिप करता है, जिससे ओरिजिन ट्रायल चरण समाप्त हो जाता है। सिक्योर एन्क्लेव का उपयोग करके macOS सपोर्ट, आगामी Chrome रिलीज़ के लिए घोषित किया गया है।
• हार्डवेयर: विंडोज़ TPM का उपयोग करता है, macOS सिक्योर एन्क्लेव का उपयोग करेगा। Google ने कहा है कि वह सुरक्षित हार्डवेयर के बिना डिवाइस तक DBSC सुरक्षा का विस्तार करने के लिए सॉफ़्टवेयर-आधारित की की भी खोज कर रहा है।
• रोडमैप: Google की GA घोषणा ने अगला-कदम रोडमैप भी प्रकाशित किया:
  • फेडेरेटेड आइडेंटिटी को सुरक्षित करना: क्रॉस-ओरिजिन DBSC बाइंडिंग ताकि रिलायिंग-पार्टी (RP) सेशन आइडेंटिटी-प्रोवाइडर (IdP) सेशन के समान डिवाइस की से बाउंड रहे, जिससे SSO के माध्यम से विश्वास की एक अटूट श्रृंखला सुरक्षित रहे।
  • एडवांस रजिस्ट्रेशन: साइन-इन पर एक नई की जनरेट करने के बजाय, DBSC सेशन को पहले से मौजूद विश्वसनीय की सामग्री जैसे mTLS सर्टिफिकेट या हार्डवेयर सुरक्षा की से बाइंड करना।
  • व्यापक डिवाइस सपोर्ट: TPM / सिक्योर एन्क्लेव के बिना डिवाइस के लिए सॉफ़्टवेयर-आधारित की।
• परिचालन परिणाम: रोलआउट के दौरान Google ने DBSC द्वारा संरक्षित सेशन के लिए "सेशन चोरी में महत्वपूर्ण कमी" की रिपोर्ट दी।
• Google खाते: अलग से, Google पहले ही Chrome for Windows पर Google खाता कुकीज़ के लिए DBSC-शैली सुरक्षा रोल आउट कर चुका था, जिसे एंटरप्राइज़ नीति के माध्यम से नियंत्रित किया जाता है। यह Gmail/Workspace की रक्षा करता है और अब वही प्रौद्योगिकी परिवार है जो सामान्य वेब के लिए GA है।

Microsoft सक्रिय रूप से भाग ले रहा है।

• स्थिति: Edge ने विंडोज़ पर एक DBSC ओरिजिन ट्रायल चलाया जो अक्टूबर 2025 में समाप्त हुआ। किसी प्रतिस्थापन ट्रायल या GA की घोषणा नहीं की गई है।
• एंटरप्राइज़ संदर्भ: Edge Entra/Azure AD SSO के लिए "Primary Refresh Token" (PRT) आर्किटेक्चर का उपयोग करता है, जो वैचारिक रूप से DBSC के समान है। PRT एक Microsoft-विशिष्ट तंत्र बना हुआ है; तृतीय-पक्ष साइटों के लिए इसे DBSC वेब मानक के साथ एकीकृत करने की कोई घोषित योजना नहीं है।

मोबाइल कवरेज के लिए Apple का रुख महत्वपूर्ण है।

• स्थिति: WebKit में ज्ञात उपयोगिता/गोपनीयता चिंताओं के साथ DBSC का मूल्यांकन करने वाला एक standards-position issue है। Safari रिलीज़ नोट्स में DBSC का उल्लेख नहीं है। कोई सार्वजनिक "सक्रिय रूप से लागू करने" वाला बयान मौजूद नहीं है।
• गोपनीयता पहले: Apple की मुख्य चिंता यह है कि DBSC का उपयोग "सुपर-कुकीज़" (अमिट ट्रैकिंग) के लिए किया जा सकता है। W3C विनिर्देश यह सुनिश्चित करके इसे संबोधित करता है कि वेबसाइट डेटा के साथ की को साफ़ किया जाता है।
• जुड़ाव: WebKit मानक प्रक्रिया के साथ जुड़ रहा है, लेकिन कार्यान्वयन की स्थिति अस्पष्ट है - "विकास के अधीन" के बजाय "चर्चा के अधीन"।

Mozilla में जटिलता और गोपनीयता के बारे में ज्ञात चिंताओं के साथ DBSC का मूल्यांकन करने वाला एक standards-position issue है। मानक स्थिर होने के बाद लागू करने की कोई सार्वजनिक प्रतिबद्धता नहीं है।

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

1. पहले पासकीज़ तैनात करें: प्रमाणीकरण लेयर को सुरक्षित करने के लिए पासकी कार्यान्वयन से शुरुआत करें। यह क्रेडेंशियल फ़िशिंग के खिलाफ तत्काल सुरक्षा प्रदान करता है और DBSC से वास्तविक मूल्य प्राप्त करने के लिए पूर्व शर्त है।

2. DBSC रजिस्ट्रेशन और रिफ्रेश एंडपॉइंट शिप करें: Chrome 146 GA के साथ, यथार्थवादी काम अब बैकएंड इंटीग्रेशन है: लॉगिन प्रतिक्रियाओं पर Secure-Session-Registration हेडर जोड़ें और हस्ताक्षरित चुनौतियों को सत्यापित करने वाले रिफ्रेश एंडपॉइंट के साथ /dbsc/register लागू करें। फ्रंट-एंड कोड को बदलने की आवश्यकता नहीं है।

3. रिफ्रेश टोकन के साथ अल्पकालिक सेशन लागू करें: यदि आप अभी तक DBSC के लिए तैयार नहीं हैं, तो रिफ्रेश तंत्र के साथ अल्पकालिक टोकन के वास्तुशिल्प पैटर्न को अपनाएं। यह आपके बैकएंड को DBSC के लिए तैयार करता है और साथ ही आज सुरक्षा में सुधार करता है।

1. हाइब्रिड दृष्टिकोण अपनाएं: फ़ॉलबैक विकल्पों को बनाए रखते हुए सक्षम ब्राउज़रों (वर्तमान में विंडोज़ पर Chrome 146+, इसके बाद macOS सिक्योर एन्क्लेव) को DBSC प्रदान करने के लिए फीचर डिटेक्शन का उपयोग करें। यह Safari, Firefox या Edge के उपयोगकर्ताओं को बाहर किए बिना सुरक्षा को अधिकतम करता है।

2. अगले रोडमैप आइटम की तैयारी करें: Google ने स्पष्ट रूप से फेडेरेटेड आइडेंटिटी (क्रॉस-ओरिजिन SSO बाइंडिंग), एडवांस रजिस्ट्रेशन (mTLS / हार्डवेयर की) और व्यापक डिवाइस कवरेज के लिए सॉफ़्टवेयर-आधारित की का आह्वान किया है। यदि आप SSO या IdP लेयर संचालित करते हैं, तो अभी क्रॉस-ओरिजिन बाइंडिंग को स्कोप करना शुरू करें।

3. आइडेंटिटी प्रोवाइडर के साथ एकीकृत करें: यदि Okta, Auth0, या समान IdPs का उपयोग कर रहे हैं, तो उनके SDKs में DBSC समर्थन को सक्षम करने के लिए उनके साथ काम करें। कई लोगों ने ओरिजिन ट्रायल में भाग लिया और Chrome के GA होने के बाद अब सक्रिय रूप से DBSC क्षमताओं को शिप कर रहे हैं।

• उच्च-मूल्य वाले लक्ष्यों के साथ प्रारंभ करें: व्यवस्थापक पैनल, वित्तीय लेन-देन और संवेदनशील डेटा एक्सेस के लिए DBSC को प्राथमिकता दें।
• प्रबंधित समाधानों का उपयोग करें: Corbado जैसे प्लेटफ़ॉर्म पर विचार करें जो DBSC कार्यान्वयन और ब्राउज़र संगतता की जटिलता को संभालते हैं।
• मापें और पुनरावृति करें: ROI प्रदर्शित करने के लिए सेशन हाइजैकिंग प्रयास, सपोर्ट टिकट और उपयोगकर्ता घर्षण जैसे मीट्रिक को ट्रैक करें।
• अनुपालन के लिए तैयारी करें: अपने DBSC कार्यान्वयन का दस्तावेजीकरण करें क्योंकि यह संभवतः संवेदनशील डेटा को संभालने के लिए अनुपालन आवश्यकता बन जाएगा।

स्क्रैच से DBSC को लागू करना एक भारी इंजीनियरिंग लिफ्ट है। इसके लिए क्रिप्टोग्राफ़िक विशेषज्ञता, ब्राउज़र विसंगतियों के गहन ज्ञान और कीज़ और चुनौतियों के प्रबंधन के लिए एक मज़बूत सर्वर-साइड बुनियादी ढांचे की आवश्यकता होती है। यहीं Corbado एक सक्षमकर्ता के रूप में कार्य करता है।

आप कम-आश्वासन वाले लॉगिन के ऊपर उच्च-आश्वासन वाला सेशन नहीं बना सकते। यदि कोई उपयोगकर्ता कमज़ोर पासवर्ड के साथ लॉग इन करता है, तो सेशन केवल उस पासवर्ड जितना ही सुरक्षित होता है। Corbado का मुख्य उत्पाद (प्रबंधित पासकीज़) आवश्यक आधार प्रदान करता है। Corbado को एकीकृत करके, संगठन आसानी से पासकीज़ को तैनात कर सकते हैं, यह सुनिश्चित करते हुए कि सेशन की शुरुआत फ़िशिंग-प्रतिरोधी है।

Corbado विश्वसनीय डिवाइस पहचान को बढ़ाने के लिए DBSC का लाभ उठाएगा। जब DBSC सिग्नल उपलब्ध होते हैं, तो वे क्रिप्टोग्राफ़िक प्रमाण प्रदान करते हैं कि एक सेशन एक विशिष्ट डिवाइस से उत्पन्न होता है जिससे Corbado तदनुसार प्रमाणीकरण विश्वास स्तर को बढ़ा सकता है।

• सिंक की गई पासकी अस्पष्टता को हल करना: सिंक की गई पासकीज़ सुविधाजनक हैं लेकिन एक विश्वास अंतर पैदा करती हैं: जब कोई उपयोगकर्ता सिंक की गई पासकी से प्रमाणित होता है, तो आप यह नहीं बता सकते कि यह उनका सामान्य लैपटॉप है या कोई बिल्कुल नया डिवाइस जिसने अभी क्रेडेंशियल को सिंक किया है। DBSC इस अंतर को बंद कर देता है। यह जांच कर कि क्या डिवाइस में स्थापित DBSC बाइंडिंग है, Corbado सत्यापित कर सकता है कि डिवाइस वास्तव में ज्ञात और विश्वसनीय है, न कि केवल पहली बार सिंक किया गया है।
• ज्ञात डिवाइस के लिए उच्च विश्वास: जब DBSC सिग्नल पुष्टि करते हैं कि एक डिवाइस को पहले देखा गया है, तो Corbado अधिक आत्मविश्वास से जोखिम निर्णय ले सकता है: वैध लौटने वाले उपयोगकर्ताओं के लिए कम स्टेप-अप प्रमाणीकरण प्रॉम्प्ट, अज्ञात डिवाइस से सेशन के लिए सख्त जांच।
• पासकी इंटेलिजेंस का पूरक: DBSC सिग्नल Corbado के मौजूदा पासकी इंटेलिजेंस इंजन के साथ एकीकृत होते हैं। पासकी-आधारित प्रमाणीकरण और DBSC-आधारित डिवाइस बाइंडिंग का संयोजन लॉगिन से लेकर पूरे सेशन जीवनचक्र तक एक पूर्ण विश्वास श्रृंखला बनाता है।

इस बारे में सवालों के लिए कि Corbado अपने प्लेटफ़ॉर्म में DBSC को कैसे एकीकृत करने की योजना बना रहा है, टीम से संपर्क करें।

अगले कुछ वर्षों तक, वेब हाइब्रिड रहेगा। कुछ उपयोगकर्ताओं के पास DBSC-सक्षम ब्राउज़र (Windows 11 पर Chrome) होंगे; अन्य पुराने सिस्टम पर होंगे। इस विखंडन को संभालना मुश्किल है। Corbado का पासकी इंटेलिजेंस इंजन सक्षम डिवाइसों को पासकीज़ प्रदान करने और दूसरों के लिए फ़ॉलबैक करने वाले इस प्रकार के फ़ॉलबैक लॉजिक को संभालने के लिए डिज़ाइन किया गया है। यही इंटेलिजेंस सेशन बाइंडिंग पर लागू होता है, यह सुनिश्चित करते हुए कि प्रत्येक उपयोगकर्ता के लिए उनके डिवाइस की क्षमताओं के अनुसार सुरक्षा अधिकतम हो।

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

डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) उद्योग के उभरते उत्तर का प्रतिनिधित्व करता है। उनके HttpOnly फ़्लैग और स्थिर रहस्यों के साथ पारंपरिक सुरक्षित कुकीज़ के विपरीत, DBSC डिवाइस-बाउंड की के माध्यम से कब्जे का क्रिप्टोग्राफ़िक प्रमाण जोड़ता है। यह चोरी की कुकीज़ को बहुत कम मूल्यवान बनाता है। उन्हें किसी अन्य डिवाइस से रिफ्रेश नहीं किया जा सकता है। जहां टोकन बाइंडिंग सभी बुनियादी ढांचे में जटिल TLS-लेयर परिवर्तनों की आवश्यकता द्वारा विफल रहा, वहीं DBSC HTTP एप्लिकेशन लेयर पर काम करके सफल होता है, मौजूदा लोड बैलेंसर और CDN आर्किटेक्चर के साथ संगत है। नोट: DBSC ने फ़ॉलबैक पथ का दस्तावेजीकरण किया है जहां ब्राउज़र बाइंडिंग को छोड़ देता है (TPM अनुपलब्ध, नेटवर्क त्रुटियां), इसलिए यह बहुत कम कर देता है लेकिन कुकी चोरी के जोखिम को समाप्त नहीं करता है।

DBSC और पासकीज़ के बीच तालमेल उपयोगकर्ता यात्रा में हमलावरों के लिए काफी बार बढ़ाता है। पासकीज़ लॉगिन पर क्रेडेंशियल फ़िशिंग को खत्म कर देती हैं, जबकि DBSC रिमोट कुकी चोरी के माध्यम से सेशन हाइजैकिंग को बहुत कठिन बना देता है - एक साथ मिलकर वह "उच्च आश्वासन" पहचान ढांचा बनाता है जिसकी FIDO एलायंस कल्पना करता है। Chrome 146 द्वारा अप्रैल 2026 में विंडोज़ पर DBSC को GA में शिप करने और macOS सिक्योर एन्क्लेव सपोर्ट के आगे आने के साथ, मानक तैयारी चरण से रोलआउट चरण में चला गया है। Google का प्रकाशित रोडमैप (फेडेरेटेड आइडेंटिटी, mTLS / हार्डवेयर की रजिस्ट्रेशन, सॉफ़्टवेयर-आधारित की) विस्तार के अगले 12 महीनों का संकेत देता है।

उत्पाद प्रबंधकों के लिए, व्यावसायिक मामला सम्मोहक है: DBSC "अनंत" सुरक्षित सेशन को सक्षम करता है जो धोखाधड़ी के नुकसान और समर्थन लागत में कटौती करते हुए लॉगिन घर्षण को नाटकीय रूप से कम करता है। ROI उच्च रूपांतरण दरों, कम पासवर्ड रीसेट टिकटों और समाप्त हुई अकाउंट टेकओवर घटनाओं में प्रकट होता है। OAuth का उपयोग करने वाले संगठन API टोकन के लिए DPoP के माध्यम से समान की-बाइंडिंग अवधारणा का लाभ उठा सकते हैं, जबकि शेयर्ड सिग्नल्स (CAEP/RISC) के साथ एकीकरण वास्तविक समय की खतरे की प्रतिक्रिया को सक्षम करता है - अगले रिफ्रेश प्रयास पर समझौता किए गए सेशन को तुरंत रद्द करना।

कार्यान्वयन के लिए खरोंच से निर्माण की आवश्यकता नहीं है। Corbado जैसे प्लेटफ़ॉर्म पासकी बुनियादी ढांचा प्रदान करते हैं और ब्राउज़र समर्थन परिपक्व होने पर डिवाइस-बाइंडिंग को एकीकृत करने के लिए DBSC विकास को ट्रैक कर रहे हैं। W3C विनिर्देश एक सक्रिय वर्किंग ड्राफ्ट है, Chrome 146 विंडोज़ पर GA है और macOS पर रोल आउट हो रहा है, और अन्य ब्राउज़र अभी भी मानक का मूल्यांकन कर रहे हैं।

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

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

जब क्राउडस्ट्राइक (CrowdStrike) जैसे एंडपॉइंट सुरक्षा टूल मैलवेयर का पता लगाते हैं, तो वे आइडेंटिटी प्रोवाइडर को एक RISC सिग्नल भेजते हैं, जो कनेक्टेड ऐप्स को एक CAEP 'Device Compromised' इवेंट भेजता है। अगले DBSC रिफ्रेश प्रयास (मिनटों के भीतर) पर, वे ऐप सेशन सिग्नेचर को अस्वीकार कर देते हैं और एक्सेस समाप्त कर देते हैं। क्रॉस-वेंडर CAEP/RISC डिप्लॉयमेंट अभी भी परिपक्व हो रहा है।

DPoP (RFC 9449) OAuth एक्सेस और रिफ्रेश टोकन को एप्लिकेशन लेयर पर एक पब्लिक की से बाइंड करता है, जो मुख्य रूप से नेटिव ऐप और SPAs में API कॉल की सुरक्षा करता है। DBSC ब्राउज़र सेशन कुकीज़ को हार्डवेयर-समर्थित TPM की से बाइंड करता है जिसे JavaScript पढ़ या निर्यात नहीं कर सकता है, जिससे XSS या मैलवेयर द्वारा वेब ऐप के ही समझौता होने पर भी उपयोगकर्ता के सामने वाले सेशन सुरक्षित रहते हैं।

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

DBSC अकाउंट टेकओवर के प्राथमिक तरीके के रूप में कुकी चोरी को बेअसर करता है, जिससे धोखाधड़ी के नुकसान और अकाउंट रिकवरी सपोर्ट लागत में सीधे कमी आती है। सुरक्षित लंबे सेशन बार-बार लॉगिन प्रॉम्प्ट को समाप्त करते हैं, ई-कॉमर्स में रूपांतरण दर में सुधार करते हैं और ड्रॉप-ऑफ़ को कम करते हैं। FIDO एलायंस DBSC को उपयोगकर्ता घर्षण को कम करते हुए सुरक्षा स्तर बढ़ाने वाले के रूप में प्रस्तुत करता है।