---
url: 'https://www.corbado.com/hi/blog/device-bound-session-credentials-dbsc'
title: 'डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) की व्याख्या'
description: 'जानें कि डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) सेशन हाइजैकिंग और कुकी चोरी को कैसे रोकते हैं। ब्राउज़र सपोर्ट की स्थिति और एंटरप्राइज़ सुरक्षा के बारे में जानें।'
lang: 'hi'
author: 'Vincent Delitz'
date: '2026-06-15T13:58:02.964Z'
lastModified: '2026-06-16T06:07:43.706Z'
keywords: 'डिवाइस बाउंड सेशन क्रेडेंशियल्स, DBSC, सेशन हाइजैकिंग की रोकथाम, कुकी चोरी से सुरक्षा, TPM सेशन बाइंडिंग'
category: 'Authentication'
---

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

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

> **नवीनतम (अप्रैल 2026):** Chrome 146
> [विंडोज़ पर DBSC को सामान्य उपलब्धता में शिप करता है](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/),
> जो फीचर को ओरिजिन ट्रायल से बाहर ले जाता है। macOS सपोर्ट (सिक्योर एन्क्लेव का उपयोग
> करके) आगामी Chrome रिलीज़ में आ रहा है। Google ने फेडेरेटेड आइडेंटिटी (क्रॉस-ओरिजिन
> [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) बाइंडिंग), एडवांस रजिस्ट्रेशन (mTLS / हार्डवेयर
> की) और सुरक्षित हार्डवेयर के बिना डिवाइस के लिए सॉफ़्टवेयर-आधारित की के लिए सार्वजनिक
> रोडमैप की भी घोषणा की।

| ब्राउज़र    | विंडोज़                 | macOS                        | लिनक्स               | एंड्रॉइड             | iOS                    | स्थिति                                                                                                                                        |
| ----------- | ----------------------- | ---------------------------- | -------------------- | -------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Chrome**  | ✅ GA (Chrome 146, TPM) | 🚧 आ रहा है (Secure Enclave) | ❌                   | ❌                   | ❌                     | [विंडोज़ पर GA](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (अप्रैल 2026), आगामी रिलीज़ में macOS |
| **Edge**    | ⏸️ ट्रायल समाप्त        | ❌                           | ❌                   | ❌                   | ❌                     | ओरिजिन ट्रायल अक्टूबर 2025 में समाप्त, कोई GA घोषित नहीं                                                                                      |
| **Safari**  | लागू नहीं               | 🔄 मूल्यांकन कर रहा है       | लागू नहीं            | लागू नहीं            | 🔄 मूल्यांकन कर रहा है | WebKit चर्चा कर रहा है, कोई कार्यान्वयन घोषित नहीं                                                                                            |
| **Firefox** | 🔄 निगरानी कर रहा है    | 🔄 निगरानी कर रहा है         | 🔄 निगरानी कर रहा है | 🔄 निगरानी कर रहा है | 🔄 निगरानी कर रहा है   | मूल्यांकन कर रहा है, लागू करने की कोई प्रतिबद्धता नहीं                                                                                        |

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

**नोट:** Chrome 146 (अप्रैल 2026) तक विंडोज़ पर TPM के साथ
[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) GA है। सिक्योर एन्क्लेव के माध्यम से
macOS सपोर्ट इसके बाद रोल आउट हो रहा है। Google के बताए गए रोडमैप में सुरक्षित हार्डवेयर
के बिना डिवाइस तक सुरक्षा का विस्तार करने के लिए सॉफ़्टवेयर-आधारित की भी शामिल हैं।

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

| **सुविधा**           | **वर्तमान कुकी मॉडल**            | **DBSC मॉडल**                             |
| -------------------- | -------------------------------- | ----------------------------------------- |
| **टोकन प्रकार**      | बियरर (कब्जा = एक्सेस)           | बाउंड (कब्जा + की = एक्सेस)               |
| **चोरी का परिणाम**   | पूर्ण अकाउंट टेकओवर              | बेकार टोकन (रिफ्रेश नहीं कर सकता)         |
| **सेशन अवधि**        | छोटी (सुरक्षा के लिए)            | लंबी / अनंत (डिज़ाइन द्वारा सुरक्षित)     |
| **उपयोगकर्ता घर्षण** | उच्च (बार-बार लॉगिन)             | निम्न (अदृश्य सुरक्षा)                    |
| **MFA बायपास**       | कमज़ोर (पास-द-कुकी)              | प्रतिरोधी (डिवाइस आवश्यक)                 |
| **रद्दीकरण**         | धीमा (समाप्ति की प्रतीक्षा करें) | लगभग वास्तविक समय (अगले रिफ्रेश में विफल) |

## Key Facts

- **DBSC** वेब सेशन को डिवाइस-हेल्ड क्रिप्टोग्राफ़िक की से बाइंड करता है, जिससे चोरी की गई
  कुकीज़ बेकार हो जाती हैं क्योंकि उन्हें किसी अन्य डिवाइस से रिफ्रेश नहीं किया जा सकता
  है।
- ब्राउज़र **TPM** में एक गैर-निर्यात योग्य प्राइवेट की संग्रहीत करता है, जो बिना
  उपयोगकर्ता इंटरैक्शन के डिवाइस के कब्जे को साबित करने के लिए हर 5 मिनट में सर्वर
  चुनौतियों पर हस्ताक्षर करता है।
- **टोकन बाइंडिंग** के विपरीत, जो TLS-लेयर बुनियादी ढांचे की जटिलता के कारण विफल रहा, DBSC
  HTTP एप्लिकेशन लेयर पर काम करता है और मौजूदा लोड बैलेंसर और CDNs के साथ पारदर्शी रूप से
  काम करता है।
- **Chrome 146 DBSC को विंडोज़ पर GA (अप्रैल 2026) में शिप करता है**, जिसमें macOS सिक्योर
  एन्क्लेव सपोर्ट आगामी रिलीज़ में आ रहा है। Google के प्रकाशित रोडमैप में फेडेरेटेड
  आइडेंटिटी (क्रॉस-ओरिजिन SSO बाइंडिंग), एडवांस रजिस्ट्रेशन (mTLS / हार्डवेयर की) और
  सुरक्षित हार्डवेयर के बिना डिवाइस के लिए सॉफ़्टवेयर-आधारित की भी शामिल हैं। Safari और
  Firefox अभी भी मूल्यांकन कर रहे हैं; Edge का ओरिजिन ट्रायल अक्टूबर 2025 में बिना किसी GA
  की घोषणा के समाप्त हो गया।

## 1. परिचय: डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC)

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

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

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

[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) वेब सेशन को बनाए रखने के तरीके में एक
आदर्श बदलाव का प्रतिनिधित्व करता है। यह सरल बियरर टोकन से ऐसे मॉडल की ओर बढ़ने का प्रस्ताव
करता है जहां सेशन [क्रिप्टोग्राफ़िक रूप से डिवाइस से बाउंड](https://www.w3.org/TR/dbsc/)
होता है।
[Chrome 146 (अप्रैल 2026) द्वारा विंडोज़ पर DBSC को GA में शिप करने](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)
के साथ, मानक प्रयोगात्मक से एक उत्पादन क्षमता में चला गया है जिसे वेब टीमें आज तैनात कर
सकती हैं। Chrome विंडोज़ पर TPMs का उपयोग करता है और इसके बाद macOS पर सिक्योर एन्क्लेव के
लिए सपोर्ट रोल आउट कर रहा है; मानक स्वयं की स्टोरेज के बारे में अज्ञेयवादी है, केवल यह
आवश्यकता है कि यह "वर्णित खतरे के खिलाफ मज़बूत" हो। यह चोरी की कुकीज़ को बहुत कम मूल्यवान
बनाता है। उन्हें बाउंड की के बिना किसी अन्य डिवाइस से रिफ्रेश नहीं किया जा सकता है।

यह लेख [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/glossary/oauth2) के बीच क्या संबंध है?
9. वास्तविक समय के खतरे की प्रतिक्रिया के लिए DBSC शेयर्ड सिग्नल्स (CAEP/RISC) के साथ कैसे
   एकीकृत होता है?

## 2. मुख्य समस्याओं और समाधानों को समझना

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

### 2.1 वर्तमान सेशन प्रबंधन की विफलता

वर्तमान सेशन प्रबंधन की मूलभूत विफलता विश्वास की "पोर्टेबिलिटी" है। जब कोई सर्वर सेशन कुकी
जारी करता है, तो वह अनिवार्य रूप से एक पासपोर्ट जारी कर रहा होता है जो इसे रखने वाले किसी
भी व्यक्ति के लिए काम करता है। जबकि ब्राउज़रों ने
[HttpOnly और Secure फ़्लैग](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies)
(JavaScript एक्सेस को रोकना और HTTPS पर ट्रांसमिशन सुनिश्चित करना) जैसे बचाव लागू किए हैं,
ये बचाव केवल क्रॉस-साइट स्क्रिप्टिंग (XSS) या नेटवर्क स्निफ़िंग जैसे विशिष्ट निष्कर्षण
वैक्टर से रक्षा करते हैं। वे होस्ट डिवाइस पर चल रहे मैलवेयर के खिलाफ कोई सुरक्षा प्रदान
नहीं करते हैं। "इन्फोस्टीलर्स" विशेष रूप से डिस्क पर ब्राउज़र की कुकी स्टोरेज फ़ाइल का पता
लगाने, उसे डिक्रिप्ट करने (अक्सर उपयोगकर्ता के स्वयं के OS-स्तर क्रेडेंशियल्स का उपयोग
करके), और कमांड-एंड-कंट्रोल सर्वर को सामग्री निकालने के लिए डिज़ाइन किए गए मैलवेयर हैं। एक
बार जब हमलावर के पास कुकी आ जाती है, तो वे एक
[पास-द-कुकी हमला](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)
कर सकते हैं, सेशन को हाईजैक करने के लिए अपने स्वयं के ब्राउज़र में चोरी किए गए टोकन को
इंजेक्ट कर सकते हैं। सर्वर, एक मान्य कुकी को देखकर, मान लेता है कि अनुरोध वैध है।

### 2.2 पारंपरिक सुरक्षित कुकीज़ पर DBSC का क्रिप्टोग्राफ़िक लाभ

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

### 2.3 पासकीज़ और DBSC के बीच तालमेल

पासकीज़ और DBSC पूरक प्रौद्योगिकियां हैं जो उपयोगकर्ता जीवनचक्र के विभिन्न चरणों को
सुरक्षित करती हैं। पासकीज़ (FIDO2) _प्रमाणीकरण_ समस्या को हल करती हैं पासवर्ड के बिना सेशन
शुरू करने के लिए पहचान साबित करती हैं, इस प्रकार क्रेडेंशियल फ़िशिंग को समाप्त करती हैं।
DBSC _पोस्ट-प्रमाणीकरण_ समस्या को संबोधित करता है जिससे कुकी चोरी के माध्यम से सेशन
हाइजैकिंग काफी कठिन हो जाती है।
[FIDO एलायंस DBSC को](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
एक पूरक तकनीक के रूप में प्रस्तुत करता है जो सेशन हाइजैकिंग के खिलाफ "बार बढ़ाता है"। एक
साथ, वे लॉगिन और सेशन जीवनचक्र में हमले की सतह को कम करते हैं हालांकि DBSC चल रहे डिवाइस
एक्सेस वाले मैलवेयर या उसी डिवाइस पर वास्तविक समय के ब्राउज़र-इन-द-मिडल हमलों से बचाव नहीं
करता है।

| प्रौद्योगिकियां           | रिमोट फ़िशिंग | क्रेडेंशियल स्टफिंग | टोकन चोरी |
| ------------------------- | ------------- | ------------------- | --------- |
| **पासकीज़**               | ✅            | ✅                  | ❌        |
| **DBSC / DPoP**           | ❌            | ❌                  | ✅        |
| **पासकीज़ + DBSC / DPoP** | ✅            | ✅                  | ✅        |

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

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

### 2.4 टोकन बाइंडिंग की विफलता से सीखना

DBSC इस समस्या को हल करने का पहला प्रयास नहीं है। "टोकन बाइंडिंग" एक पिछला मानक था जिसने
कुकीज़ को अंतर्निहित TLS (Transport Layer Security) कनेक्शन से बाइंड करने का प्रयास किया
था। हालांकि क्रिप्टोग्राफ़िक रूप से मज़बूत, टोकन बाइंडिंग TLS लेयर पर अपनी भारी निर्भरता
के कारण अपनाने में विफल रहा। आधुनिक वेब में, TLS कनेक्शन अक्सर लोड बैलेंसर, CDNs, या
रिवर्स प्रॉक्सी पर समाप्त हो जाते हैं, जबकि एप्लिकेशन लॉजिक उनके पीछे सर्वर पर रहता है। इन
जटिल नेटवर्क लेयर्स के माध्यम से टोकन बाइंडिंग जानकारी का प्रचार करना बहुत कठिन साबित हुआ।
DBSC इस विफलता से
[पूरी तरह से एप्लिकेशन लेयर (HTTP) पर काम करके](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
सीखता है। यह अंतर्निहित नेटवर्क कनेक्शन पर निर्भर नहीं करता है, जो इसे मौजूदा लोड बैलेंसर,
प्रॉक्सी और क्लाउड बुनियादी ढांचे के साथ संगत बनाता है।

### 2.5 व्यावसायिक निहितार्थ और ROI के अवसर

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

## 3. खतरे का परिदृश्य: कुकी चोरी का औद्योगीकरण

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

### 3.1 इन्फोस्टीलर्स का उदय

```mermaid
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](https://www.corbado.com/blog/passkey-webauthn-database-guide)
  फ़ाइल) और लॉगिन डेटा डेटाबेस (सहेजे गए पासवर्ड)।
- **तंत्र:** ब्राउज़र डेटा प्रोटेक्शन APIs (विंडोज़ पर DPAPI) का उपयोग करके इन डेटाबेस को
  उपयोगकर्ता के OS लॉगिन से जोड़कर एन्क्रिप्ट करते हैं। चूंकि मैलवेयर _उपयोगकर्ता के रूप
  में_ चलता है, इसलिए यह आसानी से इन फ़ाइलों के डिक्रिप्शन का अनुरोध कर सकता है।
- **आउटपुट:** मैलवेयर एक "लॉग" उत्पन्न करता है - एक ज़िप फ़ाइल जिसमें डिक्रिप्टेड कुकीज़,
  पासवर्ड, सिस्टम जानकारी और कभी-कभी क्रिप्टो-वॉलेट की शामिल होती हैं।

### 3.2 "लॉग" के लिए बाज़ार

इन लॉग्स को एकत्र किया जाता है और (इसके बंद होने से पहले) जेनेसिस मार्केट और रशियन मार्केट
जैसे डार्क वेब [मार्केटप्लेस](https://www.corbado.com/passkeys-for-e-commerce) पर बेचा जाता है। खरीदार विशिष्ट
उच्च-मूल्य वाले लक्ष्यों के लिए सक्रिय कुकीज़ वाले लॉग की खोज कर सकते हैं: "Salesforce,"
"Gmail," "Bank of America," या "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console।"

**बायपास:** एक कुकी लॉग का मूल्य मल्टी-फैक्टर प्रमाणीकरण (MFA) को बायपास करने की उसकी
क्षमता में निहित है। अधिकांश [MFA](https://www.corbado.com/hi/blog/medibank-data-breach) चुनौतियां (SMS, TOTP,
Push) केवल _लॉगिन_ इवेंट के दौरान होती हैं। एक बार सेशन स्थापित हो जाने और कुकी जारी हो
जाने के बाद, सर्वर मान लेता है कि उपयोगकर्ता विश्वसनीय है। एक वैध सेशन कुकी आयात करने वाला
हमलावर
[सीधे MFA गेट से आगे निकल जाता है](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc),
सर्वर को सक्रिय टैब पर लौटने वाले उपयोगकर्ता के रूप में दिखाई देता है।

### 3.3 Google Workspace और Microsoft Entra का खतरा

क्लाउड उत्पादकता सूट प्रमुख लक्ष्य हैं। Google Workspace या
[Microsoft Entra ID](https://www.corbado.com/hi/blog/enterprise-passkey-deployment-challenges) (पूर्व में Azure
AD) खाते के लिए एक चोरी की गई सेशन कुकी एक हमलावर को कॉर्पोरेट ईमेल, दस्तावेज़ों और आंतरिक
सिस्टम तक पहुंच प्रदान कर सकती है।
[Google की अपनी खतरे की खुफिया जानकारी](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)
ने Google खातों तक पहुंचने के लिए प्राथमिक वेक्टर के रूप में कुकी चोरी में भारी वृद्धि की
सूचना दी है, स्पष्ट रूप से इसे DBSC में उनके निवेश के लिए ड्राइवर के रूप में नामित किया
है। वे ध्यान देते हैं कि जैसे-जैसे वे 2-स्टेप वेरिफिकेशन (2SV) और पासकीज़ को बलपूर्वक
सक्षम करते हैं, हमलावरों ने क्रेडेंशियल फ़िशिंग (जिसे [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / पासकीज़
रोकता है) से कुकी चोरी (जिसे [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / पासकीज़ अक्सर नहीं रोकता है) में
रणनीति बदल दी है।

### 3.4 "डिवाइस फ़िंगरप्रिंटिंग" की सीमाएं

ऐतिहासिक रूप से, जोखिम इंजन ने
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) स्ट्रिंग, स्क्रीन
रिज़ॉल्यूशन, स्थापित फ़ॉन्ट और IP पते को देखकर, डिवाइस फ़िंगरप्रिंट का विश्लेषण करके सेशन
चोरी का पता लगाने की कोशिश की है। यदि कोई सेशन कुकी अचानक थोड़े भिन्न कैनवास फ़िंगरप्रिंट
के साथ एक नए IP से दिखाई देती है, तो सर्वर इसे अमान्य कर सकता है। **समस्या:** ब्राउज़रों
में गोपनीयता पहल (जैसे Safari की Intelligent Tracking Prevention और Chrome का Privacy
Sandbox) विज्ञापन-ट्रैकिंग को रोकने के लिए सक्रिय रूप से इन फ़िंगरप्रिंट की एन्ट्रॉपी को
कम कर रही हैं। यह सुरक्षा के लिए "अच्छी" फ़िंगरप्रिंटिंग को तेजी से कठिन बना देता है। इसके
अलावा, हमलावर अब "एंटी-डिटेक्ट ब्राउज़र" का उपयोग करते हैं जो उन्हें पीड़ित की प्रोफ़ाइल
से पूरी तरह मेल खाने के लिए इन फ़िंगरप्रिंट को खराब करने की अनुमति देते हैं, जिससे
अनुमानित पहचान अप्रभावी हो जाती है। DBSC इस संभाव्य अनुमान लगाने के खेल को नियतात्मक
क्रिप्टोग्राफ़िक प्रमाण के साथ बदल देता है।

## 4. तकनीकी वास्तुकला: DBSC कैसे काम करता है

डिवाइस बाउंड सेशन क्रेडेंशियल्स (DBSC) क्लाइंट डिवाइस पर की से बाउंड सेशन बनाने के लिए एक
[मानकीकृत API और प्रोटोकॉल](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)
पेश करता है। मानक को "वर्णित खतरे के खिलाफ मज़बूत" की स्टोरेज की आवश्यकता है लेकिन
कार्यान्वयन के बारे में अज्ञेयवादी है। उपलब्ध होने पर Chrome विंडोज़ पर TPM का उपयोग करता
है। यह अनुभाग W3C वर्किंग ड्राफ्ट और Chrome के दस्तावेज़ीकरण में परिभाषित तंत्र का विवरण
देता है।

### 4.1 मुख्य घटक

| **घटक**                         | **विवरण**                                         | **DBSC में भूमिका**                                                                                                              |
| ------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **उपयोगकर्ता एजेंट (ब्राउज़र)** | क्लाइंट एप्लिकेशन (Chrome, Edge, आदि)।            | की पेयर का प्रबंधन करता है, HSM इंटरैक्शन को संभालता है, और प्रमाण संलग्न करने के लिए नेटवर्क अनुरोधों को रोकता है।              |
| **रिलायिंग पार्टी (सर्वर)**     | वेब एप्लिकेशन (जैसे, बैंकिंग पोर्टल)।             | चुनौतियां जारी करता है, सिग्नेचर को सत्यापित करता है, और सेशन जीवनचक्र का प्रबंधन करता है।                                       |
| **की स्टोरेज**                  | सुरक्षित स्टोरेज (TPM, सिक्योर एन्क्लेव, या अन्य) | प्राइवेट की संग्रहीत करता है। उपलब्ध होने पर Chrome विंडोज़ पर TPM का उपयोग करता है; मानक कार्यान्वयन के बारे में अज्ञेयवादी है। |
| **सेशन कुकी**                   | एक मानक HTTP कुकी।                                | बियरर टोकन के रूप में उपयोग किया जाता है, लेकिन बहुत कम जीवनकाल के साथ (जैसे, 5-10 मिनट)।                                        |
| **कब्जे का प्रमाण**             | एक क्रिप्टोग्राफ़िक सिग्नेचर।                     | एक JWT जिसे ब्राउज़र द्वारा भेजा जाता है यह साबित करने के लिए कि उसके पास अभी भी प्राइवेट की है।                                 |

### 4.2 DBSC प्रोटोकॉल जीवनचक्र

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

```mermaid
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->>ब्राउज़र: सिग्नेचर
    ब्राउज़र->>सर्वर: सिग्नेचर प्रमाण
    सर्वर->>सर्वर: संग्रहीत पब्लिक की के साथ सत्यापित करें
    सर्वर->>ब्राउज़र: नई अल्पकालिक कुकी
    ब्राउज़र->>सर्वर: मूल अनुरोध का पुनः प्रयास करें
    सर्वर->>ब्राउज़र: सफलता प्रतिक्रिया
```

#### 4.2.1 चरण 1: शुरुआत और बाइंडिंग

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

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) को इस विशिष्ट
   पब्लिक की के साथ जोड़ने के लिए अपने डेटाबेस को अपडेट करता है। इस क्षण से, सेशन "बाउंड"
   हो जाता है।

#### 4.2.2 चरण 2: अल्पकालिक कुकी लूप

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

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

#### 4.2.3 चरण 3: रिफ्रेश (कब्जे का प्रमाण)

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

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. **पुनरारंभ:** ब्राउज़र नई कुकी लेता है और मूल रोके गए अनुरोध को पारदर्शी रूप से पुनः
   प्रयास करता है।
   [उपयोगकर्ता को कोई रुकावट अनुभव नहीं होती है](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)।

### 4.3 कार्यान्वयन बारीकियां

#### 4.3.1 "लिफ्ट और शिफ्ट" बचाव

```mermaid
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 हेडर देखता है लेकिन रिफ्रेश नहीं कर सकता क्योंकि उसके पास बाउंड प्राइवेट
  की नहीं है। हमला विफल हो जाता है।

#### 4.3.2 दायरा और गोपनीयता

गोपनीयता DBSC का एक केंद्रीय डिज़ाइन लक्ष्य है।
[W3C विनिर्देश](https://www.w3.org/TR/dbsc/) स्पष्ट रूप से वैश्विक पहचानकर्ताओं के उपयोग
पर रोक लगाता है जो साइटों के पार उपयोगकर्ताओं को ट्रैक कर सकते हैं।

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

#### 4.3.3 सर्वर-साइड विचार

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

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

## 5. व्यावसायिक और उत्पाद निहितार्थ

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

### 5.1 घर्षण रहित सुरक्षा का ROI

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

- **धोखाधड़ी में कमी:** अकाउंट टेकओवर (ATO) के प्राथमिक वेक्टर को बेअसर करके, व्यवसाय
  धोखाधड़ी के नुकसान में लाखों बचा सकते हैं।
- **सपोर्ट लागत:** अकाउंट रिकवरी महंगी है।
  [पहली जगह में हैक को रोकना](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
  सीधे इस परिचालन बोझ को कम करता है।
- **रूपांतरण अनुकूलन:** [ई-कॉमर्स](https://www.corbado.com/passkeys-for-e-commerce) में, हर लॉगिन प्रॉम्प्ट एक
  संभावित ड्रॉप-ऑफ़ पॉइंट है। DBSC आक्रामक "मुझे लॉग इन रखें" नीतियों की अनुमति देता है,
  जिससे पासवर्ड प्रॉम्प्ट के बिना त्वरित चेकआउट सक्षम होता है।

### 5.2 अनुपालन और "स्टेट ऑफ द आर्ट"

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

- **बचाव योग्य सुरक्षा:** जैसे-जैसे DBSC एक मानक बन जाता है, इसे संभवतः सेशन प्रबंधन के
  लिए "स्टेट ऑफ द आर्ट" के रूप में व्याख्यायित किया जाएगा। उल्लंघन की स्थिति में, यह
  प्रदर्शित करना कि DBSC लागू किया गया था, लापरवाही के दावों के खिलाफ एक मज़बूत बचाव हो
  सकता है।
- **बैंकिंग मानक (PSD2):** [पेमेंट](https://www.corbado.com/hi/blog/digital-credentials-aur-bhugtan) सर्विसेज
  डायरेक्टिव 2 के लिए "स्ट्रॉन्ग कस्टमर ऑथेंटिकेशन" (SCA) की आवश्यकता होती है। जबकि
  [SCA](https://www.corbado.com/hi/blog/psd2-passkeys) लॉगिन पर केंद्रित है, डिवाइस के साथ सेशन की गतिशील लिंकिंग
  प्रमाणीकरण को विशिष्ट राशियों और भुगतानकर्ताओं से बाइंड करने के निर्देश के लक्ष्यों के
  साथ पूरी तरह से मेल खाती है।

### 5.3 उच्च आश्वासन बनाम मध्यम आश्वासन

[FIDO एलायंस श्वेतपत्र](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/)
"आश्वासन स्तर" की अवधारणा पर प्रकाश डालते हैं।

- **मध्यम आश्वासन:** सिंक किए गए पासकीज़ (जैसे
  [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) में) का उपयोग करता है। उपभोक्ता ऐप्स के लिए
  बढ़िया, पुनर्प्राप्त करने योग्य, उपयोग करने में आसान।
- **उच्च आश्वासन:** डिवाइस-बाउंड की की आवश्यकता होती है। यह वह जगह है जहां DBSC चमकता है।
  एंटरप्राइज़ संसाधनों (HR पोर्टल, कोड रिपॉजिटरी) या उच्च-मूल्य वाले
  [बैंकिंग](https://www.corbado.com/passkeys-for-banking) के लिए, संगठन एक नीति लागू कर सकता है जो _केवल_ एक
  विशिष्ट प्रबंधित डिवाइस से बाउंड सेशन से पहुंच की अनुमति देती है। DBSC इस नीति के लिए
  तकनीकी प्रवर्तन तंत्र प्रदान करता है।

## 6. DBSC बनाम विकल्प

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

```mermaid
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
```

### 6.1 DBSC बनाम टोकन बाइंडिंग

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

- **टोकन बाइंडिंग:** क्लाइंट, सर्वर, _और_ बीच के हर हॉप (लोड बैलेंसर, TLS टर्मिनेटर) से
  समर्थन की आवश्यकता थी। जब कोई कनेक्शन समाप्त और पुनः एन्क्रिप्ट किया जाता था तो यह टूट
  जाता था।
- **DBSC:**
  [HTTP एप्लिकेशन लेयर पर काम करता है](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)।
  यह मानक हेडर/कुकीज़ के रूप में लोड बैलेंसर के माध्यम से पारदर्शी रूप से गुजरता है।
  आधुनिक क्लाउड आर्किटेक्चर (AWS/GCP/Azure) में तैनात करना बहुत आसान है जहां TLS अक्सर
  क्लाउड प्रदाता के एज नेटवर्क द्वारा नियंत्रित किया जाता है।

### 6.2 DBSC बनाम DPoP (कब्जे का प्रमाण प्रदर्शित करना)

[DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) "सेंडर-कन्स्ट्रेंड" OAuth
टोकन के लिए मानक है। यह एक्सेस टोकन _और_ रिफ्रेश टोकन दोनों को एक पब्लिक की से बाइंड करता
है - महत्वपूर्ण है क्योंकि रिफ्रेश टोकन स्वयं लंबे समय तक चलने वाले बियरर क्रेडेंशियल्स
हैं। प्रत्येक API अनुरोध में एक DPoP प्रमाण शामिल होता है: HTTP विधि, URL, टाइमस्टैम्प और
अद्वितीय पहचानकर्ता के साथ एक हस्ताक्षरित JWT। उच्च-आश्वासन विनिर्देश जैसे
[FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) सेंडर-कन्स्ट्रेंड टोकन
अनिवार्य करते हैं; जब mTLS अनुपलब्ध हो तो DPoP अनुशंसित विधि है।

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

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

| पहलू               | DPoP                                  | DBSC                                |
| ------------------ | ------------------------------------- | ----------------------------------- |
| **लक्ष्य**         | OAuth एक्सेस + रिफ्रेश टोकन           | ब्राउज़र सेशन कुकीज़                |
| **की स्टोरेज**     | ऐप संदर्भ (सर्वोत्तम अभ्यास: OS APIs) | हार्डवेयर-समर्थित (TPM)             |
| **XSS प्रतिरोध**   | ⚠️ कार्यान्वयन-निर्भर                 | ✅ की निर्यात नहीं की जा सकतीं      |
| **प्राथमिक उपयोग** | नेटिव ऐप्स, SPAs, FAPI 2.0            | उपयोगकर्ता-सामना करने वाले वेब सेशन |

**तालमेल:** जैसा कि
[FIDO एलायंस नोट करता है](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/),
पासकीज़ लॉगिन पर फ़िशिंग को खत्म कर देती हैं, जबकि DBSC/DPoP पोस्ट-प्रमाणीकरण टोकन की
रक्षा करते हैं। एक आधुनिक वास्तुकला दोनों को जोड़ती है: OAuth APIs के लिए DPoP (विशेष रूप
से विनियमित ओपन [बैंकिंग](https://www.corbado.com/passkeys-for-banking)), ब्राउज़र सेशन के लिए DBSC। साथ में वे
पूरे सेशन जीवनचक्र में "लिफ्ट और शिफ्ट" हमले के वेक्टर को बंद कर देते हैं।

### 6.3 DBSC बनाम शॉर्ट-लिव्ड कुकीज़ (अकेले)

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

## 7. शेयर्ड सिग्नल्स और डायनेमिक रिस्पॉन्स (CAEP/RISC)

```mermaid
%%{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)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/),
विशेष रूप से **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 अल्पकालिक कुकी को रिफ्रेश करने का प्रयास
   करता है, तो सर्वर सिग्नेचर को अस्वीकार कर देता है और सेशन को समाप्त कर देता है।\
   यह [वास्तुकला पैटर्न](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/)
   तेज़ रद्दीकरण को सक्षम करता है - वास्तविक विलंबता साइट की रिफ्रेश अवधि और इस बात पर
   निर्भर करती है कि उन्होंने DBSC और SSF दोनों को लागू किया है या नहीं।

## 8. ब्राउज़र और इकोसिस्टम सपोर्ट

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

### 8.1 Google Chrome

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

- **स्थिति (अप्रैल 2026):**
  [Chrome 146 विंडोज़ पर DBSC को सामान्य उपलब्धता में शिप करता है](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/),
  जिससे ओरिजिन ट्रायल चरण समाप्त हो जाता है। सिक्योर एन्क्लेव का उपयोग करके macOS सपोर्ट,
  आगामी Chrome रिलीज़ के लिए घोषित किया गया है।
- **हार्डवेयर:** विंडोज़ TPM का उपयोग करता है, macOS सिक्योर एन्क्लेव का उपयोग करेगा।
  Google ने कहा है कि वह सुरक्षित हार्डवेयर के बिना डिवाइस तक DBSC सुरक्षा का विस्तार करने
  के लिए **सॉफ़्टवेयर-आधारित की** की भी खोज कर रहा है।
- **रोडमैप:** Google की GA घोषणा ने अगला-कदम रोडमैप भी प्रकाशित किया:
    - **फेडेरेटेड आइडेंटिटी को सुरक्षित करना:** क्रॉस-ओरिजिन DBSC बाइंडिंग ताकि
      रिलायिंग-पार्टी (RP) सेशन आइडेंटिटी-प्रोवाइडर (IdP) सेशन के समान डिवाइस की से बाउंड
      रहे, जिससे [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) के माध्यम से विश्वास की एक अटूट
      श्रृंखला सुरक्षित रहे।
    - **एडवांस रजिस्ट्रेशन:** साइन-इन पर एक नई की जनरेट करने के बजाय, DBSC सेशन को पहले से
      मौजूद विश्वसनीय की सामग्री जैसे **mTLS सर्टिफिकेट** या **हार्डवेयर सुरक्षा की** से
      बाइंड करना।
    - **व्यापक डिवाइस सपोर्ट:** TPM / सिक्योर एन्क्लेव के बिना डिवाइस के लिए
      सॉफ़्टवेयर-आधारित की।
- **परिचालन परिणाम:** रोलआउट के दौरान Google ने DBSC द्वारा संरक्षित सेशन के लिए "सेशन
  चोरी में महत्वपूर्ण कमी" की रिपोर्ट दी।
- **Google खाते:** अलग से, Google पहले ही
  [Chrome for Windows पर Google खाता कुकीज़](https://support.google.com/chrome/a/answer/2657289)
  के लिए DBSC-शैली सुरक्षा रोल आउट कर चुका था, जिसे एंटरप्राइज़ नीति के माध्यम से
  नियंत्रित किया जाता है। यह Gmail/Workspace की रक्षा करता है और अब वही प्रौद्योगिकी
  परिवार है जो सामान्य वेब के लिए GA है।

### 8.2 Microsoft Edge और विंडोज़

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

- **स्थिति:** Edge ने विंडोज़ पर एक
  [DBSC ओरिजिन ट्रायल](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d)
  चलाया जो अक्टूबर 2025 में समाप्त हुआ। किसी प्रतिस्थापन ट्रायल या GA की घोषणा नहीं की गई
  है।
- **एंटरप्राइज़ संदर्भ:** Edge Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) के
  लिए
  ["Primary Refresh Token" (PRT) आर्किटेक्चर](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token)
  का उपयोग करता है, जो वैचारिक रूप से DBSC के समान है। PRT एक Microsoft-विशिष्ट तंत्र बना
  हुआ है; तृतीय-पक्ष साइटों के लिए इसे DBSC वेब मानक के साथ एकीकृत करने की कोई घोषित योजना
  नहीं है।

### 8.3 Apple Safari (WebKit)

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

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

### 8.4 Mozilla Firefox

Mozilla में जटिलता और गोपनीयता के बारे में ज्ञात चिंताओं के साथ DBSC का मूल्यांकन करने
वाला एक
[standards-position issue](https://github.com/mozilla/standards-positions/issues/912) है।
मानक स्थिर होने के बाद लागू करने की कोई सार्वजनिक प्रतिबद्धता नहीं है।

## 9. सिफ़ारिशें: आज उपयोगकर्ताओं की सुरक्षा करना

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

### 9.1 तत्काल कार्रवाइयां (अब Chrome 146 GA है)

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

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

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

### 9.2 रणनीतिक योजना (अगले 12 महीने)

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

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

3. **आइडेंटिटी प्रोवाइडर के साथ एकीकृत करें**: यदि Okta,
   [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), या समान IdPs का उपयोग कर रहे हैं, तो उनके SDKs
   में DBSC समर्थन को सक्षम करने के लिए उनके साथ काम करें। कई लोगों ने ओरिजिन ट्रायल में
   भाग लिया और Chrome के GA होने के बाद अब सक्रिय रूप से DBSC क्षमताओं को शिप कर रहे हैं।

### 9.3 कार्यान्वयन सर्वोत्तम अभ्यास

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

## 10. Corbado कैसे मदद कर सकता है: भविष्य का पुल

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

### 10.1 आधार: पासकीज़

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

### 10.2 भविष्य: विश्वसनीय डिवाइस पहचान के लिए DBSC

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

- **सिंक की गई पासकी अस्पष्टता को हल करना:** सिंक की गई पासकीज़ सुविधाजनक हैं लेकिन एक
  विश्वास अंतर पैदा करती हैं: जब कोई उपयोगकर्ता सिंक की गई पासकी से प्रमाणित होता है, तो
  आप यह नहीं बता सकते कि यह उनका सामान्य लैपटॉप है या कोई बिल्कुल नया डिवाइस जिसने अभी
  क्रेडेंशियल को सिंक किया है। DBSC इस अंतर को बंद कर देता है। यह जांच कर कि क्या डिवाइस
  में स्थापित DBSC बाइंडिंग है, Corbado सत्यापित कर सकता है कि डिवाइस वास्तव में ज्ञात और
  विश्वसनीय है, न कि केवल पहली बार सिंक किया गया है।
- **ज्ञात डिवाइस के लिए उच्च विश्वास:** जब DBSC सिग्नल पुष्टि करते हैं कि एक डिवाइस को
  पहले देखा गया है, तो Corbado अधिक आत्मविश्वास से जोखिम निर्णय ले सकता है: वैध लौटने वाले
  उपयोगकर्ताओं के लिए कम स्टेप-अप प्रमाणीकरण प्रॉम्प्ट, अज्ञात डिवाइस से सेशन के लिए सख्त
  जांच।
- **पासकी इंटेलिजेंस का पूरक:** DBSC सिग्नल Corbado के मौजूदा
  [**पासकी इंटेलिजेंस**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
  इंजन के साथ एकीकृत होते हैं। पासकी-आधारित प्रमाणीकरण और DBSC-आधारित डिवाइस बाइंडिंग का
  संयोजन लॉगिन से लेकर पूरे सेशन जीवनचक्र तक एक पूर्ण विश्वास श्रृंखला बनाता है।

इस बारे में सवालों के लिए कि Corbado अपने प्लेटफ़ॉर्म में DBSC को कैसे एकीकृत करने की
योजना बना रहा है, [टीम से संपर्क करें](https://www.corbado.com/contact)।

### 10.3 ग्रेसफुल फ़ॉलबैक ("हाइब्रिड" वास्तविकता)

अगले कुछ वर्षों तक, वेब हाइब्रिड रहेगा। कुछ उपयोगकर्ताओं के पास DBSC-सक्षम ब्राउज़र
(Windows 11 पर Chrome) होंगे; अन्य पुराने सिस्टम पर होंगे। इस विखंडन को संभालना मुश्किल
है। Corbado का
[**पासकी इंटेलिजेंस**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
इंजन सक्षम डिवाइसों को पासकीज़ प्रदान करने और दूसरों के लिए फ़ॉलबैक करने वाले इस प्रकार के
फ़ॉलबैक लॉजिक को संभालने के लिए डिज़ाइन किया गया है। यही इंटेलिजेंस सेशन बाइंडिंग पर लागू
होता है, यह सुनिश्चित करते हुए कि प्रत्येक उपयोगकर्ता के लिए उनके डिवाइस की क्षमताओं के
अनुसार सुरक्षा अधिकतम हो।

## 11. निष्कर्ष: DBSC के लिए आगे का रास्ता

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

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

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

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

कार्यान्वयन के लिए खरोंच से निर्माण की आवश्यकता नहीं है।
[Corbado](https://www.corbado.com/features) जैसे प्लेटफ़ॉर्म पासकी बुनियादी ढांचा प्रदान
करते हैं और ब्राउज़र समर्थन परिपक्व होने पर डिवाइस-बाइंडिंग को एकीकृत करने के लिए DBSC
विकास को ट्रैक कर रहे हैं। [W3C विनिर्देश](https://www.w3.org/TR/dbsc/) एक सक्रिय वर्किंग
ड्राफ्ट है, Chrome 146 विंडोज़ पर GA है और macOS पर रोल आउट हो रहा है, और अन्य ब्राउज़र
अभी भी मानक का मूल्यांकन कर रहे हैं।

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

## अक्सर पूछे जाने वाले प्रश्न

### DBSC, CAEP और RISC के साथ मिलकर वास्तविक समय में समझौता किए गए सेशन को कैसे रद्द करता है?

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

### वेब एप्लिकेशन सेशन की सुरक्षा के लिए DBSC और DPoP के बीच क्या अंतर है?

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

### DBSC सुरक्षा जोखिम बढ़ाए बिना लंबी सेशन अवधि की अनुमति क्यों देता है?

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

### DBSC को लागू करने से एंटरप्राइज़ किस व्यावसायिक ROI की उम्मीद कर सकते हैं?

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