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

bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

डिवाइस बाउंड सेशन क्रेडेंशियल (डीबीएससी), हार्डवेयर की मदद से सेशन की सुरक्षा जोड़कर, पुष्टि करने की प्रोसेस को मज़बूत बनाते हैं.

Daniel Rubery

José Luis Zapata

परिचय

कई वेबसाइटें, उपयोगकर्ता की पुष्टि करने के लिए लंबे समय तक सेव रहने वाली कुकी का इस्तेमाल करती हैं. हालांकि, इनमें सेशन हाइजैकिंग की आशंका होती है. डिवाइस बाउंड सेशन क्रेडेंशियल (डीबीएससी), हार्डवेयर की मदद से सुरक्षा की एक लेयर जोड़ता है. इससे, इस जोखिम को कम करने में मदद मिलती है. साथ ही, यह पक्का किया जाता है कि सेशन किसी खास डिवाइस से जुड़े हों.

यह गाइड उन डेवलपर के लिए है जो वेब ऐप्लिकेशन में पुष्टि करने के फ़्लो मैनेज करते हैं. इसमें बताया गया है कि डीबीएससी कैसे काम करता है और इसे अपनी साइट में कैसे इंटिग्रेट किया जा सकता है.

डीबीएससी कैसे काम करता है

डीबीएससी, उपयोगकर्ता के डिवाइस से जुड़ी क्रिप्टोग्राफ़िक कुंजी जोड़ता है. Chrome, लॉगिन के दौरान यह कुंजी जोड़ी जनरेट करता है. साथ ही, ट्रस्टेड प्लैटफ़ॉर्म मॉड्यूल (टीपीएम) जैसे सुरक्षित हार्डवेयर में निजी कुंजी सेव करता है. सेशन, कम समय तक काम करने वाली कुकी का इस्तेमाल करते हैं. जब इनमें से किसी कुकी की समयसीमा खत्म हो जाती है, तो Chrome उन्हें रीफ़्रेश करने से पहले, निजी कुंजी के पास होने की पुष्टि करता है. इस प्रोसेस से, सेशन को ओरिजनल डिवाइस से लिंक किया जाता है.

अगर उपयोगकर्ता के डिवाइस पर सुरक्षित कुंजी का स्टोरेज काम नहीं करता है, तो डीबीएससी, पुष्टि करने के फ़्लो को बाधित किए बिना, स्टैंडर्ड तरीके पर काम करता है.

लागू करने के बारे में खास जानकारी

अपने ऐप्लिकेशन में DBSC को इंटिग्रेट करने के लिए, आपको ये बदलाव करने होंगे:

• Sec-Session-Registration हेडर शामिल करने के लिए, अपने लॉगिन फ़्लो में बदलाव करें.
• ऐसा सेशन रजिस्ट्रेशन एंडपॉइंट जोड़ें जो:
  • उपयोगकर्ता के सेशन के साथ सार्वजनिक कुंजी जोड़ता है.
  • सेशन कॉन्फ़िगरेशन दिखाता है.
  • कुछ समय के लिए सेव होने वाली कुकी का इस्तेमाल करना.
• कुकी रिन्यूअल और पासकोड के मालिकाना हक की पुष्टि करने के लिए, रीफ़्रेश एंडपॉइंट जोड़ें.

आपके ज़्यादातर मौजूदा एंडपॉइंट में कोई बदलाव करने की ज़रूरत नहीं है. डीबीएससी को इस तरह से डिज़ाइन किया गया है कि यह आपके मौजूदा सिस्टम में कोई रुकावट पैदा किए बिना, उसमें बेहतर सुविधाएं जोड़ सके.

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

लागू करने का तरीका

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

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

1. लॉगिन फ़्लो में बदलाव करना

उपयोगकर्ता के लॉग इन करने के बाद, लंबे समय तक सेव रहने वाली कुकी और Sec-Session-Registration हेडर का इस्तेमाल करके जवाब दें. उदाहरण के लिए:

सेशन रजिस्टर होने के बाद, यह एचटीटीपी रिस्पॉन्स हेडर दिखता है:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

अगर डिवाइस में पासकोड को सुरक्षित तरीके से सेव करने की सुविधा है, तो Chrome, JSON वेब टोकन (JWT) में मौजूद सार्वजनिक पासकोड की मदद से /StartSession एंडपॉइंट से संपर्क करता है.

इस उदाहरण में, auth_cookie आपके सेशन टोकन को दिखाता है. इस कुकी को अपनी पसंद का नाम दिया जा सकता है. हालांकि, यह ज़रूरी है कि यह आपके सेशन कॉन्फ़िगरेशन में मौजूद name फ़ील्ड से मेल खाती हो और आपके पूरे ऐप्लिकेशन में इसका लगातार इस्तेमाल किया जाता हो.

2. सेशन रजिस्ट्रेशन एंडपॉइंट लागू करना

/StartSession पर, आपके सर्वर को:

• मिली सार्वजनिक कुंजी को उपयोगकर्ता के सेशन से जोड़ें.
• सेशन कॉन्फ़िगरेशन के साथ जवाब दें.
• लंबे समय तक सेव रहने वाली कुकी को, कम समय तक सेव रहने वाली कुकी से बदलें.

यहां दिए गए उदाहरण में, कम समय तक चलने वाली कुकी को 10 मिनट बाद खत्म होने के लिए कॉन्फ़िगर किया गया है:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. रीफ़्रेश एंडपॉइंट लागू करना

जब कुछ समय के लिए सेव की गई कुकी की समयसीमा खत्म हो जाती है, तो Chrome रीफ़्रेश फ़्लो शुरू करता है. इससे यह साबित होता है कि निजी कुंजी आपके पास है. इस प्रोसेस में, Chrome और आपके सर्वर, दोनों की ओर से एक साथ कार्रवाइयां की जाती हैं:

1. Chrome, उपयोगकर्ता के अनुरोध को आपके ऐप्लिकेशन पर भेजता है और /RefreshEndpoint को रीफ़्रेश करने का अनुरोध भेजता है:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   

2. आपका सर्वर चैलेंज के साथ जवाब देता है:

   HTTP/1.1 401 Unauthorized
   Sec-Session-Challenge: "challenge_value"
   

3. Chrome, सेव की गई निजी कुंजी का इस्तेमाल करके चैलेंज पर हस्ताक्षर करता है और अनुरोध फिर से करता है:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Session-Id: session_id
   Sec-Session-Response: <JWT proof>
   

4. आपका सर्वर, हस्ताक्षर किए गए सबूत की पुष्टि करता है और एक नई, कम समय तक चलने वाली कुकी जारी करता है:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome को रीफ़्रेश की गई कुकी मिलती है और वह टास्क को फिर से शुरू करता है.

इंटिग्रेशन का वैकल्पिक पैटर्न

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

• डीबीएससी काम न करने पर भी, लंबे समय तक सेव रहने वाली कुकी बनी रहती है.
• कुछ समय तक काम करने वाली कुकी को डीबीएससी का इस्तेमाल करके रीफ़्रेश किया जाता है. यह कुकी संवेदनशील ऑपरेशन के लिए ज़रूरी है.

इस पैटर्न से, साइटों को असामान्य स्थितियों को हैंडल करने के तरीके पर ज़्यादा कंट्रोल मिलता है.

सावधानियां और फ़ॉलबैक व्यवहार

Chrome, इन स्थितियों में डीबीएससी के कामों को छोड़ सकता है और डीबीएससी की मैनेज की गई कम अवधि वाली कुकी के बिना अनुरोध भेज सकता है:

• नेटवर्क से जुड़ी गड़बड़ियों या सर्वर से जुड़ी समस्याओं की वजह से, रीफ़्रेश एंडपॉइंट तक नहीं पहुंचा जा सकता.
• TPM व्यस्त है या हस्ताक्षर करने में गड़बड़ियां आ रही हैं. TPM को सिस्टम की सभी प्रोसेस के साथ शेयर किया जाता है. इसलिए, ज़्यादा बार रीफ़्रेश करने पर, रेट की सीमाएं पार हो सकती हैं.
• DBSC की ओर से मैनेज की जाने वाली, कुछ समय के लिए सेव होने वाली कुकी, तीसरे पक्ष की कुकी है. साथ ही, उपयोगकर्ता ने अपनी ब्राउज़र सेटिंग में तीसरे पक्ष की कुकी को ब्लॉक किया है.

इन स्थितियों में, अगर लंबे समय तक सेव रहने वाली कुकी अब भी मौजूद है, तो Chrome उसका इस्तेमाल करता है. यह फ़ॉलबैक सिर्फ़ तब काम करता है, जब आपके लागू किए गए तरीके में लंबे समय तक चलने वाली और कम समय तक चलने वाली, दोनों कुकी शामिल हों. अगर ऐसा नहीं है, तो Chrome कुकी के बिना अनुरोध भेजता है.

खास जानकारी

डिवाइस बाउंड सेशन के क्रेडेंशियल की सुविधा, आपके ऐप्लिकेशन में कम से कम बदलाव करके सेशन की सुरक्षा को बेहतर बनाती है. ये सेशन को कुछ खास डिवाइसों से जोड़कर, सेशन हाइजैकिंग के ख़िलाफ़ ज़्यादा सुरक्षा देते हैं. ज़्यादातर उपयोगकर्ताओं को बिना किसी रुकावट के फ़ायदा मिलता है. साथ ही, डीबीएससी, काम न करने वाले हार्डवेयर पर भी आसानी से काम करता है.

ज़्यादा जानकारी के लिए, डीबीएससी की स्पेसिफ़िकेशन देखें.