شرح Device Bound Session Credentials (DBSC)

الورقة البيضاء للمؤسسات حول Passkeys. إرشادات عملية وأنماط إطلاق ومؤشرات KPI لبرامج passkeys.

احصل على الورقة البيضاء

حالة دعم المتصفح

الأسطورة: ✅ متوفر بشكل عام | 🚧 معلن / قيد التطوير | ⏸️ انتهت التجربة | 🔄 قيد التقييم/المراقبة | ❌ غير متوفر بعد

ملاحظة: DBSC متوفر بشكل عام على نظام Windows مع TPM اعتباراً من Chrome 146 (أبريل 2026). يتم حالياً طرح دعم macOS عبر Secure Enclave. تتضمن خارطة طريق Google المعلنة أيضاً مفاتيح مستندة إلى البرامج لتوسيع الحماية للأجهزة التي لا تحتوي على أجهزة أمان مخصصة.

المزايا الرئيسية: DBSC مقابل النموذج الحالي

تأسست بنية الشبكة العالمية للمعلومات (الويب) على مبدأ انعدام الحالة (statelessness). عندما تم تصميم HTTP لأول مرة، لم يكن يحتفظ بمعلومات حول المستخدمين بين الطلبات. لحل ذلك، تم اختراع "ملف تعريف الارتباط" (cookie) - وهو جزء صغير من البيانات يتم إرساله من موقع الويب وتخزينه على كمبيوتر المستخدم، ليتم إرساله مرة أخرى إلى موقع الويب مع كل طلب لاحق. لعقود من الزمن، كانت هذه الآلية بمثابة الأساس لإدارة الجلسات. عندما يقوم المستخدم بتسجيل الدخول، يتحقق الخادم من بيانات الاعتماد الخاصة به ويصدر ملف تعريف ارتباط. يعمل ملف تعريف الارتباط هذا كـ "رمز مميز للحامل" (bearer token). في العالم المادي، أداة الحامل هي مستند يمنح حامله الحقوق أو الأصول التي يمثلها؛ إذا كنت تحمل السند، فأنت تملك السند. وبالمثل، في العالم الرقمي لبروتوكول HTTP، إذا كنت تحمل ملف تعريف الارتباط، فأنت المستخدم.

تعتبر قدرة الحامل هذه في نفس الوقت أكبر فائدة للويب وأعمق نقاط ضعفه. يعتمد أمان الجلسة بأكملها - وبالتالي هوية المستخدم وبياناته وأصوله المالية - كلياً على سرية سلسلة ملف تعريف الارتباط هذه. إذا تمكن جهة ضارة من نسخ تلك السلسلة، فيمكنها انتحال شخصية المستخدم من أي جهاز في أي مكان في العالم، متجاوزة عمليات التحقق من المصادقة الأولية تماماً. أدت هذه الثغرة الأمنية المحددة إلى ظهور اقتصاد سري على مستوى صناعي لـ "سرقة ملفات تعريف الارتباط" و "اختطاف الجلسة".

مع نجاح الصناعة في تعزيز أمان "الباب الأمامي" للمصادقة من خلال اعتماد معايير FIDO (الهوية السريعة عبر الإنترنت) ومفاتيح المرور، يحول المهاجمون تركيزهم إلى "الباب الخلفي": الجلسة النشطة. أصبح تصيد كلمة المرور أكثر صعوبة، لكن سرقة ملف تعريف ارتباط الجلسة تظل فعالة بشكل خطير. تتمثل استجابة الصناعة لهذا التهديد المتصاعد في Device Bound Session Credentials (DBSC).

يمثل DBSC تحولاً نموذجياً في كيفية الحفاظ على جلسات الويب. ويقترح الانتقال بعيداً عن الرموز المميزة البسيطة للحامل نحو نموذج تكون فيه الجلسة مرتبطة تشفيرياً بالجهاز. مع إطلاق Chrome 146 (أبريل 2026) لـ DBSC في التوفر العام على نظام Windows، انتقل المعيار من إمكانية تجريبية إلى إمكانية إنتاج يمكن لفرق الويب نشرها اليوم. يستخدم Chrome وحدات TPM على نظام Windows ويقوم بطرح دعم لـ Secure Enclave على macOS تالياً؛ والمواصفات نفسها محايدة بخصوص تخزين المفاتيح، حيث تتطلب فقط أن تكون "قوية ضد التهديد الموصوف." هذا يجعل ملفات تعريف الارتباط المسروقة أقل قيمة بكثير. لا يمكن تحديثها من جهاز آخر بدون المفتاح المرتبط.

تقدم هذه المقالة تحليلاً شاملاً لـ DBSC، مصمماً لمهندسي الأمان ومديري المنتجات والمطورين. وتستكشف البنية التقنية، والآثار التجارية لـ "الأمان بدون احتكاك"، والعلاقة مع المعايير الناشئة مثل الإشارات المشتركة (CAEP/RISC)، وكيف يمكن للمؤسسات الاستعداد لهذا المستقبل باستخدام منصات مثل Corbado.

الأسئلة الرئيسية التي تجيب عليها هذه المقالة

1. لماذا تفشل إدارة الجلسات الحالية في منع الاستيلاء على الحسابات؟
2. كيف يختلف DBSC عن ملفات تعريف الارتباط "الآمنة" (Secure) الحالية وعلامات HttpOnly؟
3. كيف يعمل DBSC ومفاتيح المرور معاً لمقاومة أقوى للتصيد الاحتيالي؟
4. ماذا حدث لربط الرمز المميز (Token Binding)، ولماذا ينجح DBSC حيث فشل؟
5. ما هي الآثار التجارية وعائد الاستثمار لمديري المنتجات؟
6. ما هي المتصفحات وأنظمة التشغيل التي تدعم DBSC اليوم؟
7. كيف يمكن للمؤسسات تنفيذ DBSC دون البناء من الصفر؟
8. ما هي العلاقة بين DBSC وDPoP وOAuth 2.0؟
9. كيف يتكامل DBSC مع الإشارات المشتركة (CAEP/RISC) للاستجابة للتهديدات في الوقت الفعلي؟

للتنقل عبر تعقيدات هذا المعيار الجديد، يجب أن نفهم أولاً المشاكل الأساسية في إدارة الجلسات الحالية وكيف يقدم DBSC حلولاً لها. يمثل كل مجال من هذه المجالات ثغرة أمنية حرجة أو قيداً يعالجه DBSC.

الفشل الأساسي لإدارة الجلسة الحالية هو "قابلية نقل" الثقة. عندما يصدر الخادم ملف تعريف ارتباط لجلسة، فإنه في الأساس يصدر جواز سفر يعمل لأي شخص يحمله. بينما قامت المتصفحات بتنفيذ دفاعات مثل علامات HttpOnly و Secure (التي تمنع وصول JavaScript وتضمن النقل عبر HTTPS)، إلا أن هذه الدفاعات تحمي فقط ضد نواقل استخراج معينة مثل البرمجة عبر المواقع (XSS) أو استنشاق الشبكة. وهي لا توفر أي حماية ضد البرامج الضارة التي تعمل على الجهاز المضيف. "سارقو المعلومات" (Infostealers) هم برامج ضارة مصممة خصيصاً لـ تحديد موقع ملف تخزين ملف تعريف الارتباط للمتصفح على القرص، وفك تشفيره (غالباً باستخدام بيانات اعتماد مستوى نظام التشغيل الخاصة بالمستخدم نفسه)، وتسريب المحتويات إلى خادم قيادة وسيطرة. بمجرد أن يمتلك المهاجم ملف تعريف الارتباط، يمكنه إجراء هجوم تمرير ملف تعريف الارتباط، عن طريق إدخال الرمز المسروق في متصفحه الخاص لاختطاف الجلسة. يفترض الخادم، عند رؤية ملف تعريف ارتباط صالح، أن الطلب شرعي.

يقدم DBSC عاملاً ثانياً للمصادقة في حلقة صيانة الجلسة نفسها. على عكس ملف تعريف الارتباط الآمن القياسي، وهو سر ثابت، تتكون جلسة DBSC من رمز مميز للحامل قصير الأجل وإثبات تشفيري للامتلاك. ينشئ المتصفح زوج مفاتيح (عام/خاص) يتم تخزينه بأمان على الجهاز. يربط الخادم الجلسة بالمفتاح العام. بشكل دوري، يجب أن يثبت المتصفح أنه لا يزال يحتفظ بالمفتاح الخاص من خلال توقيع تحدي من الخادم. تتطلب المواصفات تخزين المفاتيح بحيث تكون "قوية ضد التهديد الموصوف". يستخدم Chrome تقنية TPM على نظام Windows عند توفرها. إذا قام مهاجم بسرقة ملف تعريف الارتباط من جهاز مختلف، فلن يتمكن من تحديثه لأنه لا يستطيع إنشاء التوقيع التشفيري المطلوب. يتم تقليل جانب "الحامل" إلى نافذة قصيرة جداً، بينما يوفر جانب "الربط" استمرارية طويلة الأمد.

مفاتيح المرور و DBSC هما تقنيتان متكاملتان تؤمنان مراحل مختلفة من دورة حياة المستخدم. تحل مفاتيح المرور (FIDO2) مشكلة المصادقة من خلال إثبات الهوية لبدء جلسة بدون كلمات مرور، وبالتالي القضاء على تصيد بيانات الاعتماد. يعالج DBSC مشكلة ما بعد المصادقة مما يجعل اختطاف الجلسة عبر سرقة ملف تعريف الارتباط أصعب بكثير. يؤطر تحالف FIDO تقنية DBSC كتقنية تكميلية "ترفع المستوى" ضد اختطاف الجلسات. معاً، يقللان من سطح الهجوم عبر دورة حياة تسجيل الدخول والجلسة، على الرغم من أن DBSC لا يحمي من البرامج الضارة ذات الوصول المستمر للجهاز أو هجمات الرجل في المتصفح في الوقت الفعلي على نفس الجهاز.

كيف تعمل مفاتيح المرور و DBSC معاً

ليست DBSC هي المحاولة الأولى لحل هذه المشكلة. كان "Token Binding" (ربط الرمز المميز) معياراً سابقاً حاول ربط ملفات تعريف الارتباط باتصال TLS (أمان طبقة النقل) الأساسي. بينما كان سليماً من الناحية التشفيرية، فشل Token Binding في كسب التبني بسبب اعتماده الكبير على طبقة TLS. في الويب الحديث، غالباً ما يتم إنهاء اتصالات TLS في موازنات الأحمال أو شبكات CDN أو الوكلاء العكسيين، بينما يقع منطق التطبيق في الخوادم خلفها. ثبت أن نشر معلومات Token Binding عبر طبقات الشبكة المعقدة هذه كان صعباً للغاية. يتعلم DBSC من هذا الفشل عن طريق العمل بالكامل في طبقة التطبيق (HTTP). لا يعتمد على اتصال الشبكة الأساسي، مما يجعله متوافقاً مع موازنات الأحمال والوكلاء والبنية التحتية السحابية الحالية.

بالنسبة لقادة المنتجات، يوفر DBSC فرصة لتحسين الأمان مع تحسين تجربة المستخدم (UX) في نفس الوقت. تقليدياً، يعني الأمان العالي انتهاء صلاحية الجلسة لفترات قصيرة، مما يجبر المستخدمين على تسجيل الدخول بشكل متكرر (احتكاك). من خلال ربط الجلسة بالجهاز، يتم تقليل خطر سرقة ملف تعريف الارتباط عن بُعد بشكل كبير. يمكن للشركات التفكير في فترات جلسة أطول، مع العلم أن ملفات تعريف الارتباط المسروقة لا يمكن تحديثها من جهاز آخر. ومع ذلك، لا تحمي DBSC من سرقة الجهاز أو البرامج الضارة المستمرة على الجهاز أو الإساءة من قبل مستخدم ضار، لذلك يجب أن تعكس سياسات عمر الجلسة هذه المخاطر المتبقية.

لفهم الحاجة الملحة وراء DBSC، يجب على المرء أن يدرك مدى تعقيد مشهد التهديد الحديث. تخرجت سرقة ملفات تعريف ارتباط الجلسات من خدعة قراصنة متخصصة إلى صناعة قابلة للتطوير ومؤتمتة.

graph TD
    A[المستخدم ينزل<br/>برمجيات خبيثة] -->|تنفيذ| B[تنشيط برنامج سرقة المعلومات<br/>على الجهاز]
    B --> C[يحدد موقع بيانات المتصفح]
    C --> D[تخزين ملفات تعريف الارتباط<br/>لـ Chrome/Edge/Firefox]
    C --> E[قاعدة بيانات كلمات المرور]
    C --> F[محافظ التشفير]

    D --> G[يفك التشفير باستخدام<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) إلى خفض حاجز الدخول لمجرمي الإنترنت. "سارقو المعلومات" (Infostealers) مثل RedLine و Raccoon و Vidar و Taurus هي سلالات برامج ضارة متاحة تجارياً مصممة بهدف أساسي واحد: استخراج البيانات من متصفحات الويب. يتم توزيع أدوات السرقة هذه عبر رسائل التصيد الاحتيالي، أو البرامج المقرصنة، أو الإعلانات الضارة. بمجرد تثبيتها، فإنها تستهدف مسارات الملفات المحددة حيث تخزن متصفحات مثل Chrome وEdge وFirefox بياناتها.

• الهدف: قاعدة بيانات ملفات تعريف الارتباط (عادةً ملف SQLite) وقاعدة بيانات بيانات تسجيل الدخول (كلمات المرور المحفوظة).
• الآلية: تقوم المتصفحات بتشفير قواعد البيانات هذه باستخدام واجهات برمجة تطبيقات حماية البيانات (DPAPI على Windows) المرتبطة بتسجيل دخول المستخدم لنظام التشغيل. نظراً لأن البرامج الضارة تعمل بصفة المستخدم، يمكنها بسهولة طلب فك تشفير هذه الملفات.
• المخرجات: تولد البرامج الضارة "سجلاً" (log) - وهو ملف مضغوط يحتوي على ملفات تعريف الارتباط التي تم فك تشفيرها، وكلمات المرور، ومعلومات النظام، وأحياناً مفاتيح محافظ التشفير.

يتم تجميع هذه السجلات وبيعها في الأسواق على الويب المظلم مثل سوق التكوين (Genesis Market) (قبل إغلاقه) والسوق الروسية (Russian Market). يمكن للمشترين البحث عن سجلات تحتوي على ملفات تعريف ارتباط نشطة لأهداف عالية القيمة محددة: "Salesforce" أو "Gmail" أو "Bank of America" أو "AWS Console".

التجاوز: تكمن قيمة سجل ملف تعريف الارتباط في قدرته على تجاوز المصادقة متعددة العوامل (MFA). تحدث معظم تحديات MFA (الرسائل القصيرة، TOTP، الإشعارات المباشرة) فقط أثناء حدث تسجيل الدخول. بمجرد إنشاء الجلسة وإصدار ملف تعريف الارتباط، يفترض الخادم أن المستخدم موثوق به. إن إدخال المهاجم لملف تعريف ارتباط صالح للجلسة ينزلق مباشرة عبر بوابة MFA، ويظهر للخادم كالمستخدم الذي يعود إلى علامة تبويب نشطة.

تعتبر حزم الإنتاجية السحابية أهدافاً رئيسية. يمكن أن يمنح ملف تعريف ارتباط جلسة مسروق لـ Google Workspace أو حساب Microsoft Entra ID (المعروف سابقاً باسم Azure AD) المهاجم إمكانية الوصول إلى البريد الإلكتروني للشركة والمستندات والأنظمة الداخلية. أبلغت معلومات التهديدات الخاصة بشركة Google عن زيادة هائلة في سرقة ملفات تعريف الارتباط كناقل أساسي للوصول إلى حسابات Google، حيث سمته صراحةً كمحرك لاستثمارها في DBSC. ويشيرون إلى أنه عندما يفرضون تمكين التحقق بخطوتين (2SV) ومفاتيح المرور، فقد غيّر المهاجمون تكتيكاتهم ببساطة من تصيد بيانات الاعتماد (والذي يوقفه 2SV / مفاتيح المرور) إلى سرقة ملفات تعريف الارتباط (والتي لا يوقفها 2SV / مفاتيح المرور في الغالب).

تاريخياً، حاولت محركات المخاطر اكتشاف سرقة الجلسات من خلال تحليل البصمات الرقمية للجهاز، والنظر إلى سلسلة وكيل المستخدم (User-Agent)، ودقة الشاشة، والخطوط المثبتة، وعنوان IP. إذا ظهر ملف تعريف ارتباط جلسة فجأة من عنوان IP جديد ببصمة مختلفة قليلاً، فقد يقوم الخادم بإبطاله. المشكلة: تعمل مبادرات الخصوصية في المتصفحات (مثل منع التتبع الذكي في Safari وPrivacy Sandbox في Chrome) بنشاط على تقليل إنتروبيا هذه البصمات لـ وقف تتبع الإعلانات. هذا يجعل أخذ البصمات "الجيدة" لأغراض الأمان صعباً بشكل متزايد. علاوة على ذلك، يستخدم المهاجمون الآن متصفحات "مضادة للاكتشاف" تتيح لهم تزييف هذه البصمات بشكل مثالي لتتطابق مع الملف الشخصي للضحية، مما يجعل الكشف الإرشادي غير فعال. يستبدل DBSC لعبة التخمين الاحتمالية هذه بإثبات تشفيري حتمي.

يقدم Device Bound Session Credentials (DBSC) واجهة برمجة تطبيقات وبروتوكول قياسي لإنشاء جلسات مرتبطة بمفتاح على جهاز العميل. تتطلب المواصفة أن يكون تخزين المفاتيح "قوياً ضد التهديد الموصوف" لكنها غير محددة بشأن التنفيذ. يستخدم Chrome تقنية TPM على Windows عند توفرها. يفصل هذا القسم الآليات كما هو محدد في مسودة عمل W3C ووثائق Chrome.

تسمح دورة حياة DBSC بانتقال سلس من جلسة قياسية إلى جلسة مرتبطة، مما يضمن التوافق مع الإصدارات السابقة والتحسين التدريجي.

sequenceDiagram
    participant User
    participant Browser
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server

    Note over User,Server: المرحلة 1: المصادقة والربط
    User->>Browser: تسجيل الدخول ببيانات الاعتماد/مفتاح المرور
    Browser->>Server: طلب المصادقة
    Server->>Browser: نجاح + ترويسة تسجيل DBSC
    Browser->>HSM: إنشاء زوج مفاتيح
    HSM->>Browser: مفتاح عام/خاص (خاص غير قابل للتصدير)
    Browser->>Server: تسجيل المفتاح العام (JWT موقع)
    Server->>Server: ربط الجلسة بالمفتاح العام
    Server->>Browser: ملف تعريف ارتباط قصير الأجل (5 دقائق)

    Note over User,Server: المرحلة 2: الاستخدام العادي
    loop كل طلب خلال 5 دقائق
        Browser->>Server: طلب بملف تعريف الارتباط
        Server->>Browser: استجابة
    end

    Note over User,Server: المرحلة 3: التحديث (بعد انتهاء الصلاحية)
    Browser->>Server: طلب بملف تعريف ارتباط منتهي الصلاحية
    Server->>Browser: 401 + رقم تحدي
    Browser->>HSM: توقيع التحدي
    HSM->>Browser: توقيع
    Browser->>Server: إثبات التوقيع
    Server->>Server: تحقق باستخدام المفتاح العام المخزن
    Server->>Browser: ملف تعريف ارتباط قصير الأجل جديد
    Browser->>Server: إعادة محاولة الطلب الأصلي
    Server->>Browser: استجابة بالنجاح

تبدأ عملية الربط فور مصادقة المستخدم باستخدام طرق قياسية (كلمة المرور، مفتاح المرور، وما إلى ذلك).

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. إنشاء المفتاح: يحلل المتصفح هذه الترويسة. ويولد زوج مفاتيح غير متماثل جديد (مثل، Elliptic Curve P-256)، مخزناً بأمان على الجهاز.

   • ملاحظة التنفيذ: يستخدم Chrome تقنية TPM على نظام Windows عند توفرها؛ المواصفة محايدة بخصوص آلية التخزين، وتتطلب فقط أن تكون "قوية ضد التهديد الموصوف."
   • نطاق الخصوصية: يتم تحديد نطاق المفتاح لأصل الويب (مثل bank.com). يضمن المتصفح عدم استخدام هذا المفتاح مطلقاً لـ retailer.com، مما يمنع التتبع عبر المواقع.

3. طلب التسجيل: يرسل المتصفح طلباً إلى مسار التسجيل المحدد. يتضمن هذا الطلب المفتاح العام المولد حديثاً داخل JSON Web Token (JWT)، موقعاً بواسطة المفتاح الخاص (تصديق موقع ذاتياً).

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

4. ربط الجلسة: يتحقق الخادم من التوقيع للتأكد من أن المفتاح العام يعمل. ثم يقوم بتحديث قاعدة البيانات الخاصة به لربط جلسة المستخدم (session_id=xyz123) بهذا المفتاح العام المحدد. من هذه اللحظة فصاعداً، تصبح الجلسة "مرتبطة".

لتحقيق التوازن بين الأمان والأداء (يمكن أن تضيف عمليات المفاتيح الآمنة زمن انتقال)، يستخدم DBSC نظاماً مزدوج الرموز.

1. الإصدار: يصدر الخادم ملف تعريف ارتباط جديد، قصير الأجل (على سبيل المثال، صالح لمدة 5 دقائق). لنطلق على هذا access_token.
2. الاستخدام: يستخدم المتصفح هذا الـ access_token لجميع الطلبات العادية (جلب الصور، مكالمات API، التنقل بين الصفحات). طالما كان ملف تعريف الارتباط صالحاً، لا يتم تنفيذ أي عمليات تشفيرية. يضمن هذا بقاء التصفح سريعاً.
3. انتهاء الصلاحية: بعد 5 دقائق، تنتهي صلاحية access_token.

هذا هو قلب الآلية الأمنية. عندما تنتهي صلاحية ملف تعريف الارتباط قصير الأجل، يتم منع مهاجم على جهاز مختلف، ولكن يمكن للمستخدم الشرعي (الذي لديه حق الوصول إلى المفتاح المرتبط) الاستمرار.

1. الاكتشاف: يحاول المتصفح إجراء طلب. يلاحظ أن ملف تعريف الارتباط قد انتهت صلاحيته (أو أن الخادم يرجع 401 أو ترويسة Secure-Session-Challenge محددة).
2. الاعتراض: يقوم المتصفح بإيقاف طلب الشبكة مؤقتاً. ولا يظهر أي خطأ للمستخدم.
3. طلب التحديث: يستدعي المتصفح نقطة نهاية التحديث المحددة في تكوين الجلسة تلقائياً.
   • يرسل الخادم تحدي تشفيري (رقم عشوائي nonce).
   • يستخدم المتصفح المفتاح المرتبط لتوقيع هذا التحدي.
   • يثبت التوقيع امتلاك المفتاح الخاص.
4. التقديم: يرسل المتصفح التحدي الموقع مرة أخرى إلى الخادم.

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

5. التحقق من الصحة: يستخدم الخادم المفتاح العام المخزن للتحقق من التوقيع.
   • إذا كان صالحاً: يعرف الخادم أن الطلب قادم من نفس الجهاز المادي الذي بدأ الجلسة. ويصدر access_token قصير الأجل جديد (صالح لمدة 5 دقائق أخرى).
   • إذا كان غير صالح: يتم رفض الطلب. ويتم إنهاء الجلسة.
6. الاستئناف: يأخذ المتصفح ملف تعريف الارتباط الجديد ويعيد محاولة الطلب الأصلي المتوقف مؤقتاً بشفافية. الـ مستخدم لا يعاني من أي انقطاع.

graph LR
    subgraph "جهاز الضحية"
        A[جلسة المستخدم<br/>مع DBSC]
        B[المفتاح الخاص لـ<br/>HSM/TPM]
        C[ملف تعريف الارتباط +<br/>معرف الجلسة]
        A --> B
        A --> C
        B -.->|غير قابل للتصدير| X[لا يمكن استخراج<br/>المفتاح الخاص]
    end

    subgraph "سيناريو الهجوم"
        D[برنامج RedLine Stealer<br/>يصيب الجهاز]
        D --> E[يسرق ملف تعريف الارتباط<br/>ومعرف الجلسة]
        E --> F[يصدر إلى<br/>المهاجم]
    end

    subgraph "جهاز المهاجم"
        G[يستورد ملف تعريف<br/>الارتباط المسروق]
        H[يحاول<br/>استخدام الجلسة]
        I[يطلب الخادم<br/>تحديث DBSC]
        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

تخيل مهاجماً أصاب جهاز الكمبيوتر الخاص بالمستخدم ببرنامج RedLine Stealer. يسرق access_token و session_id. ويقوم باستيرادها إلى متصفحه الخاص.

• السيناريو أ (خلال 5 دقائق): قد يحصل المهاجم على وصول لبضع دقائق حتى تنتهي صلاحية الرمز المميز قصير الأجل.
• السيناريو ب (بعد انتهاء الصلاحية): يحاول متصفح المهاجم (على جهاز مختلف) استخدام الرمز المميز. يرفضه الخادم ويطالب بتحديثه. يرى متصفح المهاجم ترويسات DBSC ولكنه لا يستطيع إجراء التحديث لأنه لا يمتلك المفتاح الخاص المرتبط. يفشل الهجوم.

الخصوصية هي هدف تصميمي مركزي لـ DBSC. الـ مواصفات W3C تحظر صراحة استخدام المعرفات العالمية التي قد تتتبع المستخدمين عبر المواقع.

• مفاتيح لكل أصل: يقوم المتصفح بإنشاء زوج مفاتيح فريد لكل موقع. يرى google.com المفتاح A؛ ويرى amazon.com المفتاح B. لا يوجد أي ارتباط بينهما.
• مسح بيانات المستخدم: إذا قام المستخدم بمسح ملفات تعريف الارتباط/بيانات الموقع، يقوم المتصفح أيضاً بحذف مفاتيح DBSC المرتبطة. وهذا يضمن عدم إمكانية استخدام DBSC كـ "ملف تعريف ارتباط فائق" (super-cookie) لـ إحياء الهويات المحذوفة.

يتطلب تنفيذ DBSC من الخادم الحفاظ على حالة حول المفاتيح العامة.

• مخطط قاعدة البيانات: يجب تحديث جدول الجلسات لتخزين public_key و last_challenge بجانب user_id و session_expiry.
• الأداء: تتضمن عملية التحديث تحققاً تشفيرياً (مثل التحقق من توقيع ECDSA). رغم سرعتها، إلا أنها تستهلك وحدة المعالجة المركزية (CPU) أكثر من التحقق من سلسلة بسيطة. ومع ذلك، نظراً لأن عمليات التحديث تحدث فقط كل بضع دقائق (وليس في كل طلب)، فإن العبء يكون ضئيلاً.

بالإضافة إلى المواصفات التقنية، يحمل DBSC آثاراً مهمة لاستراتيجية الأعمال، وخرائط طريق المنتجات، ومواقف الامتثال.

غالباً ما يُنظر إلى المبادرات الأمنية على أنها مراكز تكلفة أو مولدات احتكاك. يقلب DBSC هذه السردية. يوضح الرسم البياني التالي كيف يخلق ربط الجهاز سلسلة من الفوائد التجارية:

• تقليل الاحتيال: من خلال إبطال ناقل الاستيلاء على الحساب (ATO) الأساسي، يمكن للشركات توفير ملايين الدولارات في خسائر الاحتيال.
• تكاليف الدعم: استرداد الحسابات مكلف. يؤدي منع الاختراق في المقام الأول إلى تقليل هذا العبء التشغيلي بشكل مباشر.
• تحسين التحويل: في التجارة الإلكترونية، تمثل كل مطالبة تسجيل دخول نقطة تسرب محتملة. يسمح DBSC بسياسات قوية لـ "إبقائي مسجل الدخول"، مما يمكّن من الدفع الفوري دون مطالبات بكلمات المرور.

تتطلب الأطر التنظيمية مثل القانون العام لحماية البيانات (GDPR) في أوروبا من المؤسسات تنفيذ "تدابير فنية وتنظيمية مناسبة" لضمان الأمان.

• أمان يمكن الدفاع عنه: مع تحول DBSC إلى معيار، من المرجح أن يُفسر على أنه "أحدث ما توصلت إليه التكنولوجيا" لإدارة الجلسات. في حالة حدوث خرق، فإن إثبات تنفيذ DBSC يمكن أن يكون دفاعاً قوياً ضد ادعاءات الإهمال.
• المعايير المصرفية (PSD2): يتطلب التوجيه الخاص بخدمات الدفع 2 "مصادقة قوية للعملاء" (SCA). بينما يركز SCA على تسجيل الدخول، فإن الربط الديناميكي للجلسة بالجهاز يتماشى تماماً مع أهداف التوجيه المتمثلة في ربط المصادقة بمبالغ ومدفوع لأمرهم محددين.

تسلط تقارير تحالف FIDO الضوء على مفهوم "مستويات الضمان".

• ضمان متوسط: يستخدم مفاتيح مرور متزامنة (مثل تلك الموجودة في iCloud Keychain). رائع لتطبيقات المستهلكين، قابل للاسترداد، سهل الاستخدام.
• ضمان عالي: يتطلب مفاتيح مرتبطة بالجهاز. هذا هو المكان الذي يتألق فيه DBSC. بالنسبة للموارد المؤسسية (بوابات الموارد البشرية، مستودعات الأكواد) أو الخدمات المصرفية عالية القيمة، قد تفرض المؤسسة سياسة تسمح فقط بالوصول من جلسات مرتبطة بجهاز مُدار محدد. يوفر DBSC آلية الإنفاذ الفني لهذه السياسة.

لتقدير DBSC بشكل كامل، يجب أن نقارنها مع تقنيات أخرى حاولت حل مشاكل مشابهة.

graph RL
    subgraph "ملفات تعريف الارتباط التقليدية"
        TC1[رمز حامل فقط]
        TC2[عرضة للسرقة]
        TC3[جلسات طويلة = مخاطر]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "ربط الرمز المميز Token Binding"
        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/موازنات الأحمال]
        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

كما ذكرنا، حاول Token Binding ربط الجلسة بطبقة TLS.

• ربط الرمز المميز: تطلب دعماً من العميل، والخادم، و كل قفزة بينهما (موازنات الأحمال، أجهزة إنهاء TLS). وكان ينكسر عندما يتم إنهاء الاتصال و إعادة تشفيره.
• DBSC: يعمل في طبقة تطبيق HTTP. وهو يمر عبر موازنات الأحمال بشفافية كترويسات/ملفات تعريف ارتباط قياسية. ومن الأسهل بكثير نشره في البنى السحابية الحديثة (AWS/GCP/Azure) حيث يتم التعامل مع TLS غالباً بواسطة شبكة الحافة لمزود السحابة.

DPoP (RFC 9449) هو معيار الرموز المميزة لـ OAuth "المقيدة بالمرسل". يربط كلاً من رموز الوصول و رموز التحديث بمفتاح عام—وهو أمر بالغ الأهمية لأن رموز التحديث هي في حد ذاتها بيانات اعتماد حامل طويلة الأجل. يتضمن كل طلب API إثبات DPoP: JWT موقع بطريقة HTTP وعنوان URL وطابع زمني ومعرف فريد. تفرض مواصفات الضمان العالي مثل FAPI 2.0 رموزاً مقيدة بالمرسل؛ وDPoP هي الطريقة الموصى بها عندما لا يكون mTLS متاحاً.

الفرق الرئيسي: تعيش مفاتيح DPoP في سياق التطبيق. أفضل الممارسات هي استخدام واجهات برمجة تطبيقات نظام التشغيل للتخزين غير القابل للاستخراج، ولكن هذا غير مفروض—حيث تحتفظ العديد من التطبيقات بالمفاتيح في ذاكرة يمكن الوصول إليها عبر JavaScript. إذا تمكن مهاجم من تنفيذ تعليمات برمجية عشوائية (XSS، برامج ضارة)، فيمكنه الوصول إلى مفاتيح DPoP أو إنشاء أدلة عند الطلب. يوقف DPoP إعادة تشغيل الرموز المميزة بين عملاء مختلفين، ولكنه لا يمكنه حماية سياق متصفح مخترق.

ينقل DBSC إثبات الحيازة إلى المتصفح والأجهزة. يعيش المفتاح الخاص في TPM أو معزل آمن (Secure Enclave) لا يمكن لـ JavaScript قراءته أو تصديره. يتعامل المتصفح مع البروتوكول وينتج توقيعات دون تعريض المفاتيح لرمز التطبيق. حتى لو تم اختراق تطبيق الويب بالكامل، لا يمكن للمهاجم صياغة أدلة جديدة لملفات تعريف الارتباط المسروقة على جهاز آخر.

التآزر: كما يشير تحالف FIDO، تقضي مفاتيح المرور على التصيد الاحتيالي عند تسجيل الدخول، بينما تحمي DBSC/DPoP الرموز المميزة لما بعد المصادقة. تجمع بنية حديثة بينهما: DPoP لواجهات برمجة تطبيقات OAuth (خاصةً الخدمات المصرفية المفتوحة الخاضعة للتنظيم)، وDBSC لجلسات المتصفح. وهما معاً يغلقان ناقل الهجوم "الرفع والتحويل" (lift and shift) عبر كامل دورة حياة الجلسة.

يؤدي تقصير فترات صلاحية ملفات تعريف الارتباط (مثلاً، إلى 15 دقيقة) إلى تحسين الأمان ولكنه يدمر تجربة المستخدم. يُجبر المستخدمون على تسجيل الدخول باستمرار. يسمح DBSC بـ فعالية أمان ملف تعريف ارتباط لمدة 5 دقائق مع تجربة مستخدم لمدة 30 يوماً.

%%{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)، تحديداً ملف تعريف التقييم المستمر للوصول (CAEP) و إدارة المخاطر (RISC). ملاحظة: إن SSF/CAEP هي إمكانية نظام بيئي ناشئة—تم تحديد النمط المعماري، لكن النشر واسع النطاق عبر البائعين لا يزال في مرحلة النضج.

في النموذج القديم، إذا تم اختراق جهاز مستخدم، لم يكن لدى موفر الهوية (IdP) طريقة لإخبار موفر الخدمة (SP) بقتل الجلسة على الفور. كان على موفر الخدمة الانتظار حتى تنتهي صلاحية ملف تعريف الارتباط.

تدفق DBSC + CAEP المتصور:

1. المحفز: تكتشف أداة أمان نقطة النهاية (مثل CrowdStrike أو Microsoft Defender) برامج ضارة على كمبيوتر المستخدم المحمول.
2. الإشارة: ترسل أداة الأمان إشارة RISC إلى موفر الهوية (مثل Okta/Google).
3. الانتشار: يدفع IdP حدث CAEP إلى التطبيقات المتصلة: "جهاز مخترق."
4. التنفيذ (DBSC): في المرة القادمة التي يحاول فيها المتصفح تحديث ملف تعريف ارتباط DBSC قصير الأجل، يرفض الخادم التوقيع ويقتل الجلسة. يتيح هذا النمط المعماري إبطالاً أسرع—يعتمد زمن الانتقال الفعلي على فترة التحديث الخاصة بالموقع وما إذا كانوا قد نفذوا كلاً من DBSC و SSF.

يعتمد اعتماد DBSC على بائعي المتصفحات. لقد تغير المشهد في عام 2026 مادياً: نقل Chrome ميزة DBSC من التجربة الأصلية (Origin Trial) إلى التوفر العام على Windows في أبريل 2026، وسيأتي macOS بعد ذلك. ولا تزال المتصفحات الأخرى في مرحلة التقييم.

تعد Google هي المحرك الرئيسي لـ DBSC وأول متصفح يقوم بشحنه على نطاق واسع.

• الحالة (أبريل 2026): يطلق Chrome 146 ميزة DBSC في التوفر العام على نظام Windows، لتنتهي مرحلة Origin Trial. تم الإعلان عن دعم macOS، باستخدام Secure Enclave، في إصدار قادم لـ Chrome.
• الأجهزة: يستخدم Windows نظام TPM، وسيستخدم macOS نظام Secure Enclave. وصرحت Google بأنها تستكشف أيضاً مفاتيح مستندة إلى البرامج لتوسيع حماية DBSC للأجهزة التي لا تحتوي على أجهزة أمان مخصصة.
• خارطة الطريق: نشر إعلان التوفر العام من Google أيضاً خارطة الطريق للخطوة التالية:
  • تأمين الهوية الموحدة: ارتباطات DBSC عبر الأصول بحيث تظل جلسة الطرف المعتمد (RP) مرتبطة بنفس مفتاح الجهاز مثل جلسة موفر الهوية (IdP)، مع الحفاظ على سلسلة ثقة غير منقطعة عبر SSO.
  • التسجيل المتقدم: ربط جلسات DBSC بمواد رئيسية موثوقة موجودة مسبقاً مثل شهادات mTLS أو مفاتيح الأمان للأجهزة، بدلاً من إنشاء مفتاح جديد عند تسجيل الدخول.
  • دعم أوسع للأجهزة: مفاتيح مستندة إلى البرامج للأجهزة بدون TPM / Secure Enclave.
• النتائج التشغيلية: أثناء الطرح، أبلغت Google عن "انخفاض كبير في سرقة الجلسات" للجلسات المحمية بواسطة DBSC.
• حسابات Google: بشكل منفصل، كانت Google قد طرحت بالفعل حماية بنمط DBSC لـ ملفات تعريف ارتباط حساب Google على متصفح Chrome لنظام التشغيل Windows، والتي يتم التحكم فيها عبر سياسة المؤسسة. يحمي هذا Gmail/Workspace وهو الآن جزء من نفس عائلة التكنولوجيا التي تتوفر بشكل عام للويب العام.

تشارك Microsoft بنشاط.

• الحالة: أجرى Edge تجربة أصلية لـ DBSC على نظام Windows انتهت في أكتوبر 2025. ولم يتم الإعلان عن تجربة بديلة أو توفر عام.
• سياق المؤسسة: يستخدم Edge بنية "رمز التحديث الأساسي" (PRT) للدخول الموحد (SSO) الخاص بـ Entra/Azure AD، والتي تشبه مفاهيمياً DBSC. تظل PRT آلية خاصة بـ Microsoft؛ لا توجد خطة معلنة لتوحيدها مع معيار الويب DBSC لمواقع الطرف الثالث.

موقف Apple أمر بالغ الأهمية لتغطية الهواتف المحمولة.

• الحالة: لدى WebKit مشكلة موقف المعايير لتقييم DBSC مع مخاوف ملحوظة تتعلق بقابلية الاستخدام/الخصوصية. لا تذكر ملاحظات إصدار Safari تقنية DBSC. ولا يوجد بيان عام "ينفذ بنشاط".
• الخصوصية أولاً: القلق الرئيسي لشركة Apple هو إمكانية استخدام DBSC لإنشاء "ملفات تعريف ارتباط فائقة" (super-cookies) (تتبع لا يمكن حذفه). تتناول مواصفات W3C ذلك من خلال ضمان مسح المفاتيح ببيانات الموقع.
• المشاركة: يشارك WebKit في العملية القياسية، لكن حالة التنفيذ غير واضحة — "قيد المناقشة" بدلاً من "قيد التطوير."

لدى Mozilla مشكلة موقف المعايير لتقييم DBSC مع مخاوف ملحوظة حول التعقيد والخصوصية. لا يوجد التزام عام بالتنفيذ بمجرد استقرار المعيار.

نظراً لدعم النظام البيئي الحالي لـ DBSC ومفاتيح المرور، يجب على المؤسسات اتخاذ نهج مرحلي لتنفيذ هذه التقنيات التكميلية. تحدد خارطة الطريق أدناه الإجراءات الفورية والمعالم الاستراتيجية للتخطيط:

1. نشر مفاتيح المرور أولاً: ابدأ بتنفيذ مفتاح المرور لتأمين طبقة المصادقة. يوفر هذا حماية فورية ضد التصيد الاحتيالي لبيانات الاعتماد وهو المتطلب الأساسي للحصول على قيمة حقيقية من DBSC.

2. إطلاق نقاط نهاية تسجيل وتحديث DBSC: مع توفر Chrome 146 العام، أصبح العمل الواقعي الآن هو تكامل الواجهة الخلفية (backend): أضف ترويسات Secure-Session-Registration على استجابات تسجيل الدخول ونفذ /dbsc/register بالإضافة إلى نقطة نهاية تحديث تتحقق من التحديات الموقعة. لا يحتاج كود الواجهة الأمامية (front-end) إلى التغيير.

3. تنفيذ جلسات قصيرة الأجل باستخدام رموز التحديث: إذا لم تكن مستعداً بعد لـ DBSC، فاعتمد النمط المعماري للرموز قصيرة الأجل باستخدام آليات التحديث. يُعد هذا واجهتك الخلفية لـ DBSC مع تحسين الأمان اليوم.

1. اعتماد نهج هجين: استخدم ميزة الاكتشاف لتقديم DBSC للمتصفحات القادرة (حالياً Chrome 146+ على Windows، وmacOS Secure Enclave لاحقاً) مع الحفاظ على خيارات الرجوع. يؤدي هذا إلى تعظيم الأمان دون استبعاد المستخدمين على Safari أو Firefox أو Edge.

2. التحضير لعناصر خارطة الطريق التالية: أشارت Google صراحةً إلى الهوية الموحدة (ارتباطات SSO عبر الأصول)، والتسجيل المتقدم (mTLS / مفاتيح الأجهزة) والمفاتيح المستندة إلى البرامج لتغطية أوسع للأجهزة. إذا كنت تدير طبقة SSO أو IdP، فابدأ في التخطيط للربط عبر الأصول الآن.

3. التكامل مع موفري الهوية: إذا كنت تستخدم Okta أو Auth0 أو مزودي IdPs مشابهين، فاعمل معهم لتمكين دعم DBSC في حزم تطوير البرمجيات (SDKs) الخاصة بهم. شارك العديد منهم في التجارب الأصلية ويقومون الآن بشحن قدرات DBSC بنشاط بعد توفر Chrome بشكل عام.

• البدء بالأهداف ذات القيمة العالية: إعطاء الأولوية لـ DBSC للوحات الإدارة، والمعاملات المالية، والوصول إلى البيانات الحساسة.
• استخدام الحلول المدارة: فكر في الأنظمة الأساسية مثل Corbado التي تتعامل مع تعقيد تنفيذ DBSC وتوافق المتصفحات.
• القياس والتكرار: تتبع المقاييس مثل محاولات اختطاف الجلسات، وتذاكر الدعم، واحتكاك المستخدم لإثبات عائد الاستثمار (ROI).
• التحضير للامتثال: قم بتوثيق تنفيذ DBSC الخاص بك حيث سيصبح على الأرجح متطلباً للامتثال للتعامل مع البيانات الحساسة.

إن تنفيذ DBSC من الصفر هو عبء هندسي ثقيل. فهو يتطلب خبرة تشفيرية، ومعرفة عميقة باختلافات المتصفحات، وبنية تحتية قوية من جانب الخادم لإدارة المفاتيح والتحديات. هنا حيث تعمل منصة Corbado كأداة تمكين.

لا يمكنك بناء جلسة ذات ضمان عالٍ على قمة تسجيل دخول ذي ضمان منخفض. إذا سجل المستخدم الدخول بكلمة مرور ضعيفة، فإن الجلسة تكون آمنة فقط بقدر أمان كلمة المرور تلك. يوفر منتج Corbado الأساسي (مفاتيح المرور المدارة) هذا الأساس الضروري. من خلال دمج Corbado، يمكن للمؤسسات نشر مفاتيح المرور بسهولة، مما يضمن أن تكون بداية الجلسة مقاومة للتصيد الاحتيالي.

ستستفيد Corbado من تقنية DBSC لتعزيز الكشف عن الأجهزة الموثوقة. عندما تكون إشارات DBSC متاحة، فإنها توفر دليلاً تشفيرياً على أن الجلسة تنشأ من جهاز معين مما يسمح لـ Corbado بزيادة مستويات الثقة في المصادقة وفقاً لذلك.

• حل غموض مفتاح المرور المتزامن: مفاتيح المرور المتزامنة مريحة ولكنها تخلق فجوة في الثقة: عندما يصادق مستخدم باستخدام مفتاح مرور متزامن، لا يمكنك معرفة ما إذا كان جهازه المحمول المعتاد أو جهازاً جديداً تماماً قام بمزامنة بيانات الاعتماد للتو. يغلق DBSC هذه الفجوة. من خلال التحقق مما إذا كان الجهاز يحتوي على ربط DBSC راسخ، يمكن لـ Corbado التحقق من أن الجهاز معروف حقاً وموثوق به، وليس مجرد مزامنة لأول مرة.
• ثقة أعلى للأجهزة المعروفة: عندما تؤكد إشارات DBSC أن الجهاز قد تم رؤيته من قبل، يمكن لـ Corbado اتخاذ قرارات مخاطرة أكثر ثقة: عدد أقل من مطالبات المصادقة المتدرجة (step-up) للمستخدمين العائدين الشرعيين، وتدقيق أكثر صرامة للجلسات الصادرة من أجهزة غير مألوفة.
• استكمال ذكاء مفتاح المرور: تتكامل إشارات DBSC مع محرك Passkey Intelligence الحالي الخاص بـ Corbado. يُنشئ الجمع بين المصادقة المستندة إلى مفتاح المرور وربط الأجهزة المستند إلى DBSC سلسلة ثقة كاملة من تسجيل الدخول عبر دورة حياة الجلسة بأكملها.

للأسئلة حول كيف تخطط Corbado لدمج DBSC في نظامها الأساسي، تواصل مع الفريق.

بالنسبة للسنوات القليلة القادمة، سيكون الويب هجيناً. سيمتلك بعض المستخدمين متصفحات قادرة على DBSC (Chrome على Windows 11)؛ بينما سيكون الآخرون على أنظمة أقدم. التعامل مع هذا التجزئة أمر صعب. تم تصميم محرك Passkey Intelligence الخاص بـ Corbado للتعامل مع هذا النوع من منطق الرجوع (fallback) لتقديم مفاتيح المرور للأجهزة القادرة وبدائل للأجهزة الأخرى. ينطبق هذا الذكاء نفسه على ربط الجلسات، مما يضمن تحقيق أقصى قدر من الأمان لكل مستخدم وفقاً لإمكانيات جهازه.

يقترب عصر "الرمز المميز للحامل" (Bearer Token) من نهايته. فشلت إدارة الجلسة الحالية بشكل كارثي — حيث يمكن سرقة الرموز المميزة للحامل من خلال عمليات برامج ضارة واسعة النطاق واستخدامها من أي جهاز، مما يتيح عمليات استيلاء على الحسابات تتجاوز حتى أقوى طرق المصادقة. لقد خلقت هذه الثغرة الأساسية اقتصاداً سرياً بقيمة مليارات الدولارات.

تُمثل بيانات اعتماد الجلسة المرتبطة بالجهاز (DBSC) الإجابة الناشئة للصناعة. على عكس ملفات تعريف الارتباط الآمنة التقليدية بعلامات HttpOnly وأسرارها الثابتة، يضيف DBSC إثباتاً تشفيرياً للحيازة عبر مفاتيح مرتبطة بالجهاز. هذا يجعل ملفات تعريف الارتباط المسروقة أقل قيمة بكثير. لا يمكن تحديثها من جهاز آخر. حيث فشل Token Binding من خلال المطالبة بتغييرات معقدة في طبقة TLS عبر جميع البنى التحتية، تنجح DBSC بالعمل على طبقة تطبيق HTTP المتوافقة مع موازنات الأحمال الحالية وشبكات CDN. ملاحظة: لدى DBSC مسارات احتياطية موثقة حيث يتخطى المتصفح الربط (عند عدم توفر TPM، أخطاء في الشبكة)، لذلك فهو يقلل بشكل كبير ولكنه لا يلغي مخاطر سرقة ملفات تعريف الارتباط.

يرفع التآزر بين DBSC ومفاتيح المرور (Passkeys) مستوى الأمان أمام المهاجمين بشكل كبير عبر رحلة المستخدم. فمفاتيح المرور تقضي على التصيد الاحتيالي عند تسجيل الدخول، بينما تجعل DBSC اختطاف الجلسات عبر سرقة ملفات تعريف الارتباط عن بُعد أمراً أكثر صعوبة - ويشكلان معاً إطار الهوية عالي الضمان (high assurance) الذي يتصوره تحالف FIDO. مع طرح Chrome 146 لـ DBSC في التوفر العام على نظام Windows في أبريل 2026 ودعم macOS Secure Enclave القادم، يكون المعيار قد انتقل من مرحلة التحضير إلى مرحلة الطرح. وتُشير خارطة طريق Google (الهوية الموحدة، تسجيل mTLS / مفاتيح الأجهزة، والمفاتيح المستندة إلى البرمجيات) إلى الـ 12 شهرًا القادمة من التوسع.

بالنسبة لمديري المنتجات، تعتبر حالة العمل مقنعة: فـ DBSC تمكن جلسات آمنة "لا نهائية" تقلل بشكل كبير من احتكاك المستخدمين عند تسجيل الدخول وفي الوقت نفسه تقلل خسائر الاحتيال وتكاليف الدعم. ويتجلى العائد على الاستثمار في معدلات تحويل أعلى، وتذاكر إعادة تعيين كلمات مرور أقل، وإزالة حوادث الاستيلاء على الحسابات. بالنسبة للمنظمات التي تستخدم OAuth، فيمكنها استغلال نفس مفهوم ربط المفتاح من خلال DPoP لرموز واجهات برمجة التطبيقات (API tokens)، بينما يُمكّن التكامل مع الإشارات المشتركة (CAEP/RISC) من الاستجابة الفورية للتهديدات - إبطال الجلسات المخترقة فوراً عند محاولة التحديث التالية.

التنفيذ لا يتطلب البدء من الصفر. توفر المنصات مثل Corbado البنية التحتية لمفاتيح المرور، وتتابع التطورات في DBSC لدمج ربط الأجهزة مع نضوج دعم المتصفحات. يُعد معيار W3C مسودة عمل نشطة، و Chrome 146 متاح للعامة على نظام Windows وجاري توفيره على نظام macOS، ولا تزال المتصفحات الأخرى في مرحلة تقييم المعيار.

المسار المستقبلي واضح: المنظمات التي تبدأ باعتماد مفاتيح المرور و DBSC اليوم ستكون في الوضع الأفضل للمستقبل الخالي من كلمات المرور والمقاوم للتصيد الاحتيالي. السؤال لا يتعلق بما إذا كنت ستُطبّق جلسات مرتبطة بالجهاز، بل بمدى السرعة التي يمكنك بها نشرها لحماية مستخدميك وعملك. إن مستقبل أمان الويب لن يكون مصادقاً فقط؛ بل سيكون مرتبطاً تشفيرياً بالأجهزة التي نثق بها.

حول Corbado

Corbado هي Passkey Intelligence Platform لفِرَق CIAM التي تُدير المصادقة الاستهلاكية على نطاق واسع. نُمكّنك من رؤية ما لا تستطيع سجلات IDP وأدوات التحليل العامة إظهاره: أي الأجهزة وإصدارات أنظمة التشغيل والمتصفحات ومديري بيانات الاعتماد تدعم passkeys، ولماذا لا تتحوّل عمليات التسجيل إلى عمليات دخول، وأين يفشل تدفق WebAuthn، ومتى يُعطّل تحديث نظام التشغيل أو المتصفح تسجيل الدخول بصمت — كل ذلك دون استبدال Okta أو Auth0 أو Ping أو Cognito أو IDP الداخلي لديك. منتجان: Corbado Observe يُضيف observability للـ passkeys وأي طريقة دخول أخرى. Corbado Connect يُقدّم managed passkeys مع تحليلات مدمجة (إلى جانب IDP الخاص بك). تُشغّل VicRoads passkeys لأكثر من 5 ملايين مستخدم مع Corbado (تفعيل passkey بنسبة +80%). تحدث مع خبير Passkey →

عندما تكتشف أدوات أمان نقاط النهاية مثل CrowdStrike وجود برامج ضارة، فإنها ترسل إشارة RISC إلى مزود الهوية (Identity Provider)، والذي يرسل حدث 'جهاز مخترق' (Device Compromised) من نوع CAEP إلى التطبيقات المتصلة. عند محاولة التحديث التالية لـ DBSC (في غضون دقائق)، ترفض تلك التطبيقات توقيع الجلسة وتقطع الوصول. ولا يزال النشر المشترك عبر مورّدي CAEP/RISC في مرحلة النضوج.

تقوم DPoP (RFC 9449) بربط رموز الوصول (access tokens) ورموز التحديث (refresh tokens) لـ OAuth بمفتاح عام في طبقة التطبيق، مما يحمي أساسًا استدعاءات واجهات برمجة التطبيقات (API) في التطبيقات الأصلية (native apps) وتطبيقات الصفحة الواحدة (SPAs). أما DBSC فتقوم بربط ملفات تعريف ارتباط (cookies) جلسة المتصفح بمفاتيح TPM مدعومة بالأجهزة بحيث لا يمكن لـ JavaScript قراءتها أو تصديرها، مما يحمي الجلسات الخاصة بالمستخدم حتى لو تم اختراق تطبيق الويب نفسه بواسطة البرمجة عبر المواقع (XSS) أو البرامج الضارة.

يتطلب التصميم الآمن التقليدي انتهاء فترات الجلسات (session timeouts) بوقت قصير للحد من الضرر إذا سُرق ملف تعريف ارتباط وأُعيد تشغيله عن بُعد. وتقوم DBSC بربط إمكانية التحديث بالمفتاح الخاص للجهاز الأصلي، لذا فإن أي ملف تعريف ارتباط مسروق يُستخدم من جهاز آخر سيفشل في اختبار التحدي التشفيري. وبهذا يمكن أن تكون الجلسات فعلية ولأجل غير مسمى لأن هجمات إعادة التشغيل عن بُعد قد تم تحييدها.

تقوم DBSC بتحييد سرقة ملفات تعريف الارتباط بصفتها الناقل الأساسي في عمليات الاستيلاء على الحسابات، مما يقلل بشكل مباشر من خسائر الاحتيال وتكاليف دعم استعادة الحسابات. فالجلسات الطويلة الآمنة تقضي على المطالبات المتكررة بتسجيل الدخول، مما يحسن معدلات التحويل في التجارة الإلكترونية ويقلل من معدلات الانسحاب. ويصنف تحالف FIDO (FIDO Alliance) تقنية DBSC كأداة ترفع من مستوى الأمان وتقلل الاحتكاك لدى المستخدم في الوقت نفسه.