WebAuthn في الحياة الحقيقية

في سبتمبر 2019 ، دعم فريق Mail.ru Mail تقنية WebAuthn. أصبحنا أول خدمة بريد إلكتروني في العالم نفذت القدرة على تسجيل الدخول إلى حسابك باستخدام المفاتيح الإلكترونية بدلاً من كلمات المرور. الآن هذه الفرصة متاحة لجميع مستخدمينا ، يمكنك ربط المفتاح الإلكتروني لحسابك في الإعدادات وبعد ذلك استخدامه بحرية للدخول.



لقد كتبنا بالفعل أخبارًا عن هذا الحدث هنا ، على حبري. في هذه المقالة ، أود أن أتحدث أكثر عن أسباب تطبيق WebAuthn في خدماتنا وعن الجوانب التقنية للعمل مع هذه التقنية.

ما هو WebAuthn ولماذا هو مطلوب


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

ومع ذلك ، غالبًا ما تفوق عيوب كلمات المرور مزاياها:

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

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

شركات مثل Microsoft و Yahoo و Amazon في استخدام طرق المصادقة بدون كلمة مرور وتتخلى تمامًا عن استخدام كلمات المرور في خدماتها. بريد Mail.ru ليس استثناء، لدينا منذ وقت طويل دعم تسجيل الدخول باستخدام رموز لمرة واحدة ، والتي تسمح للمستخدمين بعدم تذكر كلمات المرور المعقدة والقوية والوصول بسرعة إلى حساباتهم.

بديل آخر لكلمات المرور هو المصادقة باستخدام المفاتيح الإلكترونية (مفاتيح الأمان ، اسم آخر - المصادق الإلكتروني). يعتمد مبدأ تشغيله على استخدام التشفير غير المتماثل ويتم وصفه في عائلة بروتوكول FIDO2 ، التي طورها تحالف FIDO (Fast IDentity Online).

في مارس 2019 ، أصدر W3C الإصدار الأول من المعيار.، الذي يصف واجهة برمجة تطبيقات JS المستندة إلى المستعرض والتي تتيح لك التفاعل مع المفاتيح الإلكترونية. تلقى المعيار حالة التوصية واسم مصادقة الويب: واجهة برمجة التطبيقات للوصول إلى بيانات الاعتماد باستخدام مفتاح عام: المستوى الأول (مصادقة الويب: واجهة برمجة تطبيقات للوصول إلى بيانات اعتماد المفتاح العام المستوى 1) - باختصار ، WebAuthn.

كيف يعمل WebAuthn


تم تحديد الجهات الفاعلة الرئيسية التالية في عملية المصادقة باستخدام WebAuthn:

  • Client (WebAuthn Client) - متصفح يدعم WebAuthn API ؛
  • تطبيق ويب - تطبيق قيد التشغيل على العميل باستخدام WebAuthn API للتفاعل مع بيانات الاعتماد ؛
  • بيانات الاعتماد (بيانات اعتماد المفتاح العام) - زوج من مفاتيح التشفير العامة والخاصة المرتبطة بحساب المستخدم ؛
  • أداة المصادقة - جهاز أو برنامج - تنشئ بيانات اعتماد المستخدم وتوقع الطلبات من جهة الاعتماد باستخدام بيانات الاعتماد هذه (اسم آخر هو مفتاح إلكتروني) ؛
  • يقوم الطرف المعتمد (WebAuthn Relying Party) - خادم الويب - بتخزين المفتاح العام المرتبط بحساب المستخدم ، والتحقق من صحة التوقيع على طلباتهم باستخدام المفتاح الخاص المخزن في المصدق.

يسمح لك WebAuthn API بتنفيذ عمليتين فقط. يسمح لك بإنشاء بيانات اعتماد جديدة وتوقيع الطلبات من الخادم باستخدام بيانات الاعتماد التي تم إنشاؤها بالفعل.

إنشاء أوراق الاعتماد ( MakeCredential )



مخطط المرحلة مع إنشاء أوراق الاعتماد ، مأخوذة من w3.org .

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

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

توقيع طلب باستخدام بيانات اعتماد تم إنشاؤها بالفعل ( GetAssertion )



مخطط المرحلة مع التحقق من أوراق الاعتماد ، مأخوذة من w3.org .

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

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

يمكنك مشاهدة عرض توضيحي لعملية إدخال بريد Mail.ru باستخدام WebAuthn في هذا الفيديو .

يمكنك معرفة المزيد عن WebAuthn API نفسها في مواصفات WebAuthn ، على سبيل المثال ، في هذه المقالة المتوسطة .

لذا ، فإن عمل WebAuthn يعتمد على استخدام المفاتيح الإلكترونية. ما هذا؟

مفاتيح إلكترونية


المفاتيح الإلكترونية (سأطلق عليها أحيانًا أيضًا "مفاتيح WebAuthn" ، مفتاح الأمان) هي الأجهزة أو البرامج التي تطبق بروتوكولات تفاعل FIDO2.

في مواصفات WebAuthn وعلى مستوى الأسرة ، يتم تصنيف جميع المفاتيح الإلكترونية في إحدى الفئتين:

  • المفاتيح المستقلة عن المنصة (المصادقون المتجولون) ؛
  • مصادق النظام الأساسي

المفاتيح المستقلة عن النظام الأساسي هي أجهزة مادية خارجية ، مثل Yubikey من Yubico أو Titan Security Key من Google. عادة ، يتم توصيل هؤلاء المصادقين بجهاز كمبيوتر المستخدم أو الهاتف الذكي عبر USB أو NFC أو BLE. يتم الاتصال بهذه الأجهزة باستخدام بروتوكول CTAP الخاص (Client to Authenticator Protocol).

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


أمثلة على مختلف المنصات - مفاتيح مستقلة مأخوذة من theverge.com .

إذا كانت آلية تشغيل النوع الأول من المفاتيح أكثر أو أقل وضوحًا ، فعندئذ أريد أن أطيل في مزيد من التفاصيل حول الفئة الثانية.

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

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


استخدام المصادقات الخاصة بالنظام الأساسي.

يتم إرجاع معلومات المفتاح العام المشفرة فقط أو رمز عشوائي موقّع إلى خدمة الويب من WebAuthn API ، والتي يتم تخزينها وفحصها من جانب الخادم.

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

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

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

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

فوائد WebAuthn


ما هي فوائد تقنية WebAuthn للمستخدمين والمطورين؟

  • لا يحتاج المستخدم إلى تذكر وإدخال أي كلمات مرور ، ولا يقوم الخادم بتخزين كلمات مرور المستخدم ، على التوالي ، وجميع أوجه القصور التي اختفتها كلمات المرور. يعد سرقة المصدق المادي من المستخدم أكثر صعوبة من اعتراض كلمة المرور التي يتم إرسالها إلكترونيًا عبر اتصال غير آمن ، ولن يؤدي فتح المفاتيح العامة على الموقع إلى فتح المفتاح الخاص المخفي في الجهاز.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • يوفر WebAuthn نفسه كواجهة برمجة تطبيقات للمطورين تجريدًا حول تطبيق المصادقين ويسمح لك بكتابة التعليمات البرمجية مرة واحدة ، والتي ستعمل بعد ذلك مع جميع أنواع وأنواع المفاتيح الإلكترونية. وبالتالي يعد WebAuthn حلاً قابلاً للتطوير لمصادقة المستخدم.

المزيد حول سبب كون WebAuthn أكثر أمانًا من كلمة المرور - WebAuthn للمطورين: 5 خطوات لتحسين المصادقة ، الشروع في العمل باستخدام مفاتيح الأمان .

دعم WebAuthn


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

في وقت كتابة هذا التقرير ، وفقًا لموقع caniuse.com ، يدعم WebAuthn API 80.5٪ من المستخدمين. وفقًا للإحصاءات حول مستخدمي Mail.ru ، فإن هذا الرقم له نفس الترتيب - 79.8 ٪. ومع ذلك ، من أجل استخدام WebAuthn في جميع هذه المتصفحات ، ستحتاج بالتأكيد إلى مفتاح إلكتروني خارجي.

لا يمكن لجميع المتصفحات التي تدعم WebAuthn API العمل مع المفاتيح المعتمدة على النظام الأساسي (للراحة ، سأشير إلى هذه المفاتيح باسم "بصمات الأصابع" لاحقًا). بالإضافة إلى ذلك ، للعمل مع هذه المفاتيح ، لا يكفي تثبيت متصفح يمكنه العمل معها. من الضروري أيضًا أن يكون جهازك ونظام التشغيل لديك وحدة / جهاز استشعار مناسب وأن يكون قادرًا على التفاعل معه. من بين جميع مستخدمي Mail.ru ، يمتلك 9.0٪ فقط القدرة على إضافة مفاتيح خاصة بالنظام الأساسي.

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

شبابيك


دعم WebAuthn على Windows جيد جدًا. يمكن أن يعمل النظام الفرعي لمصادقة Windows Hello مع المفاتيح الإلكترونية. لذلك ، تدعم جميع أحدث إصدارات المتصفح لنظام التشغيل هذا - Microsoft Edge و Google Chrome و Opera و Mozilla Firefox - العمل مع كل من المفاتيح الخارجية وبصمات الأصابع. لا يدعم Internet Explorer API WebAuthn.


لينكس


عادةً ما يتم دعم المصادقين الخارجيين بواسطة أي توزيعات Linux حديثة ، بالإضافة إلى المتصفحات مثل Google Chrome و Chromium و Mozilla Firefox. ومع ذلك ، في بعض الأنظمة ، قد تكون هناك حاجة إلى إعدادات إضافية للعمل مع المفاتيح الخارجية .

ذكري المظهر


دعم WebAuthn على Android جيد أيضًا. Google Chrome و Opera و Mozilla Firefox - دعم العمل مع المفاتيح الخارجية وبصمات الأصابع. لكن Microsoft Edge لنظام Android لا يدعم WebAuthn API على الإطلاق. هناك أيضًا خطأ في Firefox - تحديد النوع المفضل للمصدق باستخدام الخيار لا يعمل من أجله authenticatorAttachment.


iOS


من بين جميع المتصفحات لنظام التشغيل iOS ، يدعم WebAuthn الإصدار 13.3 من Safari للجوال فقط. علاوة على ذلك ، يمكنه العمل فقط مع المفاتيح الإلكترونية الخارجية. لا تدعم المتصفحات الأخرى لنظام iOS WebAuthn على الإطلاق.

macOS


يدعم كل من Microsoft Edge و Google Chrome و Opera و Mozilla Firefox العمل مع المفاتيح الخارجية على macOS. يدعم Google Chrome أيضًا البصمات ، مما يسمح لك باستخدام WebAuthn مع Touch ID.


إذا كانت واجهة التفاعل مع WebAuthn هي نفسها في Edge و Opera و Chrome ، فإن Firefox قد ميز نفسه هنا. بدلاً من نافذة منبثقة جميلة في Firefox ، عند استخدام WebAuthn ، يظهر إشعار صغير في زاوية الشاشة. إذا نقرت دون قصد على صفحة ، فإنه ينهار ببساطة ، مما يترك المستخدم في حيرة مما يحدث الآن.



ومع ذلك ، لم يدعم Safari WebAuthn بعد. تم الإعلان عن دعم WebAuthn في Safari 13 ، والذي سيكون متاحًا على macOS 10.15 Catalina. ومع ذلك ، في وقت كتابة هذا التقرير ، أظهرت الشيكات أن واجهة برمجة تطبيقات WebAuthn في Safari ، على الرغم من وجودها ، غير مستقرة للغاية ولا تعمل مع جميع المصادقين. مثل إصدار الهاتف المحمول ، لا يعمل Safari مع المفاتيح الإلكترونية المدمجة. بالإضافة إلى ذلك ، لا يدعم حتى الآن أيًا من المفاتيح الإلكترونية الأجنبية.

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

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

تسجيل الموثق


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

تم تصميم واجهة برمجة تطبيقات WebAuthn بحيث لا يكون العميل متاحًا عند إنشاء واستخدام بيانات الاعتماد ، أي معلومات حول نوع ونوع واسم أدوات المصادقة المستخدمة. وفقًا لذلك ، ليس لدينا أي بيانات يمكننا من خلالها التمييز بين مفتاح وآخر. سيتم تقديم جميع المفاتيح في القائمة بالتساوي دون تمييز الميزات. السؤال: ماذا تفعل؟


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

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

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

حقيقة أن المعلومات المتاحة للعميل والخادم لا تحتوي على أي بيانات حول نوع المصادق تؤدي إلى ميزة أخرى غير سارة في WebAuthn.

تخيل مستخدمًا أضاف بصمة إصبع واحدة إلى حسابه ، على سبيل المثال ، في هاتفه الذكي. عندما نريد تسجيل الدخول باستخدام WebAuthn API ، نقوم بتمرير استدعاء دالةnavigator.credentials.getقائمة بجميع المفاتيح المرتبطة بحساب. ولكن لا يمكن للمتصفح تحديد من هذه القائمة المصادق الموجود على الجهاز وغير الموجود. لذلك ، يضطر دائمًا إلى عرض المستخدم لاستخدام WebAuthn.

لذلك ، حتى عند محاولة تسجيل الدخول إلى حساب على جهاز كمبيوتر لا يدعم المصادقة من خلال بصمات الأصابع ، سيظل المستخدم معروضًا لاستخدام WebAuthn.

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

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

لم يتلق مستخدمونا حتى الآن شكاوى حول هذا السلوك ، لذلك نحن نحقق حاليًا في هذه الميزة ونقرر ما يجب فعله في المستقبل.

يعمل WebAuthn على نطاقات فرعية مختلفة


كما قلت سابقًا ، يوفر WebAuthn الحماية من التصيد الاحتيالي. عند تسجيل المفاتيح الإلكترونية ، يتم تخزين المعلومات originالتي تم تسجيل هذا المفتاح عليها. لا يسمح WebAuthn باستخدام هذا المفتاح الإلكتروني في الموارد مع مصدر آخر origin.

غالبًا ما تستخدم خدمات الويب الكبيرة مثل Mail.ru عدة نطاقات مختلفة لعملها. على سبيل المثال ، لدينا مجال e.mail.ruللبريد cloud.mail.ruوللحوسبة السحابية. ولكل منهم شكل مشترك من التفويض. في هذه الحالة ، إعدادات WebAuthn القياسية ليست كافية. حتى نتمكن من استخدام originالمفاتيح المسجلة على الآخر في أحدهما origin، من الضروري أن يكون لهما مجالان لاحقة مشتركة (نطاق فرعي مشترك أكثر من المستوى الأول).

على سبيل المثال في المجالاتe.mail.ruو cloud.mail.ruلاحقة الشائعة mail.ru.

في هذه الحالة ، عند التسجيل واستخدام المفاتيح الإلكترونية ، يمكننا تحديد معلمة rpIdمتساوية في خيارات الطلب mail.ru، وبعد ذلك يمكننا استخدام نفس المفتاح على https://mail.ruالنطاق الفرعي نفسه وعلى أي من مفاتيحه.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

يعمل WebAuthn في iframe


لأسباب أمنية ، يُحظر الاتصال بطرق WebAuthn من داخل إطارات iframe مشتركة المصدر. تستخدم مشاريعنا نموذج تفويض واحد ، وهو موجود على https://account.mail.ru/login ، وعندما نريد إظهار نموذج التفويض في أي مشروع آخر ، على سبيل المثال ، في البريد أو في السحابة ، تتم إضافة iframe بالفعل إلى الصفحة بداخله يفتح عنوان url هذا. يتيح لنا هذا الحل تحديث النموذج نفسه في الوقت نفسه على جميع المشاريع التي تستخدمه ، كما يبسط جمع الإحصاءات ، ويحسن أيضًا تجربة المستخدم ، مما يسمح له بالبقاء في الخدمة نفسها حيث كان في الأصل.



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

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

توصلنا إلى وتنفيذ الآلية التالية:

  1. في تطبيق التفويض عند استخدام WebAuthn ، نحدد ما إذا كنا مفتوحين الآن داخل iframe أم لا ؛
  2. إذا كنا منفتحين داخل iframe ، فبدلاً من استدعاء المتصفح WebAuthn API ، نقوم بتسلسل معلمات الاتصال وإرسالها عبر postMessageالنافذة الرئيسية ؛
  3. في النافذة الرئيسية ، نقوم بإلغاء تسلسل هذه المعلمات واستدعاء أساليب WebAuthn ؛
  4. عندما نتلقى إجابة ، نقوم بتسلسلها بنفس الطريقة وإرسالها عبر postMessageداخل iframe ، حيث نقبل هذه الإجابة ونجري مزيدًا من المعالجة.

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

أتمتة اختبار WebAuthn


في فريقنا لجميع المشاريع والميزات الجديدة ، نكتب دائمًا الاختبارات التلقائية لواجهة مستخدم التكامل باستخدام حلول تشبه السيلينيوم وبروتوكول WebDriver. لذلك ، أثناء تطوير WebAuthn ، نشأ سؤال حول كيفية كتابة autotests UI.

تكمن صعوبة كتابة مثل هذه الاختبارات التلقائية في أن بروتوكول WebDriver ليس لديه حتى الآن طرق لأتمتة التفاعل مع WebAuthn. وفي المعيار نفسه لا يوجد حتى الآن دعم لاختبار WebAuthn API لأتمتة (ولكن هناك مشكلة حول هذا الموضوع). تم وصف الأفكار الأولى حول كيفية تنظيم هذه الأتمتة في مسودة مصادقة الويب: واجهة برمجة تطبيقات للوصول إلى بيانات اعتماد المفتاح العام المستوى 2 ولم يتم نشرها بعد ، ناهيك عن دعمها في مكان آخر. لذلك ، كان عليّ أن أتوصل إلى حلول بديلة.

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

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

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

بعد ذلك ، نحتاج إلى الحصول على نتيجة الوظيفة بطريقة ما لإعادتها لمحاكاة عمل WebAuthn في الاختبارات. يمكننا دائمًا إعادة نوع من الإجابة الثابتة المشفرة.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

في هذه الحالة ، سيتعين علينا تعليم خادمنا قبول هذه الإجابة وعدم التحقق من صحتها ، ولكن نعتبرها صحيحة تلقائيًا.

ما هي عيوب مثل هذه الاختبارات؟ في هذه الحالة ، لن نتمكن من:

  • تحقق مما إذا كان العميل يقوم بشكل صحيح بتكوين المعلمات ولفها في وظائف WebAuthn ؛
  • تحقق من صحة تغييرات الواجهة الخلفية عند تدوير إصدارات الخلفية.

وبالتالي ، فإن هذه الاختبارات لن تكون موثوقة بما فيه الكفاية ، وهذا لا يناسبنا.

قررنا المضي في الطريق الأكثر صعوبة ، ونتيجة لذلك ، كتبنا تنفيذنا الخاص لبروتوكولات وخوارزميات FIDO2 على Node.js ، والتي تمكننا من قفل هذه الوظائف في أقرب وقت ممكن من عمليات التنفيذ الأصلية.

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

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

ونتيجة لذلك ، فإن مخطط عملية الاختبار التلقائي على النحو التالي:

  1. الحصول على الحجج التي تم استدعاء أساليب WebAuthn معها ؛
  2. ندير هذه الحجج من خلال دالة تنفذ نفس الخوارزميات داخل المصدقين الحقيقيين ؛
  3. نحصل على النتيجة ، ونعيدها من وظائفنا المستبدلة ؛
  4. تعالج جميع التعليمات البرمجية المتبقية في خدمتنا هذه الاستجابات في الوضع المعتاد ونتيجة لذلك ، لا يختلف كل سلوك الخدمة عن سلوكها للمستخدمين الحقيقيين.

توجد مصادر مثل هذا الاختبار التلقائي وتنفيذ المصدق الأكثر سرية في مستودع github ، يمكنك البدء والتحقيق في عملهم لاحقًا. عند كتابة المصدق ، لم نسترشد إلا بمواصفات w3.org ووثائق Node.js.

حاضر ومستقبل WebAuthn


لذا ما لدينا في الوقت الراهن.

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

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

لماذا أصبح WebAuthn الآن ميزة ليست لجمهور عريض؟

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

يمكن أن تحدث قفزة كبيرة إلى الأمام في شعبية WebAuthn عندما يكمل مهندسو Google تطوير واختبار إمكانية استخدام الهواتف الذكية على Android و iOS كمفاتيح إلكترونية خارجية فعلية لـ WebAuthn وفتح هذه الفرصة لجميع خدمات الإنترنت. في هذه الحالة ، سيحصل كل مالك لهاتف ذكي حديث على فرصة استخدامه كمفتاح WebAuthn وسيزداد عدد مستخدمي WebAuthn بشكل كبير. الآن هذه الميزة متاحة فقط لمستخدمي خدمة البريد الإلكتروني من Google.



كيف يمكنك استخدام WebAuthn؟


يستخدم Mail.ru WebAuthn الآن كبديل لكلمات المرور لإدخال الحساب. ولكن بشكل أساسي يمكن استخدام WebAuthn مثل أي من عوامل التفويض. يمكن استخدامه بدلاً من العامل الأول في المصادقة بعامل واحد. لذلك بدلاً من الثانية - كحماية كلمة مرور إضافية بعاملين. بالإضافة إلى ذلك ، يمكن استخدام التأكيد عبر مفتاح إلكتروني ، على سبيل المثال ، عند استعادة الوصول إلى حساب إذا فقد المستخدم كلمة المرور أو نسيها.

يمكن استخدام WebAuthn كإجراء أمني إضافي عند تعديل الإعدادات المهمة لحسابك. تخيل مدى ملاءمتها - تذهب إلى إعدادات الملف الشخصي في الخدمة المفضلة لديك ، ولا تحتاج إلى تذكر وإدخال كلمة مرور لتغييرها! ما عليك سوى وضع إصبعك على الماسح الضوئي لبصمات الأصابع ، وسيتم تمريرك.

يمكنك العثور على المزيد من السيناريوهات المختلفة لاستخدام WebAuthn في هذه المقالة المتوسطة .

أسئلة وأجوبة شائعة


أين يمكنني شراء مفتاح إلكتروني؟


حتى الآن ، لا توجد أماكن كثيرة في روسيا حيث يمكنك شراء مفاتيح إلكترونية متوافقة مع بروتوكولات FIDO2. يبيعها معظم الموردين بكميات كبيرة فقط ، على دفعات من 10 أو أكثر. يمكنك شراء مفاتيح إلكترونية قطعة قطعة في المتاجر التالية:


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

ماذا لو فقدت مفتاحي الإلكتروني؟


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

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

ماذا أفعل إذا تمكن شخص آخر من الوصول إلى مفتاحي الإلكتروني؟


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

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

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

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

الآن سيتم تخزين البيانات البيومترية الخاصة بي على Mail.ru/Google/Microsoft خوادم؟


عندما يعمل WebAuthn مع المصادقين المضمنين (على سبيل المثال ، باستخدام Touch ID على نظام التشغيل Mac OS) ، فقط المستشعر المقابل ونظام التشغيل نفسه يمكنه الوصول إلى بيانات المقاييس الحيوية الخاصة بك. لا تتلقى خدمة الويب أو تعالج أي معلومات بيومترية ؛ فهي تعمل فقط مع مفتاح التشفير العام ومع البيانات الموقعة بالمفتاح الخاص.

وعلى الخادم نفسه ، يتم تخزين المعلومات حول المفتاح العام فقط. لذلك ، لا يستخدم WebAuthn بيانات المقاييس الحيوية الخاصة بك بأي شكل من الأشكال للعمل مع المصادقين المدمجين.

استنتاج


كما اكتشفنا ، يتمتع WebAuthn بالعديد من المزايا المهمة على كلمات المرور:

  • عند استخدام WebAuthn ، لا يلزم تذكر كلمات المرور وإدخالها ؛
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn — .

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

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

آمل أن تساعدنا تجربتنا في تنفيذ WebAuthn في Mail.ru Mail على دعمه في خدماتك ، وسنعمل معًا على جعل الإنترنت أكثر أمانًا وحداثة!

مواد إضافية



All Articles