PSD2: مصادقة العملاء القوية في الاتحاد الأوروبي

هذا هو الجزء الثاني من سلسلة من ثلاثة أجزاء من المنشورات التي توضح بالتفصيل PSD2: مصادقة قوية للعملاء في الاتحاد الأوروبي (SCA).

في الدفعة الأولى من هذه السلسلة المكونة من ثلاثة أجزاء ، قدمنا ​​توجيه الهيئة المصرفية الأوروبية للاتحاد الأوروبي (أو EBA) المسمى PSD2 (اختصارًا لتوجيه خدمات الدفع الثاني) وحددنا بعض المبادئ التوجيهية لمصادقة العملاء القوية (أو SCA) .

بالإشارة إلى SCA ، يلاحظ EBA: "بفضل PSD2 ، ستتمتع المستهلكين بحماية أفضل عند إجراء عمليات الدفع أو المعاملات الإلكترونية (مثل استخدام الخدمات المصرفية عبر الإنترنت أو الشراء عبر الإنترنت). كما هو مذكور في الجزء 1 ، فإن المعيار الفني التنظيمي (RTS) يجعل المصادقة القوية للعملاء (SCA) أساسًا للوصول إلى حساب الدفع الخاص بالفرد ، وكذلك لإجراء المدفوعات عبر الإنترنت ".

في هذا المنشور ، سوف نستكشف قيود SCA والمنظمين التي يجب على المنفذين أخذها في الاعتبار. أولاً ، لنلقِ نظرة على رموز المصادقة التي تم إنشاؤها. تذكر أن هذا في الأساس عبارة عن مصادقة ثنائية أو 2FA.

يحدد RTS الشروط التالية لرموز المصادقة:

• لا يمكن اشتقاق أي معلومات تتعلق بالمعرفة والحيازة والميراث من الكشف عن رمز المصادقة. هذا يعني أنه إذا كنت تعرف رمز المصادقة ، فلا توجد طريقة لاشتقاق أي عنصر آخر من المعرفة (مثل معرف المستخدم) ، وما يمتلكه المستخدم (على سبيل المثال ، هاتف محمول - مما يعني أنه لا يمكنك اشتقاق رقم الهاتف المحمول) أو الميراث - جوانب حول المستخدمين أنفسهم ، مثل القياسات الحيوية.
• لا يمكن إنشاء رمز مصادقة جديد بناءً على معرفة أي رمز مصادقة آخر تم إنشاؤه مسبقًا . بالنسبة لهذا الشرط ، نظرًا لأي رمز مصادقة ، لا توجد طريقة لإنشاء رمز مصادقة جديد من خلال الرجوع إلى واحد أو أكثر من رموز المصادقة السابقة.
• لا يمكن تزوير رمز المصادقة . يجب على المنفذ إنشاء رموز المصادقة بحيث لا يمكن التحقق من صحة الرموز المزيفة أو المزيفة بنجاح.
• لا يجب محاولة أكثر من 5 محاولات مصادقة فاشلة خلال فترة سريان الرمز. سيكون لكل رمز تم إنشاؤه وقت انتهاء صلاحية أو "وقت للعيش". يبدأ هذا المؤقت فورًا بعد إنشاء الرمز ويتضمن وقت التسليم. القاعدة الأساسية الجيدة هي أن الكود يجب أن تنتهي صلاحيته خلال 15 دقيقة أو أقل. تستغرق بعض المنظمات هذه المدة إلى 30 دقيقة أو ساعة واحدة ، ولكن قد تكون طويلة جدًا. إذا حاول المستخدم المصادقة بالرمز وفشل 5 مرات ، فيجب إرسال رمز جديد. هذا يمنع أي نوع من محاولات القوة الغاشمة لمعرفة الكود.
• يجب ألا يتجاوز الحد الأقصى للوقت بدون نشاط من قبل الدافع أو المستخدم بعد المصادقة للوصول إلى حساب الدفع الخاص به عبر الإنترنت 5 دقائق . هذا هو مؤقت عدم نشاط قياسي وبينما يكون منفصلاً عن رمز المصادقة ، فهو مؤقت يبدأ بمجرد مصادقة المستخدم بنجاح ولا يقوم بأي نشاط.

هذه كلها شروط قياسية نسبيًا لإنشاء / التحقق من صحة رمز المصادقة المستخدم في حالات 2FA.

الآن دعنا نلقي نظرة على متطلبات RTS التي تسمى الربط الديناميكي للمعاملات. يجب أن تتضمن المعاملات الإلكترونية عن بُعد (على سبيل المثال التي تتم عبر الإنترنت ، بغض النظر عما إذا كان الجهاز سطح مكتب أو جهازًا محمولًا) عناصر "تربط المعاملة ديناميكيًا بالمبلغ المحدد (للدفع) والمدفوع لأمره المحدد.

يشير مطلب SCA هذا إلى أن مبلغ الدفع للمعاملة جنبًا إلى جنب مع من يتم السداد يجب إعادته إلى المستخدم في وقت معاملة 2FA.

على سبيل المثال ، ستتحقق رسالة SMS التي يتلقاها المستخدم من مبلغ الشراء والتاجر ، إلى جانب رمز الأمان (المصادقة) ومعلومات انتهاء الصلاحية لهذا الرمز. شيء واحد يجب ملاحظته هو أن مبلغ الشراء والتاجر غير مشفرين.

قد يكون البديل هو تضمين عنوان URL مع رمز الحماية في رسالة SMS. يرغب عنوان URL في الحصول على معلومات المعاملة المرتبطة والمشفرة - التي يمكن الوصول إليها عبر شيء يعرفه المستخدم ، بالإضافة إلى رمز الأمان (الذي يتم تلقيه على شيء يمتلكه المستخدم).

رموز المصادقة التي تم إنشاؤها بواسطة تطبيقات الطرف الثالث المتوافقة مع TOTP مثل Google Authenticator والعديد من التطبيقات الأخرى منفصلة تمامًا عن معلومات الدفع / التاجر. تعد القدرة على ربط هذه الرموز ديناميكيًا بالمعاملة أمرًا مزعجًا إلى حد ما.

بالإضافة إلى ذلك ، قد لا تحتوي معظم هذه التطبيقات المجانية على التدابير المناسبة لدعم الربط الديناميكي لبيانات المعاملات ولضمان احتواء هذه التطبيقات على إجراءات مضادة لتعطيل استنساخ التطبيقات وكذلك كسر الحماية واكتشاف الجذر. ومع ذلك ، هناك بعض SDKs و APIs المتخصصة التي يمكن أن توفر هذه الإجراءات المضادة لتطبيقات الأجهزة المحمولة المتوافقة.

هذا يعني أن رمز المصادقة الذي تم إنشاؤه بواسطة تطبيق متوافق مع TOTP تابع لجهة خارجية مثل Google Authenticator يتم إنشاؤه بشكل منفصل عن معلومات الدفع / التاجر وبالتالي لا يمكن ربطه ديناميكيًا.

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

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

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

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

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

في الجزء الثالث من هذه السلسلة المكونة من ثلاثة أجزاء ، سنحدد بعض خيارات تنفيذ SCA التي يجب أن تفي بالمتطلبات الموضحة في RTS ، بالإضافة إلى بعض الأماكن للعثور على مزيد من المعلومات.

يرجى النظر في متابعتي على تويتر: @ wdudley2009

تعرف على التأثيرات التي قد تحدثها الأزمة الصحية الحالية على استراتيجية الأعمال والتحول الرقمي ومستقبل التجارة الإلكترونية هنا.