هل تعمل مفاتيح المرور (Passkeys) في وضع التصفح المتخفي؟

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

في هذا المقال، نحاول الإجابة على الأسئلة التالية:

1. هل تعمل مفاتيح المرور في وضع التصفح المتخفي / الخاص؟
2. كيف يكون سلوك المصادقة باستخدام مفاتيح المرور في الوضع المتخفي / الخاص في متصفحات Chrome وSafari وEdge وFirefox؟

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

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

عادةً، تُخزَّن مفاتيح المرور بشكل آمن داخل الجهاز، وتظل وظيفتها ثابتة حتى في أوضاع التصفح المتخفي أو الخاص لمعظم أنظمة التشغيل باستثناء Windows 10 (كما سنرى أدناه)، شريطة أن يكون الجهاز جاهزًا لاستخدام مفاتيح المرور.

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

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

يساعد فهم سلوك مفاتيح المرور في مختلف المتصفحات وأنظمة التشغيل على ضمان التوافق وتجربة مستخدم سلسة.

هل تعمل مفاتيح المرور في وضع التصفح المتخفي / الخاص؟

في نظام التشغيل Windows 10 (22H2)، اكتشفنا الاستثناء الوحيد لعدم عمل مفاتيح المرور بشكل موثوق، وحصلنا على لقطتي الشاشة التاليتين عند محاولة استخدام أداة مصادقة المنصة (Windows Hello):

رسالة خطأ مفتاح المرور في وضع التصفح المتخفي لمتصفح Chrome على نظام Windows 10

رسالة خطأ مفتاح المرور في وضع InPrivate لمتصفح Edge على نظام Windows 10

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

علاوة على ذلك، عندما حاولنا استخدام أداة مصادقة عبر المنصات (مثل مفتاح الأمان المادي، مثل YubiKey، أو المصادقة عبر الأجهزة باستخدام رمز QR / البلوتوث)، فقد نجح الأمر.

عند التعمق أكثر في المشكلة وتنفيذ الأمرين التاليين في وحدة تحكم المتصفح لتحديد ما إذا كانت أداة مصادقة المنصة (PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()) وواجهة المستخدم الشرطية (PublicKeyCredential.isConditionalMediationAvailable()) متاحتين، قمنا باكتشاف مثير للاهتمام: الوعد الأول أعاد القيمة false، بينما أعاد الثاني القيمة true، وهو أمر غير منطقي، حيث إن أدوات المصادقة الخاصة بالمنصة مطلوبة لكي تعمل واجهة المستخدم الشرطية.

بدءًا من إصدار Chrome 129 (وبشكل مشابه في Edge، المبني على Chromium)، تُرجع الدالة PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() القيمة true حتى في وضع Incognito / InPrivate على نظام Windows 10. سابقًا، كانت هذه القيمة false في وضع التصفح المتخفي. على الرغم من أنها تُرجع الآن القيمة true، تظل أداة مصادقة المنصة غير متاحة لإنشاء مفاتيح مرور جديدة، مما يؤدي إلى تجربة مستخدم معطلة.

فيما يلي جدول يوضح القيم التي تُرجعها الدالة PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() على نظام Windows 10 في إصدارات وأوضاع مختلفة من Chrome/Edge:

السلوك الملحوظ:

• في وضع Incognito لمتصفحي Chrome/Edge على نظام Windows 10، على الرغم من أن الوعد يُرجع القيمة true، لا تظهر أداة مصادقة المنصة لـإنشاء مفتاح المرور.
• بدلاً من ذلك، يُطلب من المستخدمين إضافة مفتاح أمان (مثل YubiKey)
• بينما لا تزال مفاتيح الأمان المادية تعمل لـإنشاء مفتاح المرور، فإن هذا ليس هو التدفق المتوقع عند استخدام أدوات مصادقة المنصة مثل Windows Hello.

تأثير التغيير: هذا يعطل فعليًا تدفق إضافة مفاتيح المرور إلى أداة مصادقة المنصة في وضع Incognito/InPrivate. تم إجراء التعديل في Chrome 129+ بشكل أساسي لتمكين وظيفة تسجيل الدخول باستخدام مفاتيح المرور في وضع Incognito. تستخدم تدفقات تسجيل الدخول نفس آلية الكشف للتحقق من دعم مفاتيح المرور (PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable())، ويضمن هذا التغيير أن عمليات تسجيل الدخول يمكن أن تتم بسلاسة. ومع ذلك، فإن النتيجة غير المقصودة هي التجربة المعطلة لإنشاء مفاتيح المرور باستخدام أداة مصادقة المنصة في أوضاع التصفح الخاص.

يمكن العثور على مزيد من التفاصيل حول هذا التغيير في مراجعة كود مصدر Chromium ومناقشة تتبع المشكلات المرتبطة به. بالنسبة للمواقع التي تهدف إلى توفير دعم أمثل لمفاتيح المرور، فإن اكتشاف وضع التصفح المتخفي هو حاليًا الطريقة الوحيدة للتخفيف من هذه المشكلة. من خلال تحديد متى يكون المستخدم في وضع Incognito/InPrivate على نظام Windows 10 مع Chrome/Edge، يمكن للمواقع تجنب عرض خيارات أداة مصادقة المنصة لـإنشاء مفتاح المرور بشكل استباقي.

عند استخدام Windows Hello كأداة مصادقة للمنصة، تظهر نافذة منبثقة أمنية أثناء إنشاء مفتاح المرور في وضع التصفح المتخفي (على Chrome) / وضع InPrivate (على Edge)، لتنبيه المستخدمين بأن مفتاح المرور سيتم تخزينه وسيكون قابلاً للاستخدام لاحقًا في وضع التصفح غير المتخفي (تم اختبار هذا السلوك على Windows 11 22H2). بالنظر إلى إحدى حالات استخدام وضع التصفح المتخفي، حيث يرغب المستخدم في إنشاء حساب دون ترك أي أثر للمعلومات، فإن هذا التحذير منطقي.

على نظام Android وباستخدام وضع التصفح المتخفي (على Chrome) / وضع InPrivate (على Edge)، يكون السلوك مشابهًا لنظام Windows 11، حيث تظهر نافذة منبثقة إعلامية تخبر المستخدم بأن مفتاح المرور سيتم حفظه في مدير كلمات المرور وأن أي شخص لديه حق الوصول إلى مدير كلمات المرور سيكون لديه أيضًا حق الوصول إلى مفتاح المرور.

باختصار، تعمل مفاتيح المرور بشكل موثوق في أوضاع التصفح المتخفي والخاص عبر معظم المتصفحات وأنظمة التشغيل الرئيسية، مع بعض الاستثناءات المحددة على نظام Windows 10 لإنشاء مفاتيح المرور. من خلال الاستفادة من حلول Corbado، يمكن للمطورين تطبيق مفاتيح المرور بكفاءة، ويمكن لمديري المنتجات تحسين تجارب المستخدم دون المساومة على الأمان.