تهدف هذه الوثيقة إلى توثيق أهداف مشروع Discourse فيما يتعلق بمصادقة FIDO2 / Webauthn.
لماذا؟
سيؤدي إضافة دعم Webauthn إلى Discourse إلى زيادة أمان حسابات المستخدمين، مما يتيح إنشاء حسابات خالية من كلمات المرور بسهولة باستخدام الميزات الآمنة لأجهزتهم، مثل قارئ البصمة في الهواتف الذكية.
طرق المصادقة
Webauthn كعامل مصادقة ثانٍ (يعمل كبديل لـ Google Authenticator)
Webauthn كعامل مصادقة أول (يعمل كبديل لتسجيل الدخول عبر الشبكات الاجتماعية)
Webauthn كعامل مصادقة متعدد العوامل (تسجيل دخول بدون اسم مستخدم)
Webauthn كعامل مصادقة ثانٍ
سيمكن هذا المستخدم من Discourse، الذي يمتلك حسابًا نشطًا بالفعل، من استخدام Webauthn كعامل مصادقة ثنائي (2FA)، حيث نوفر حاليًا دعمًا لـ TOTP فقط.
يمكن أن تعمل أي طريقة Webauthn هنا، سواء كانت قياسات بيومترية للجهاز (مثل قارئ البصمة في أندرويد، أو Windows Hello في أجهزة اللابتوب)، أو شريحة آمنة في الجهاز (مثل TPM، أو Secure Enclave)، أو مفتاحًا ماديًا (مثل Yubikey).
سيكون هذا متاحًا لكل مستخدم يتصفح باستخدام:
Microsoft Edge على نظام Windows، باستخدام Windows Hello (مع التعرف على الوجه، أو قارئ البصمة، أو رمز PIN)
Chrome على نظام macOS، باستخدام Touch ID
هاتف أندرويد
لابتوب/سطح مكتب/هاتف + مفتاح مادي (Yubikey، Google Titan)
Webauthn كعامل مصادقة أول (حسابات خالية من كلمات المرور)
يسمح للمستخدم بتسجيل الدخول إلى حساب Discourse الخاص به باستخدام مصادقة Webauthn كبديل لكلمة المرور. إذا تم إعداد عامل مصادقة أول، فسيُطلب من المستخدم استخدام هذا العامل بدلاً من كلمة المرور.
ستعمل نفس طرق المصادقة المستخدمة في المصادقة الثنائية في حالة المصادقة الأولية: القياسات البيومترية، أو الشريحة الآمنة، أو المفتاح المادي.
Webauthn كعامل مصادقة متعدد العوامل (تسجيل دخول بدون اسم مستخدم)
سيوفر طريقة تسجيل دخول بديلة تطلب فقط إدخال بيانات Webauthn. سيقوم المفتاح الأمني المسجل بإضافة معلومات معرف المستخدم (user ID) إلى خادم Discourse.
تتطلب هذه الطريقة حاليًا مفتاح مصادقة حديث (مثل Yubikey 5) بالإضافة إلى Google Chrome 76 أو أحدث، لأنها تعتمد على ميزة تسمى “المفاتيح القابلة للنقل” (Resident Keys). وبما أن هذه الميزة تخزن البيانات على جهاز المصادقة، فقد تكون هناك قيود، فمثلاً يمكن لـ Yubikey 5C تخزين ما يصل إلى 25 مفتاحًا من هذا النوع فقط.
سير عملية التسجيل
هذه العمليات هي تطور عن عملية تسجيل الدخول الخالي من كلمات المرور، وليست سير عملية تسجيل دخول منفصل. وهذا يسمح بتنفيذ تدريجي.
شكرًا لك على هذه طلب المراجعة (RFC)، فهي شاملة جدًا! ومع ذلك، لدي فكرة تتعلق بتدفق استخدام Webauthn كطريقة للمصادقة الثنائية مع تسجيل الدخول العادي باستخدام اسم المستخدم وكلمة المرور. عندما أستخدم المصادقة الثنائية عبر TOTP، تظهر لي هذه النافذة المنبثقة عند تسجيل الدخول:
إذا كان المستخدم قد فعّل كودات TOTP ومصادقات Webauthn معًا، فماذا سيكون تدفق العمل؟ هل سيختار المستخدم في هذه النافذة المنبثقة ما إذا كان يريد استخدام Webauthn أو رمز المصادقة الثنائية؟ أم أن هذا سيكون مرهقًا جدًا؟ ربما يمكن لـ Discourse افتراضيًا طلب Webauthn إذا كان المستخدم قد قام بإعداده ويدعمه المتصفح، ثم العودة إلى المصادقة الثنائية كخيار احتياطي؟
شكرًا لك جيف، هذا منطقي. بعض الأفكار الأخرى اليوم بعد مزيد من البحث:
المصادقة بالعامل الأول
إذا قام مستخدم بالتسجيل في حساب Discourse باستخدام Webauthn كطريقة للمصادقة بالعامل الأول، فهل توجد طريقة لاحقًا لتغيير ذلك واستخدام كلمة مرور بدلاً من ذلك؟ وإذا كان الأمر كذلك، هل ستتحول مصادقة Webauthn التي تم إعدادها إلى طريقة عادية للمصادقة الثنائية (2FA) حتى الوقت الذي يقرر فيه المستخدم إزالتها؟
إذا تم استخدام Webauthn كطريقة للمصادقة بالعامل الأول، فهل سيظل يظهر في واجهة المستخدم ضمن تفضيلات العامل الثاني، ولكن دون إمكانية إزالته؟
هل من المنصف أيضًا القول إن المستخدم سيتم منعه من إعداد تسجيلات الدخول عبر الشبكات الاجتماعية بنفس الطريقة التي يُمنع بها إذا كانت المصادقة الثنائية (2FA) مفعلة؟
أتخيل أن قسم تفضيلات المستخدم الذي تُرسل إليه رسالة إعادة تعيين كلمة المرور سيتغير أيضًا، نظرًا لأنهم لن يكون لديهم كلمة مرور عند استخدام العامل الأول:
من حيث الصياغة، لا أحب استخدام مصطلح “Web Authn”؛ فأعتقد أنه قد يُربك المستخدمين النهائيين، لذا يُفضّل استخدام “مفتاح الأمان” أو ما شابه ذلك.
أود بشدة تجنب التفكير في مصطلحات مثل “العامل الأول” أو “المصادقة الخالية من كلمة المرور” في هذه المرحلة؛ فبالنسبة لي، يجب أن نطلق هذه الميزة ونعمل بها لمدة 3-4 أشهر على الأقل قبل حتى النظر في ذلك.
خاصةً أننا ندعم بالفعل تسجيل الدخول عبر البريد الإلكتروني، مما يعني أنه يمكن للمستخدم تقنيًا نسيان كلمة المرور.
أتفق على أن سير العمل يجب أن يكون كالتالي: إذا توفرت لديك واجهات برمجة التطبيقات (APIs) ومفتاح WebAuthn، فحاول استخدام WebAuthn أولاً، لكن امنح المستخدم خيارًا للخروج من هذه العملية. كما يجب مراعاة احتمال امتلاك المستخدم لأكثر من جهاز WebAuthn؛ لذا أنصح باتباع نهج جوجل في التعامل مع هذا الأمر (مثل توفير رابط “اختر خيارًا آخر” أو ما شابه).
أما بالنسبة لشيء أفكر فيه على المدى الطويل كعنصر منفصل، فيمكننا استخدام “تطبيق Discourse” للمصادقة الثنائية (2FA)، وهو ما سيكون رائعًا جدًا @pmusaraj. وهذا قد يجعل استخدام المصادقة الثنائية أكثر شيوعًا وانتشارًا.
في العمل (الذي يُعدّ سياقًا عالي الأمان)، لدينا أيضًا تنبيه يُرسل بريدًا إلكترونيًا إليك بعد مرور 90 يومًا على عدم استخدام مفتاح الأمان، مما يحثك إما على استخدامه أو إزالته من حسابك.
أعتقد أن تنفيذ ذلك بعد 360 يومًا قد يكون فكرة جيدة؟
فكرة رائعة. إن وجود فاصل زمني أقل سيكون مزعجًا لأننا نستخدم جلسات “لانهائية”، وأعتقد أن معظم الأشخاص سيكون لديهم مفتاح يومي بالإضافة إلى مفتاح احتياطي في الدرج. دون احتساب مفاتيح الأمان الأصلية لأجهزة متعددة.
لقد أضفت بصمة Android الخاصة بي، ومفتاح Yubikey عبر NFC ومفتاح Yubikey عبر USB-C، باستخدام Chrome على Android وFirefox على سطح المكتب، وكل شيء يبدو جيدًا حتى الآن.
شكرًا لك يا @Falco ويا @sam على ملاحظاتكما. لم أكن أدرك أن هناك مسارًا مختلفًا لتسجيل الدخول عبر الهاتف المحمول! سأبدأ العمل على هذه الإصلاحات، بما في ذلك تغييرات تسمية كلمة المرور/الأزرار، الليلة، وآمل أن أقوم بفتح طلب سحب (PR) جديد للإصلاح!
أنا سعيد جدًا بأن هذا يعمل على جهاز Android الخاص بك أيضًا (على الرغم من أن العرض على الهاتف المحمول لا يعمل بشكل صحيح) — لم يكن لدي جهاز Android لإجراء الاختبار عليه.
