القياسات الحيوية ووعي الدافع في الربط الديناميكي

يجمع نهج Corbado بين مفاتيح المرور (Passkeys) المقاومة لـ التصيد الاحتيالي (SCA) وشاشة عرض يتحكم فيها البنك وربط ديناميكي من جانب الخادم للوفاء بمتطلبات المادة 5 من المعايير الفنية التنظيمية لـ PSD2 ("ما تراه هو ما توقعه").

• التنفيذ الأساسي (اليوم): نعرض مبلغ المعاملة والمدفوع له في واجهة مستخدم يتحكم فيها Bison-Bank مباشرة قبل وأثناء المصادقة باستخدام مفتاح المرور. يُنشئ نظامنا الخلفي تحديًا لمرة واحدة يكون مرتبطًا بنسخة أساسية من المعاملة (المبلغ، المدفوع له، معرّف المعاملة). لا تُقبل الاستجابة إلا إذا تطابقت مع تلك النسخة؛ أي تغيير يبطلها.

• الموقف التنظيمي: يظل الربط الديناميكي مطلوبًا للمدفوعات عن بُعد حتى مع استخدام مفاتيح المرور (PSD2 المادة 97(2)؛ RTS المادة 5). لا تشترط المعايير الفنية التنظيمية (RTS) أن يتم حساب "رمز المصادقة" للربط الديناميكي على الجهاز؛ فالتوليد والتحقق من جانب الخادم مقبولان عند فرض سلامة العرض والتحديد والإبطال عند التغيير (انظر أيضًا سؤال وجواب الهيئة المصرفية الأوروبية 2020_5366 حول مكان حساب الرمز).

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

• المصادقة القوية للعملاء (SCA): عنصران مستقلان من فئات مميزة (المعرفة/الحيازة/السمة الشخصية)، محميان ضد الكشف/النسخ مع إجراءات تخفيف مناسبة (المواد 6-8 من RTS). الاستقلالية مطلوبة (المادة 9)، بما في ذلك الفصل عند التنفيذ على أجهزة متعددة الأغراض (مثل حماية على مستوى نظام التشغيل، أجهزة آمنة).
• الربط الديناميكي (المادة 5 من RTS):
  • (1) يتم إعلام الدافع بالمبلغ والمدفوع له أثناء المصادقة
  • (2) يكون رمز المصادقة فريدًا لذلك المبلغ/المدفوع له
  • (3) أي تغيير يبطل الرمز
  • (4) سرية وسلامة المبلغ والمدفوع له والرمز محمية من البداية إلى النهاية. هذا يحقق القصد التنظيمي "ما تراه هو ما توقعه".
• النتيجة: المصادقة القوية للمستخدم وحدها غير كافية للمدفوعات. يجب ربط الموافقة ببيانات معاملة محددة مع دليل قابل للتدقيق على هذا الربط والعرض للدافع (المادة 5(1)(أ-د) من RTS).

توضيح — التصيد الاحتيالي مقابل التفويض: مفاتيح المرور مرتبطة بالمصدر، لذا لا يمكن للنطاقات المزيفة الحصول على توقيعات صالحة. ومع ذلك، لا يزال PSD2 يتطلب الربط الديناميكي للمدفوعات عن بعد لربط التفويض بـالمبلغ والمدفوع له المحددين لـإبطال أي تغيير وحماية سلامة ما يتم عرضه على الدافع (المادة 5(1)(أ-د) من RTS). يعالج الربط الديناميكي سلامة التفويض (بما في ذلك استبدال MITM/MITB/TPP)، وليس فقط التصيد الاحتيالي.

يُعزز رأي الهيئة المصرفية الأوروبية لعام 2019 (EBA‑Op‑2019‑06) أن الربط الديناميكي يربط المصادقة بالمبلغ والمدفوع له، ويتطلب استقلالية العوامل ويقبل المفاتيح المشفرة المرتبطة بالجهاز كدليل على الحيازة حيث يوجد ربط فريد بالجهاز. كما يؤكد على سلامة ما يتم عرضه على الدافع أثناء المصادقة. رأي EBA 2019

قبل PSD2، اعتمدت العديد من البنوك على كلمات المرور لمرة واحدة عبر الرسائل القصيرة (SMS OTPs) أو قوائم أرقام المعاملات (TAN) المطبوعة التي غالبًا ما لم تظهر المبلغ أو المدفوع له بجانب خطوة الموافقة. سهّلت هذه الثغرة خداع العملاء للموافقة على تحويلات غير مقصودة بمجرد سرقة بيانات الاعتماد. تم تقديم الربط الديناميكي لسد هذه الثغرة من خلال ضمان أن يكون الدافع على علم بالمبلغ والمدفوع له بالضبط وقت المصادقة ومن خلال جعل رمز المصادقة خاصًا بتلك التفاصيل بحيث يبطله أي تغيير (المادة 5(1)(أ-د) من RTS). حيث تكون الرسائل القصيرة جزءًا من العملية، يجب على جهات الإصدار أيضًا ضمان سرية وصحة وسلامة المبلغ/المدفوع له والرمز خلال جميع مراحل المصادقة (سؤال وجواب 2018_4414؛ المادة 5(2) من RTS). تنفذ الموافقات داخل التطبيق اليوم (على سبيل المثال، "هل تريد تفويض 100 دولار أمريكي إلى جون سميث عبر Face ID؟") مبدأ "ما تراه هو ما توقعه" بطريقة سهلة للعملاء.

اليوم، على الأجهزة المحمولة، يسيطر نمطان. أولاً، يمكن لإشعار فوري أن يوجه العميل مباشرة إلى التطبيق لمراجعة تفاصيل المعاملة والموافقة عليها. أوضحت الجهات الإشرافية أن الإشعارات يمكن أن تكون دليلاً على عنصر الحيازة إذا تم تطبيق ضوابط المادة 7 للتخفيف من الاستخدام غير المصرح به ومنع النسخ، وكانت الرحلة بأكملها متوافقة مع RTS؛ ومع ذلك، لا تزال مخاطر الهندسة الاجتماعية قائمة ويجب معالجتها في تجربة المستخدم (سؤال وجواب 2019_4984؛ المادة 7 من RTS).

ثانيًا، تقوم الموافقات التي تستخدم القياسات الحيوية الأصلية للجهاز (مع وجود رقم تعريف شخصي كبديل) بإجراء تحقق من المستخدم محليًا لفتح عملية مفتاح خاص. يوجد المفتاح الخاص في بيئة أجهزة آمنة (Secure Enclave/TEE/TPM) ويوقع على تحدٍ. يتوافق هذا بشكل واضح مع SCA: السمة الشخصية (القياسات الحيوية) بالإضافة إلى الحيازة التي يثبتها ربط الجهاز ومفتاح تشفير مرتبط بالجهاز (EBA‑Op‑2019‑06، الفقرات 25، 35-37). بالنسبة للمدفوعات عن بعد، يجب أن يكون الرمز مرتبطًا ديناميكيًا بالمبلغ والمدفوع له ويجب عرض هذه التفاصيل على الدافع قبل التحقق من المستخدم (المادة 5 من RTS). إذا كان كلا العاملين على جهاز واحد، يجب تنفيذ بيئات تنفيذ آمنة منفصلة وفحوصات سلامة بحيث لا يؤدي اختراق أحدهما إلى اختراق الآخر (المادة 9(2)-(3) من RTS).

تحت الغطاء، لا تقوم القياسات الحيوية المحلية بـ "المصادقة مع البنك" مباشرة. بدلاً من ذلك، تقوم القياسات الحيوية (أو رقم التعريف الشخصي البديل) بإجراء تحقق من المستخدم على الجهاز وتتحكم في الوصول إلى مفتاح خاص غير قابل للتصدير مخزن في وحدة أمان مدعومة بالأجهزة. عندما يوافق الدافع، يستخدم الجهاز هذا المفتاح الخاص لإنشاء توقيع رقمي على تحدٍ مقدم من البنك. إذا اشتق البنك أو ربط هذا التحدي بنسخة أساسية من المعاملة (المبلغ، المدفوع له، المعرّفات)، فإن التوقيع الناتج يعمل كرمز مصادقة خاص بتلك التفاصيل. أي تغيير سيبطل الرمز لأن النسخة المخزنة لم تعد متطابقة، أو في التصميمات المحسنة، لأن اشتقاق التحدي يتغير. يظل جزء وعي الدافع متطلبًا لتجربة المستخدم: عرض المبلغ والمدفوع له في عرض يتحكم فيه البنك مباشرة قبل التحقق من المستخدم. معًا، يلبي هذا متطلبات المادة 5 من RTS بشأن الوعي والتحديد/التفرد والإبطال عند التغيير، بينما تثبت ضوابط المادة 7 وربط الجهاز عنصر الحيازة.

• الحيازة (المفاتيح المرتبطة بالجهاز والمتزامنة): يتم تخزين المفاتيح الخاصة لمفاتيح المرور في أجهزة آمنة (TEE/Secure Enclave/TPM). مفاتيح المرور المرتبطة بالجهاز غير قابلة للتصدير، مما يتماشى مع توقعات EBA للربط الفريد بالجهاز (EBA‑Op‑2019‑06، الفقرات 25، 35-37). يمكن لمفاتيح المرور المتزامنة أيضًا إثبات الحيازة عند كل مصادقة، شريطة أن تكون ضوابط ربط الجهاز ومكافحة النسخ فعالة؛ وقد أكد المنظمون على الحاجة إلى رابط موثوق بين العنصر والجهاز (EBA‑Op‑2019‑06؛ المادة 7 من RTS).
• السمة الشخصية/المعرفة (التحقق من المستخدم): يقوم التحقق من المستخدم عبر القياسات الحيوية (سمة شخصية) أو رقم التعريف الشخصي للجهاز (معرفة) بتفعيل المفتاح محليًا. بالإضافة إلى الحيازة، يعد هذا مصادقة ثنائية العوامل حقيقية مع استقلالية العوامل. اختراق أحدهما لا يعرض الآخر للخطر.

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

هناك خياران لتنفيذ الربط الديناميكي مع مفاتيح المرور:

• الربط من جانب الخادم (قياسي): إنشاء تحدي WebAuthn لمرة واحدة يربطه النظام الخلفي بالمبلغ والمدفوع له بالضبط. يرى المستخدم "X يورو إلى Y" في عرض يتحكم فيه البنك ويوافق باستخدام مفتاح مرور. لا تُقبل الاستجابة إلا لتلك المعاملة. أي تغيير يبطلها.
• التضمين التشفيري (محسّن): تضمين تجزئة (hash) للمبلغ/المدفوع له في التحدي بحيث يلتزم التوقيع ببيانات المعاملة. هذا غير مطلوب من قبل RTS ولكنه يضيف تأكيدًا على أن حتى التبديلات في النظام الخلفي ستفشل في التحقق.

ملاحظة امتثال صريحة: لا تتطلب RTS أن يتم حساب "رمز المصادقة" للربط الديناميكي على جهاز الدافع. يجوز لمقدم خدمة الدفع (PSP) إنشاؤه والتحقق منه على الخادم طالما أن المبلغ/المدفوع له محميان وأي تغيير يبطل الرمز (انظر سؤال وجواب EBA 2020_5366 حول موقع/توقيت الرمز). هذا هو نهجنا للربط الديناميكي من جانب الخادم (القياسي).

كلا الخيارين ينتج عنهما "رمز مصادقة" فريد وغير قابل لإعادة الاستخدام خاص بالمعاملة. التحذير الأساسي هو وعي الدافع: WebAuthn نفسه لا يثبت ما تم عرضه. يجب أن تأتي سلامة العرض من واجهة مستخدم يتحكم فيها البنك.

تتطلب المادة 5 من RTS أن يرى الدافع المبلغ والمدفوع له أثناء المصادقة. لا يشهد WebAuthn على ما تم عرضه. نظريًا، إذا تم اختراق التطبيق أو نظام التشغيل، يمكن تضليل المستخدم بينما لا يزال المصادق يوقع. سنحلل أدناه بالتفصيل كيف تحدث هذه المخاطرة في الواقع ولماذا لا تشكل خطرًا أمنيًا حقيقيًا بل هي مسألة تفسير للتنظيم.

ضوابط سلامة العرض التي نفرضها:

• عرض يتحكم فيه البنك يعرض المبلغ + المدفوع له: نحن نمنع استدعاء مفتاح المرور إذا كان العرض محجوبًا أو خارج نطاق التركيز
• اكتشاف التراكب/التلاعب في التطبيق/الويب: لا توجد مطالبات بمفاتيح مرور من iframes مخفية
• بوابة سلامة الجهاز/الشهادة: رفض أو تصعيد الإجراءات عند وجود إشارات تدل على جهاز مخترق (rooted/jailbroken)
• موافقة ذرية مقابل نسخة محفوظة على الخادم للمبلغ/المدفوع له: مطلوب تحدٍ جديد عند أي تغيير في المعلمات

حول التضمين التشفيري: امتدادات "عرض المعاملات" في WebAuthn (SPC) غير مدعومة على نطاق واسع اليوم. خط الأساس المحمول لدينا هو الربط من جانب الخادم، معززًا باشتقاق التحدي من نسخة المعاملة (على سبيل المثال، H(المبلغ || المدفوع له || معرّف المعاملة || قيمة عشوائية)) بحيث يلتزم التوقيع بتلك القيم.

يستخدم كلا النمطين التشفير بالمفتاح العام مع مفاتيح جهاز غير قابلة للتصدير، وكلاهما يعتمد على التحقق المحلي من المستخدم لفتح عملية التوقيع. في كليهما، يضمن البنك وعي الدافع من خلال عرض المبلغ والمدفوع له في عرض يتحكم فيه البنك مباشرة قبل التحقق من المستخدم، ويضمن التحديد من خلال ربط رمز المصادقة بتلك التفاصيل — وإبطاله عند أي تغيير (المادة 5(1)(أ-د) من RTS). إن RTS محايد تقنيًا ولا يتطلب عرض المبلغ/المدفوع له داخل نافذة قياسات حيوية لنظام التشغيل؛ بل يتطلب العرض للدافع وربط الرمز (المادة 5 من RTS). عندما يتم تنفيذ كلا عنصري SCA على جهاز واحد، تنطبق متطلبات السلامة والفصل في المادة 9 بالتساوي (المادة 9(2)-(3) من RTS). أخيرًا، موقع حساب الربط الديناميكي مرن: يمكن إجراؤه من جانب الخادم إذا تم الحفاظ على السلامة وأي تغيير يبطل الرمز (سؤال وجواب 2020_5366). هذه هي نفس الشروط التي يقبل بموجبها المنظمون بالفعل القياسات الحيوية المحلية مع PKI — لذلك، يجب قبول مفاتيح المرور، المنفذة بنفس ضوابط وعي الدافع والربط، على أساس مكافئ.

إذًا، هل تحقق مفاتيح المرور العادية وفقًا لمعيار WebAuthn قصد الربط الديناميكي؟ جزئيًا:

• هجمات الوسيط/الشبكة: نعم. يمنع ربط المصدر والتوقيعات لكل تحدٍ التلاعب وإعادة التشغيل.
• سلامة المعاملة: نعم. يضمن الربط من جانب الخادم أو تجزئة التحدي أن المبلغ/المدفوع له الأصليين فقط سيتم التحقق منهما.
• موافقة الدافع: أصعب. تفتقر مفاتيح المرور إلى عرض على مستوى المصادق. قد يكون خداع واجهة المستخدم على الأجهزة المخترقة ممكنًا. يجب بناء شيء إضافي لضمان موافقة الدافع.

لماذا لا يزال الربط الديناميكي مطلوبًا مع مفاتيح المرور

• قانوني: تفرض المادة 97(2) من PSD2 والمادة 5 من RTS الربط الديناميكي لـجميع عمليات بدء الدفع عن بعد. لا يوجد استثناء للطرق المقاومة للتصيد الاحتيالي.
• أمني: تزيل مفاتيح المرور التصيد الاحتيالي عبر المصادر المختلفة، لكنها لا تثبت بمفردها ما تم عرضه على الدافع. يضمن الربط الديناميكي + ضوابط سلامة العرض أن المبلغ/المدفوع له المحددين اللذين رآهما المستخدم هما ما ينفذه البنك، وأن أي تغيير يبطل الموافقة.

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

تقدم Corbado حلاً متوافقًا مع الربط الديناميكي يعالج بشكل صريح اعتبارات موافقة الدافع المذكورة أعلاه.

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

تدفق العملية:

• عرض يتحكم فيه البنك يظهر للدافع المبلغ والمدفوع له بالضبط. لا تظهر مطالبة بمفتاح المرور ما لم يكن هذا العرض مرئيًا.
• المصادقة: يستدعي العميل WebAuthn بتحدٍ فريد ومربوط لمرة واحدة للمعاملة الأساسية. يقوم المصادق بالتحقق من المستخدم (قياسات حيوية أو رقم تعريف شخصي للجهاز) ويوقع على التحدي والمصدر.
• التحقق من جانب الخادم: يتحقق النظام الخلفي من تجزئة معرّف الطرف المعتمد (RP ID) والمصدر، ويطابق التحدي مع المعاملة المخزنة، ويفحص علامات التحقق من المستخدم (UV)، ويفرض الاستخدام لمرة واحدة وانتهاء الصلاحية، ويقارن نسخة المبلغ/المدفوع له المخزنة.
• الموافقة والتدقيق: عندها فقط تتم الموافقة على المعاملة بشكل ذري. يتم رفض أي عدم تطابق/تغيير ويتطلب مصادقة جديدة. يتم الاحتفاظ بسجل تدقيق غير قابل للتغيير (معرّف الاعتماد، authenticatorData، clientDataJSON، التوقيع، التحدي، والمبلغ/المدفوع له الأساسي)، ويمكن ربطه بتجزئة متسلسلة كدليل على عدم التلاعب.
• بوابة سلامة الجهاز: تقييم سلامة الجهاز وإشارات الشهادة: رفض أو تصعيد الإجراءات إذا كان الجهاز مخترقًا (rooted/jailbroken).
• توحيد المدفوع له: عرض تسمية ودية (مثل، "ACME GmbH")، ولكن الربط والتحقق مقابل معرّف مدفوع له أساسي (مثل، IBAN/BIC أو نظام فريد آخر).

تفاصيل تقنية:

• النظام الخلفي: إنشاء كائن معاملة ببيانات أساسية (مثل، عملة/كسور عشرية موحدة؛ IBAN/مستفيد أساسي). إنشاء تحدٍ قصير العمر يلتزم بهذه القيم (مثل، H(المبلغ||المدفوع له||معرّف المعاملة||قيمة عشوائية))؛ تخزينه كمعلق؛ عرض معرّفات مبهمة فقط للعميل.
• العميل/المصادق: عرض تفاصيل الدافع في عرض يتحكم فيه البنك؛ استدعاء WebAuthn (RP ID = نطاق Bison) فقط عندما يكون مرئيًا؛ طلب التحقق من المستخدم؛ يوقع المصادق على التحدي + المصدر وفقًا لـ WebAuthn.
• التحقق/الإنهاء: التحقق من التوقيع، تجزئة RP ID، المصدر/النوع، علامات UV؛ مكافحة إعادة التشغيل/انتهاء الصلاحية؛ مقارنة نسخة المبلغ/المدفوع له غير القابلة للتغيير؛ الموافقة الذرية؛ الاحتفاظ بسجل التدقيق.
• اشتقاق التحدي من النسخة:: challenge = H(المبلغ ‖ المدفوع له الأساسي ‖ معرّف المعاملة ‖ قيمة عشوائية)

سياسات تجربة المستخدم:

• تركيز واضح على المبلغ/المدفوع له؛ ضوابط تأكيد/إلغاء يمكن الوصول إليها؛ مهل زمنية قصيرة؛ إعادة محاولة سلسة باستخدام تحدٍ جديد دائمًا؛ إيصالات فورية (مثل، "لقد وافقت على X يورو إلى Y"). حظر مطالبة مفتاح المرور إذا كان العرض محجوبًا والتحذير إذا تغيرت المعلمات قبل التوقيع.
• اكتشاف التراكبات/المحتوى المحجوب: لا تعرض أبدًا مطالبة بمفتاح مرور إذا كان عرض المعاملة غير مرئي. ارفض إذا تغيرت المعلمات في منتصف التدفق وأعد التشغيل بـتحدٍ جديد.

ملاحظة امتثال: هذا التصميم المتكامل يفي بمتطلبات المادة 5 من RTS: وعي الدافع (عرض يتحكم فيه البنك)، التحديد والتفرد (رمز لمرة واحدة مرتبط بالمبلغ/المدفوع له)، الإبطال عند التغيير (فحوصات صارمة من جانب الخادم)، والسرية/السلامة للمبلغ/المدفوع له والرمز خلال جميع المراحل (المادة 5(1)(أ-د)، 5(2) من RTS؛ انظر أيضًا سؤال وجواب 2018_4414 لسلامة الرسائل القصيرة). يتم الحفاظ على استقلالية العوامل (المواد 7-9) عبر الحيازة المرتبطة بالجهاز والتحقق المحلي من المستخدم على أجهزة متعددة الأغراض مع حماية مناسبة (المادة 9(2)-(3) من RTS).

ملاحظة:

• بالنسبة لتدفقات الويب، ستعتمد Corbado اختياريًا تأكيد الدفع الآمن](https://www.w3.org/TR/payment-request-secure-payment-confirmation/) إذا/عندما توفر Apple دعمًا واسعًا، مما يضيف عرضًا موثوقًا بوساطة المتصفح يشهد تشفيريًا على المبلغ والمدفوع له.

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

القلق: الهندسة الاجتماعية / الاحتيال بالدفع الفوري المصرح به (APP) الاستجابة: لا يمكن لأي مصادق أن يمنع تمامًا المستخدم من تفويض دفعة تحت ذرائع كاذبة (مثل، عمليات احتيال "الحساب الآمن"). يضمن الربط الديناميكي أن يرى المستخدم صراحةً المدفوع له والمبلغ ويوفر دليلاً قويًا على الموافقة، لكنه لا يمكنه تجاوز دافع مقتنع. تشمل التعويضات التحذيرات السياقية (مدفوع له جديد، أول تحويل كبير)، فترات تهدئة أو تنفيذ مؤجل للمدفوع لهم ذوي المخاطر العالية، تحقق أقوى من المدفوع له، وفحوصات تصعيدية (تأكيد إضافي) عند وجود إشارات خطر. تساعد إشعارات ما بعد الدفع وقنوات النزاع السريعة في اكتشاف الضرر واحتوائه. نضيف تحذيرات سياقية في الوقت الفعلي (مثل، مدفوع له جديد، أول تحويل كبير)، فترات تهدئة للمدفوع لهم ذوي المخاطر العالية، تحقق أقوى من المدفوع له وإشعارات ما بعد الدفع ("لقد وافقت على X يورو إلى Y") لتسريع الاكتشاف والاستجابة.

القلق: البرامج الضارة أو اختراق الجهاز الاستجابة: المفاتيح الخاصة غير قابلة للتصدير وتتطلب التحقق المحلي من المستخدم لكل توقيع، لذلك لا يمكن للبرامج الضارة ببساطة سرقة بيانات الاعتماد. الخطر الواقعي هو خداع واجهة المستخدم على نظام تشغيل مخترق بالكامل. يمكن التخفيف من ذلك من خلال واجهة مستخدم آمنة/متحقق منها (مثل، تأكيدات محمية)، فحوصات سلامة الجهاز/الشهادة وحظر الأجهزة عالية الخطورة، والتأكيدات الموثوقة مثل SPC أو امتداد تأكيد عند توفره. إذا ظهرت مؤشرات اختراق (اكتشاف تراكب، root/jailbreak)، استخدم إعادة التحقق خارج النطاق أو ارفض التنفيذ. لا توجد طريقة استهلاكية مثالية على جهاز مملوك بالكامل، لكن هذه الضوابط تضيق نافذة الهجوم بشكل كبير.

القلق: هجوم الوسيط في المتصفح / اختطاف الجلسة الاستجابة: يمكن للإضافات الضارة أو النصوص البرمجية المحقونة بدء إجراءات على المصدر الشرعي. توقف مفاتيح المرور المرتبطة بالمصدر التصيد الاحتيالي عبر المواقع. يضمن الربط الديناميكي أن التعديلات التي تتم في الكواليس على المبلغ/المدفوع له تفشل. نقوم بتعزيز القناة عبر ضوابط CSP/مكافحة التلاعب ومن خلال طلب تحدٍ جديد وفريد لكل تأكيد.

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

القلق: سرقة الأجهزة / سرقة بيانات الاعتماد الاستجابة: مجرد حيازة الجهاز غير كافٍ: مطلوب التحقق من المستخدم (قياسات حيوية/رقم تعريف شخصي) لكل توقيع، مع حدود معدل وقفل على مستوى نظام التشغيل. تتطلب كل دفعة تحديًا جديدًا وخاصًا بالمعاملة؛ لا يمكن لرموز الجلسة العامة تفويض مدفوعات عشوائية. إضافات مثل إلغاء الجهاز عن بعد، التصعيد عند استخدام جهاز جديد، فحوصات سرعة الموقع الجغرافي، والإشعارات ("لقد فوضت X يورو إلى Y") تقيد الاستغلال بشكل أكبر.

بشكل عام: تقلل مفاتيح المرور بشكل مادي من مخاطر التصيد الاحتيالي وإعادة التشغيل؛ يظل الربط الديناميكي ضروريًا لضمان سلامة المعاملة، وربط الموافقات بالمبلغ/المدفوع له، وتوفير دليل قوي على الموافقة المستنيرة عبر سيناريوهات التهديد المتبقية.

السؤال 1: كيف يمكننا إثبات أن المستخدم رأى ووافق بالفعل على المبلغ والمدفوع له عند استخدام مفتاح مرور؟ الاستجابة: نحن نفرض عرض تفاصيل الدفع في عرض يتحكم فيه البنك ونربط الموافقة بـنسخة من جانب الخادم للمبلغ/المدفوع له. يتم قبول التأكيد الخاص بمفتاح المرور (authenticatorData, clientDataJSON, التوقيع) فقط للتحدي المشتق من تلك النسخة؛ أي تغيير يتطلب تحديًا جديدًا. يربط تدقيقنا المقاوم للتلاعب التأكيد بـ "X يورو إلى معرّف المدفوع له Y" ويسجل أن نظامنا لن يتابع إذا اختلفت التفاصيل. حيثما يكون مدعومًا، يضيف SPC دليلاً تشفيريًا على أن المستخدم أكد التفاصيل المعروضة.

السؤال 1: كيف يمكننا إثبات أن المستخدم رأى ووافق بالفعل على المبلغ والمدفوع له عند استخدام مفتاح مرور؟ الاستجابة: هذا هو سؤال عدم الإنكار بشكل أساسي. بموجب PSD2، كان القصد من الربط الديناميكي ضمان أن يكون المستخدم على دراية بما يوافق عليه. باستخدام مفتاح المرور، الدليل الذي نحتفظ به هو التوقيع التشفيري (رمز المصادقة) والبيانات المرتبطة به (أي مبلغ/مدفوع له كان مرتبطًا به على خادمنا). كسياسة، نعرض تفاصيل المعاملة للمستخدم في التطبيق أو صفحة الويب قبل المصادقة. نسجل تلك الشاشة/العرض والمصادقة الناجحة اللاحقة بمفتاح المرور لتلك المعاملة المحددة. في حالة النزاع، يمكننا أن نثبت أن جهاز المستخدم أنتج توقيعًا صالحًا لتحدٍ كان مرتبطًا (على سبيل المثال) بـ "100 يورو إلى شركة ACME" وأن نظامنا لم يكن ليتابع لو كان أي تفصيل مختلفًا. يعتمد امتثالنا على التسجيل الآمن: نحن نضمن أن أنظمتنا مقاومة للتلاعب في ربط استجابة مفتاح المرور ببيانات المعاملة.

السؤال 2: ماذا لو تم اختراق الجهاز أو نظام التشغيل؟ هل يمكن للبرامج الضارة التلاعب بالمعاملة أو عملية مفتاح المرور؟ الاستجابة: يعد اختراق الجهاز تهديدًا خطيرًا في أي سيناريو مصرفي رقمي. إذا كان نظام التشغيل ضارًا، فقد يحاول تضليل المستخدم أو اختطاف العمليات. ومع ذلك، حتى في أسوأ الحالات، تحافظ مفاتيح المرور على بعض الحمايات الرئيسية. لا يمكن استخراج المفتاح الخاص بواسطة البرامج الضارة. كما لا يمكن للبرامج الضارة انتحال شخصية المستخدم لدى البنك، لأنها لا تستطيع إنتاج توقيع مفتاح المرور بدون القياسات الحيوية/رقم التعريف الشخصي للمستخدم. أقصى ما يمكن أن تفعله هو دفع المستخدم للمصادقة على شيء ما تحت ذرائع كاذبة. يساعد الربط الديناميكي هنا من خلال طلب فحوصات سلامة: لا يمكن للبرامج الضارة تغيير تفاصيل المعاملة بصمت بعد إتمامها - إذا فعلت ذلك، فلن يتم التحقق من التوقيع. أضعف نقطة هي العرض/واجهة المستخدم: قد يغير حصان طروادة متطور ما يراه المستخدم (على سبيل المثال، عرض "شركة ACME" بينما تذهب المعاملة الأساسية في الواقع إلى مدفوع له آخر). هذا ليس بالأمر السهل، خاصة إذا كان تطبيق البنك يستخدم أطر واجهة مستخدم آمنة، ولكنه أمر يمكن تصوره. مع كل ما قيل، إذا اكتشفنا علامات اختراق الجهاز (سلوك غير عادي، توقيعات برامج ضارة معروفة، إلخ)، فسنلجأ إلى التحقق خارج النطاق أو نرفض المعاملة. باختصار: لا يوجد حل آمن بنسبة 100% إذا كان جهاز المستخدم مملوكًا بالكامل لمهاجم. تقلل مفاتيح المرور + الربط الديناميكي بشكل كبير من سطح الهجوم (لا يمكن للمهاجم ببساطة تمرير بيانات الاعتماد أو تغيير بيانات الشبكة؛ سيتعين عليه خداع المستخدم في الوقت الفعلي). إذا تم اختراق نظام التشغيل، يضمن الربط الديناميكي على الأقل أن أي عدم تطابق بين ما يجب أن يكون وما تمت الموافقة عليه يتم اكتشافه من قبل نظامنا الخلفي.

السؤال 3: إذا تم استخدام قياس حيوي لفتح مفتاح المرور، فهل يعتبر ذلك عاملاً واحدًا أم اثنين؟ هل نمتثل لقاعدة العاملين؟ الاستجابة: القياس الحيوي وحده ليس كافيًا لـ SCA - إنه مجرد عامل سمة شخصية واحد. ومع ذلك، في تنفيذ مفتاح المرور، القياس الحيوي ليس وحده: حيازة الجهاز هي العامل الآخر. يفتح القياس الحيوي للمستخدم المفتاح الخاص المخزن على الجهاز. الحيازة والسمة الشخصية فئتان متميزتان. هذا يماثل كيف تلبي العديد من تطبيقات الخدمات المصرفية بالفعل SCA: لديك الهاتف (حيازة) و تستخدم بصمة إصبعك أو وجهك لفتح التطبيق (سمة شخصية). اعترفت الهيئة المصرفية الأوروبية صراحةً بمجموعات من ربط الجهاز بالإضافة إلى القياسات الحيوية كـ SCA متوافق. سيناريو مفتاح المرور هو بالضبط هذا المزيج. إذا اختار المستخدم استخدام رقم تعريف شخصي بدلاً من القياس الحيوي لفتح مفتاح المرور، فهذا يعني حيازة + معرفة، وهو متوافق أيضًا. نحن نفرض التحقق من المستخدم في جميع عمليات مفاتيح المرور (مما يعني أن المستخدم يجب أن يقدم قياسًا حيويًا/رقم تعريف شخصي في كل مرة)، لذلك لا توجد حالة يكون فيها مجرد امتلاك الجهاز كافيًا. وبالتالي، فإن كل تفويض دفع عبر مفتاح المرور هو حدث ثنائي العوامل بموجب تعريفات PSD2.

السؤال 4: هل يمكن لمهاجم إعادة استخدام مصادقة مفتاح مرور أو تجاوز الربط الديناميكي بطريقة ما عن طريق التلاعب بالبيانات أثناء النقل؟ الاستجابة: لا. هذا هو المكان الذي تعمل فيه مفاتيح المرور والربط الديناميكي معًا بقوة. كل مصادقة WebAuthn تنتج توقيعًا فريدًا مرتبطًا بالتحدي (الذي ننشئه لكل معاملة) ومحدد لنطاقنا. لا يمكن للمهاجم إعادة تشغيل هذا التوقيع لمعاملة مختلفة. يشتمل التوقيع نفسه على قيمة عشوائية للتحدي وهو صالح فقط لما تم إصداره من أجله في الأصل. إذا اعترض مهاجم الاتصال بالشبكة، فلن يتمكن من تغيير المبلغ أو المدفوع له دون إبطال التوقيع (لأن التحدي أو سياق المعاملة لن يتطابق بعد الآن). هذه هي حماية MITM التي ناقشناها بشكل فعال. أيضًا، تتضمن توقيعات مفاتيح المرور بيانات المصدر - لن يتم التحقق منها إذا لم يتم إرسالها إلى موقعنا/تطبيقنا الدقيق، لذا لن ينجح التصيد الاحتيالي أو إعادة التوجيه. باختصار، أي محاولة تلاعب تبطل رمز المصادقة، وفقًا لقواعد الربط الديناميكي. هذا في الواقع أكثر أمانًا من بعض تدفقات OTP الحالية، حيث يوافق المستخدمون أحيانًا على رمز عام وهناك خطر من أن الطلب قد تم التلاعب به. مع مفاتيح المرور، نربط مصادقة المستخدم تشفيريًا بالجلسة/المعاملة المحددة.

السؤال 5: هل هناك أي آراء تنظيمية معروفة حول WebAuthn/مفاتيح المرور لـ SCA؟ هل نحن متأكدون من أن المنظمين سيقبلون مفاتيح المرور كطريقة متوافقة؟ الاستجابة: حتى الآن، لم تنشر الهيئة المصرفية الأوروبية صراحةً آراء حول WebAuthn أو مصطلح "مفاتيح المرور" في أسئلتها وأجوبتها أو إرشاداتها. ومع ذلك، بناءً على المبادئ التي وضعوها، تتناسب مفاتيح المرور بوضوح مع الأساليب المقبولة. توقع رأي EBA لعام 2019 بشكل أساسي مناهج شبيهة بـ FIDO2: بالنسبة للحيازة، ذكروا صراحةً "تبادل المفاتيح العامة/الخاصة" مع ربط مناسب بالجهاز كدليل على الحيازة. مفتاح مرور WebAuthn هو بالضبط ذلك - زوج من المفاتيح العامة/الخاصة، مع النصف الخاص مرتبط بشكل آمن بالجهاز. كما أشاروا إلى "توقيع تم إنشاؤه بواسطة جهاز" كدليل حيازة صالح. لذلك بينما لم يستخدموا مصطلح مفتاح المرور، فإن الطريقة مغطاة بأمثلتهم. لقد لاحظنا أيضًا أن اللاعبين الرئيسيين في مجال المدفوعات في أوروبا يمضون قدمًا في تطبيقات مفاتيح المرور (مثل PayPal) مما يشير إلى مستوى من الثقة في أن هذا متوافق مع PSD2. يوضح هذا المثال أن مفاتيح المرور يتم قبولها كجزء من تدفقات SCA المتوافقة، شريطة تلبية الربط الديناميكي والمتطلبات العامة.

السؤال 6: هل ما زلنا بحاجة إلى الربط الديناميكي إذا كانت مفاتيح المرور مقاومة للتصيد الاحتيالي؟ الاستجابة: نعم. تمنع مفاتيح المرور التصيد الاحتيالي عبر المصادر المختلفة، لكن PSD2 لا يزال يفرض الربط الديناميكي لبدء الدفع عن بعد. يربط الربط الديناميكي المبلغ والمدفوع له المحددين بنتيجة SCA ويبطل أي تغيير، مما يعالج سلامة التفويض بما يتجاوز التصيد الاحتيالي (مثل، استبدال MITM/MITB/TPP).

حل Corbado متوافق مع الربط الديناميكي وPSD2. إن عرض تفاصيل الدفع قبل المصادقة، والتحدي لمرة واحدة المرتبط بالمبلغ والمدفوع له، والتحقق الصارم من جانب الخادم، والتدقيق غير القابل للتغيير، تلبي معًا متطلبات المادة 5 من RTS بشأن وعي الدافع، والتفرد/التحديد، والإبطال عند التغيير، والسلامة/السرية. يتم الحفاظ على استقلالية العوامل من خلال الحيازة المرتبطة بالجهاز والتحقق من المستخدم (قياس حيوي أو رقم تعريف شخصي)، بما يتماشى مع إرشادات EBA.

مقارنة بأساليب OTP/SMS الحالية، تقدم Corbado أمانًا ونتائج مستخدم أفضل بشكل مادي: مقاومة للتصيد الاحتيالي والتمرير، ومنع التلاعب الصامت بالمعلمات، ودليل أقوى غير قابل للإنكار، وتقليل الاحتكاك من خلال التحقق من المستخدم على الجهاز. يتم التخفيف من المخاطر المتبقية (مثل، الهندسة الاجتماعية، الأجهزة المخترقة) بضوابط ملموسة وهي أضيق نطاقًا مما هي عليه مع الأساليب القديمة. بالنسبة للويب، يمكن لـ Corbado اعتماد SPC عندما يكون دعم المنصات (لا سيما Apple) واسعًا، مما يضيف دليلاً تشفيريًا على العرض دون تغيير وضع الامتثال الأساسي.

باختصار، يلبي تفويض المعاملات المستند إلى مفاتيح المرور من Corbado نص وروح الربط الديناميكي في PSD2 ويحسن من مقاومة الاحتيال وقابلية التدقيق مقارنة بالنهج القديمة، مع الحفاظ على مسار واضح للتحسينات المستقبلية (SPC) مع نضج النظام البيئي.

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