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

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

ড্যানিয়েল রুবেরি
Daniel Rubery

ভূমিকা

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

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

কিভাবে DBSC কাজ করে

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

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

বাস্তবায়ন ওভারভিউ

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

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

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

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

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

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

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

DBSC প্রবাহ দেখানো চিত্র

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

ব্যবহারকারী লগ ইন করার পরে, একটি দীর্ঘস্থায়ী কুকি এবং একটি Sec-Session-Registration শিরোনাম সহ প্রতিক্রিয়া জানান৷ যেমন:

সফল সেশন নিবন্ধনের পরে নিম্নলিখিত HTTP প্রতিক্রিয়া শিরোনামটি ফেরত দেওয়া হয়:

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. ক্রোম সঞ্চিত ব্যক্তিগত কী ব্যবহার করে চ্যালেঞ্জে স্বাক্ষর করে এবং অনুরোধটি পুনরায় চেষ্টা করে:

    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 ব্যর্থতার মধ্যে পার্থক্য করতে সাহায্য করে।

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

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

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

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

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

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

সারাংশ

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

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

,

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

ড্যানিয়েল রুবেরি
Daniel Rubery

ভূমিকা

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

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

কিভাবে DBSC কাজ করে

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

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

বাস্তবায়ন ওভারভিউ

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

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

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

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

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

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

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

DBSC প্রবাহ দেখানো চিত্র

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

ব্যবহারকারী লগ ইন করার পরে, একটি দীর্ঘস্থায়ী কুকি এবং একটি Sec-Session-Registration শিরোনাম সহ প্রতিক্রিয়া জানান৷ যেমন:

সফল সেশন নিবন্ধনের পরে নিম্নলিখিত HTTP প্রতিক্রিয়া শিরোনামটি ফেরত দেওয়া হয়:

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. ক্রোম সঞ্চিত ব্যক্তিগত কী ব্যবহার করে চ্যালেঞ্জে স্বাক্ষর করে এবং অনুরোধটি পুনরায় চেষ্টা করে:

    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 ব্যর্থতার মধ্যে পার্থক্য করতে সাহায্য করে।

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

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

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

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

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

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

সারাংশ

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

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

,

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

ড্যানিয়েল রুবেরি
Daniel Rubery

ভূমিকা

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

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

কিভাবে DBSC কাজ করে

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

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

বাস্তবায়ন ওভারভিউ

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

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

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

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

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

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

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

DBSC প্রবাহ দেখানো চিত্র

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

ব্যবহারকারী লগ ইন করার পরে, একটি দীর্ঘস্থায়ী কুকি এবং একটি Sec-Session-Registration শিরোনাম সহ প্রতিক্রিয়া জানান৷ যেমন:

সফল সেশন নিবন্ধনের পরে নিম্নলিখিত HTTP প্রতিক্রিয়া শিরোনামটি ফেরত দেওয়া হয়:

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. ক্রোম সঞ্চিত ব্যক্তিগত কী ব্যবহার করে চ্যালেঞ্জে স্বাক্ষর করে এবং অনুরোধটি পুনরায় চেষ্টা করে:

    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 ব্যর্থতার মধ্যে পার্থক্য করতে সাহায্য করে।

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

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

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

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

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

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

সারাংশ

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

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

,

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

ড্যানিয়েল রুবেরি
Daniel Rubery

ভূমিকা

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

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

কিভাবে DBSC কাজ করে

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

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

বাস্তবায়ন ওভারভিউ

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

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

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

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

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

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

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

DBSC প্রবাহ দেখানো চিত্র

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

ব্যবহারকারী লগ ইন করার পরে, একটি দীর্ঘস্থায়ী কুকি এবং একটি Sec-Session-Registration শিরোনাম সহ প্রতিক্রিয়া জানান৷ যেমন:

সফল সেশন নিবন্ধনের পরে নিম্নলিখিত HTTP প্রতিক্রিয়া শিরোনামটি ফেরত দেওয়া হয়:

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. ক্রোম সঞ্চিত ব্যক্তিগত কী ব্যবহার করে চ্যালেঞ্জে স্বাক্ষর করে এবং অনুরোধটি পুনরায় চেষ্টা করে:

    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 ব্যর্থতার মধ্যে পার্থক্য করতে সাহায্য করে।

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

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

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

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

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

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

সারাংশ

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

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