لا يمكن استخدام U2F المسجل إذا تغير اسم المضيف

ملاحظة: هذا سلوك مرغوب فيه من منظور أمني، ولكن يمكننا تحسين تجربة المستخدم إذا حدث هذا لمستخدم

إذا قام المستخدم بتسجيل رمز U2F، فلن يعمل إذا تغير اسم المضيف للموقع منذ تسجيله.

ومع ذلك، لا توجد أي تغذية راجعة للمستخدم تشير إلى أن هذا قد يكون بسبب تغير اسم المضيف، حيث أننا لا نخزن هذه المعلومات في Discourse. وإذا لم يكن المستخدم على دراية بالسبب الذي قد يؤدي إلى ذلك، فسيشعر بالارتباك.

قد يكون التحسين في هذه الحالة هو ما يلي على هذه الشاشة:

  • تعطيل خيار “المصادقة باستخدام مفتاح الأمان”.
  • إظهار رسالة مثل: “لدينا مفتاح أمان مسجل لهذا الحساب، لكنه ليس للمضيف الذي تقدم بطلبك إليه (www.example.com)”.

اعتبار:

  • إذا قمنا بما سبق، يجب أن نضمن عدم إعادة تعيين اسم المضيف القديم إلى اسم المضيف الجديد في جدول UserSecurityKey.
6 إعجابات

نعم، يجب أن نضيف بعض النص هنا @sam لتغطية حالة تغيير اسم النطاق. أعتقد أنه في الغالب تحديث للنص، مثل إخلاء مسؤولية في الأسفل أو شيء مشابه؟

إعجاب واحد (1)

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

وبشكل مرتبط بذلك، يجب عليّ أيضًا إصلاح 2fa security key breaks when migrating to custom domain - #6 by balboah. سأعيّن هذا الموضوع لنفسي أيضًا، لأنني أعتقد أنه عند تغيير أسماء المضيفين، يجب ربما تعطيل جميع مفاتيح الأمان الحالية لأنها تصبح عديمة الفائدة فعليًا.

إعجاب واحد (1)

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

إعجاب واحد (1)