ডিভাইস বাউন্ড সেশন শংসাপত্র (DBSC)

ডিভাইস বাউন্ড সেশন ক্রেডেনশিয়াল (DBSC) হার্ডওয়্যার-সমর্থিত সেশন নিরাপত্তা যোগ করে প্রমাণীকরণকে শক্তিশালী করে।

Daniel Rubery

José Luis Zapata

ভূমিকা

অনেক ওয়েবসাইট ব্যবহারকারীর প্রমাণীকরণের জন্য দীর্ঘস্থায়ী কুকির উপর নির্ভর করে, কিন্তু এগুলি সেশন হাইজ্যাকিংয়ের ঝুঁকিতে থাকে। ডিভাইস বাউন্ড সেশন ক্রেডেনশিয়ালস (DBSC) এই ঝুঁকি কমাতে হার্ডওয়্যার-সমর্থিত সুরক্ষার একটি স্তর যুক্ত করে, যা নিশ্চিত করে যে সেশনগুলি নির্দিষ্ট ডিভাইসের সাথে আবদ্ধ।

এই নির্দেশিকাটি সেইসব ডেভেলপারদের জন্য যারা ওয়েব অ্যাপ্লিকেশনগুলিতে প্রমাণীকরণ প্রবাহ বজায় রাখেন। এটি ব্যাখ্যা করে যে DBSC কীভাবে কাজ করে এবং কীভাবে এটি আপনার সাইটে সংহত করতে হয়।

ডিবিএসসি কীভাবে কাজ করে

উচ্চ স্তরে, DBSC ব্যবহারকারীর ডিভাইসের সাথে যুক্ত একটি ক্রিপ্টোগ্রাফিক কী জোড়া প্রবর্তন করে। লগইন করার সময় Chrome এই কী জোড়া তৈরি করে এবং উপলব্ধ হলে নিরাপদ হার্ডওয়্যার, যেমন একটি ট্রাস্টেড প্ল্যাটফর্ম মডিউল (TPM) -এ প্রাইভেট কী সংরক্ষণ করে। সেশনগুলি স্বল্পস্থায়ী কুকি ব্যবহার করে। যখন এই কুকিগুলির একটির মেয়াদ শেষ হয়ে যায়, তখন ক্রোম সেগুলিকে রিফ্রেশ করার আগে প্রাইভেট কীটির মালিকানা প্রমাণ করে। এই প্রক্রিয়াটি সেশনের ধারাবাহিকতাকে মূল ডিভাইসের সাথে লিঙ্ক করে।

যদি কোনও ব্যবহারকারীর ডিভাইস সুরক্ষিত কী স্টোরেজ সমর্থন না করে, তাহলে DBSC প্রমাণীকরণ প্রবাহকে ব্যাহত না করেই সুন্দরভাবে স্ট্যান্ডার্ড আচরণে ফিরে আসে।

বাস্তবায়নের সারসংক্ষেপ

আপনার অ্যাপ্লিকেশনে DBSC সংহত করতে, আপনাকে নিম্নলিখিত পরিবর্তনগুলি করতে হবে:

• আপনার লগইন ফ্লো পরিবর্তন করে একটি Secure-Session-Registration হেডার অন্তর্ভুক্ত করুন।
• একটি সেশন রেজিস্ট্রেশন এন্ডপয়েন্ট যোগ করুন যা:
  • ব্যবহারকারীর সেশনের সাথে একটি পাবলিক কী সংযুক্ত করে।
  • সেশন কনফিগারেশন পরিবেশন করে।
  • স্বল্পস্থায়ী কুকিতে রূপান্তর।
• কুকি পুনর্নবীকরণ এবং কী দখল যাচাইকরণ পরিচালনা করতে একটি রিফ্রেশ এন্ডপয়েন্ট যোগ করুন।

আপনার বিদ্যমান বেশিরভাগ এন্ডপয়েন্টের কোনও পরিবর্তনের প্রয়োজন নেই। DBSC এমনভাবে ডিজাইন করা হয়েছে যাতে এটি সংযোজনকারী এবং বিঘ্নিত না হয়।

যখন কোনও প্রয়োজনীয় স্বল্পস্থায়ী কুকি অনুপস্থিত থাকে বা মেয়াদোত্তীর্ণ হয়, তখন Chrome অনুরোধটি থামিয়ে কুকিটি রিফ্রেশ করার চেষ্টা করে। এটি আপনার অ্যাপকে ব্যবহারকারী সাইন ইন করেছেন কিনা তা নিশ্চিত করার জন্য তার স্বাভাবিক সেশন কুকি চেক ব্যবহার করতে দেয়। যেহেতু এটি সাধারণ প্রমাণীকরণ প্রবাহের সাথে মেলে, তাই DBSC আপনার লগইন লজিকে ন্যূনতম পরিবর্তনের সাথে কাজ করে।

বাস্তবায়নের ধাপ

এই বিভাগটি আপনার প্রমাণীকরণ সিস্টেমের প্রয়োজনীয় পরিবর্তনগুলি নিয়ে আলোচনা করবে, যার মধ্যে রয়েছে আপনার লগইন প্রবাহ কীভাবে পরিবর্তন করবেন, সেশন নিবন্ধন পরিচালনা করবেন এবং স্বল্পস্থায়ী কুকি রিফ্রেশ পরিচালনা করবেন। প্রতিটি পদক্ষেপ আপনার বিদ্যমান অবকাঠামোর সাথে মসৃণভাবে সংহত করার জন্য ডিজাইন করা হয়েছে।

বাস্তবায়নের ধাপগুলি DBSC সক্রিয় থাকাকালীন একজন সাইন-ইন করা ব্যবহারকারীর অভিজ্ঞতার সাধারণ প্রবাহ অনুসরণ করে: লগইনে নিবন্ধন, তারপরে নিয়মিত স্বল্পস্থায়ী কুকি রিফ্রেশ। আপনার অ্যাপের সেশন সংবেদনশীলতার স্তরের উপর নির্ভর করে আপনি প্রতিটি ধাপ স্বাধীনভাবে পরীক্ষা এবং বাস্তবায়ন করতে পারেন।

১. লগইন প্রবাহ পরিবর্তন করুন

ব্যবহারকারী লগ ইন করার পর, একটি দীর্ঘস্থায়ী কুকি এবং একটি Secure-Session-Registration হেডার দিয়ে প্রতিক্রিয়া জানান। উদাহরণস্বরূপ:

সফল সেশন রেজিস্ট্রেশনের পরে নিম্নলিখিত HTTP প্রতিক্রিয়া শিরোনামটি ফেরত পাঠানো হয়:

HTTP/1.1 200 OK
Secure-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 ক্ষেত্রের সাথে মেলে এবং আপনার অ্যাপ্লিকেশন জুড়ে ধারাবাহিকভাবে ব্যবহৃত হয়।

২. সেশন রেজিস্ট্রেশন এন্ডপয়েন্ট বাস্তবায়ন করুন

/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"
  }]
}

৩. রিফ্রেশ এন্ডপয়েন্ট বাস্তবায়ন করুন

যখন স্বল্পস্থায়ী কুকির মেয়াদ শেষ হয়ে যায়, তখন Chrome ব্যক্তিগত কী-এর অধিকার প্রমাণ করার জন্য একটি রিফ্রেশ ফ্লো শুরু করে। এই প্রক্রিয়ায় Chrome এবং আপনার সার্ভার উভয়ের দ্বারা সমন্বিত পদক্ষেপ জড়িত:

1. Chrome আপনার অ্যাপ্লিকেশনে ব্যবহারকারীর অনুরোধ স্থগিত করে এবং /RefreshEndpoint এ একটি রিফ্রেশ অনুরোধ পাঠায়:

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

2. আপনার সার্ভার একটি চ্যালেঞ্জের সাথে সাড়া দেয়:

   HTTP/1.1 403 Forbidden
   Secure-Session-Challenge: "challenge_value"
   

3. ক্রোম সঞ্চিত প্রাইভেট কী ব্যবহার করে চ্যালেঞ্জে স্বাক্ষর করে এবং অনুরোধটি পুনরায় চেষ্টা করে:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   Secure-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 কুকি যোগ করতে পারে। এই দীর্ঘস্থায়ী কুকিটি শুধুমাত্র নতুন স্বল্পস্থায়ী টোকেন ইস্যু করার জন্য ব্যবহৃত হয় এবং সত্যিকার অর্থে অপ্রমাণিত অনুরোধ এবং অস্থায়ী DBSC ব্যর্থতার মধ্যে পার্থক্য করতে সাহায্য করে।

• DBSC ব্যর্থ হলেও দীর্ঘস্থায়ী কুকি টিকে থাকে।
• স্বল্পস্থায়ী কুকিটি DBSC ব্যবহার করে রিফ্রেশ করা হয় এবং সংবেদনশীল ক্রিয়াকলাপের জন্য প্রয়োজনীয়।

এই প্যাটার্নটি সাইটগুলিকে এজ কেসগুলি কীভাবে পরিচালনা করতে হয় তার উপর আরও নিয়ন্ত্রণ দেয়।

সতর্কতা এবং ফলব্যাক আচরণ

নিম্নলিখিত পরিস্থিতিতে Chrome DBSC কার্যক্রম এড়িয়ে যেতে পারে এবং DBSC-পরিচালিত স্বল্পস্থায়ী কুকি ছাড়াই অনুরোধ পাঠাতে পারে:

• নেটওয়ার্ক ত্রুটি বা সার্ভার সমস্যার কারণে রিফ্রেশ এন্ডপয়েন্টটি পৌঁছানো যাচ্ছে না।
• TPM ব্যস্ত আছে অথবা সাইনিং ত্রুটির সম্মুখীন হচ্ছে। যেহেতু TPM সিস্টেম প্রক্রিয়া জুড়ে ভাগ করা হয়, তাই অতিরিক্ত রিফ্রেশ এর হার সীমা অতিক্রম করতে পারে।
• DBSC-পরিচালিত স্বল্পস্থায়ী কুকিটি একটি তৃতীয় পক্ষের কুকি, এবং ব্যবহারকারী তাদের ব্রাউজার সেটিংসে তৃতীয় পক্ষের কুকিজ ব্লক করেছেন।

এই পরিস্থিতিতে, যদি কোনও দীর্ঘস্থায়ী কুকি এখনও উপস্থিত থাকে, তাহলে Chrome পুনরায় সেই কুকি ব্যবহার করতে বাধ্য হয়। এই ফলব্যাকটি কেবল তখনই কাজ করে যদি আপনার বাস্তবায়নে দীর্ঘস্থায়ী এবং স্বল্পস্থায়ী উভয় ধরণের কুকি অন্তর্ভুক্ত থাকে। যদি না হয়, তাহলে Chrome কুকি ছাড়াই অনুরোধটি পাঠায়।

সারাংশ

ডিভাইস বাউন্ড সেশন ক্রেডেনশিয়াল আপনার অ্যাপ্লিকেশনে ন্যূনতম পরিবর্তনের মাধ্যমে সেশন নিরাপত্তা উন্নত করে। নির্দিষ্ট ডিভাইসের সাথে সেশন সংযুক্ত করে তারা সেশন হাইজ্যাকিংয়ের বিরুদ্ধে আরও শক্তিশালী সুরক্ষা প্রদান করে। বেশিরভাগ ব্যবহারকারী কোনও বাধা ছাড়াই উপকৃত হন এবং DBSC অসমর্থিত হার্ডওয়্যারের উপর সুন্দরভাবে ফিরে আসে।

আরও তথ্যের জন্য, DBSC স্পেসিফিকেশন দেখুন।