Wednesday, September 9, 2020

استكشاف ClientDataJSON في WebAuthn

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

لبدء سلسلتنا ، نتعمق في ملف clientDataJSONcode> موضوع كجزء من مصادقة الويب أو مواصفات WebAuthn . يعد WebAuthn معيارًا مثيرًا حظي بالكثير من الاهتمام ، ولكن غالبًا ما يكون البدء به معقدًا.

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

الـ clientDataJSON الكائن هو مفتاح تبادل بيانات واجهة برمجة تطبيقات WebAuthn. إذا كنت تقوم بإنشاء تطبيق سطح مكتب أو جوال ، فإن إنشاء ملف clientDataJSON كائن يجب أن يتم باستخدام مكتبة أو SDK.

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

ما هو WebAuthn؟

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

الفكرة وراء WebAuthn هي تخليص العالم من مصادقة كلمة المرور (شيء تعرفه) عن طريق استبدالها بـ مصادقة المفتاح العام (شيء لديك).

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

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

أثناء مصادقة المستخدم ، يرسل الخادم تحديات زائفة تم إنشاؤها عشوائيًا إلى العميل حتى يوقعها المصدق. التوقيع ، الذي يأخذ تجزئة لملف clientDataJSON جنبا إلى جنب مع authenticatorDatacode> ، تم التوقيع عليه بواسطة المفتاح الخاص. يثبت هذا التوقيع حيازة المفتاح الخاص ويؤكد أن التحدي ومعرف الطرف المعتمد (RP) والأصل لم يتم العبث بها ، كل ذلك دون مشاركة المفتاح الخاص أو مطالبة المستخدم بتوفير كلمة مرور ثابتة. إعادة الهجمات يتم منعها بواسطة العشوائية الزائفة للتحدي. هجمات التصيد يتم منع هذا التوقيع على التحدي باستخدام المفتاح الخاص الذي تم تحديد نطاقه لمعرف RP (المجال). بالإضافة إلى تدابير مواجهة هجمات إعادة التشغيل والتصيد الاحتيالي ، تمنع واجهة برمجة تطبيقات مصادقة الويب أيضًا بيانات الاعتماد المخترقة (اسم المستخدم + كلمة المرور) حيث لا يتم تمرير كلمة المرور أو تخزينها من قبل RP ، ومن هنا جاء مصطلح “بدون كلمة مرور”.

ما هو ClientDataJSON؟

على مستوى عالٍ ، فإن مواصفات WebAuthn هي في الحقيقة مجرد تبادل للتحديات والاستجابات التي يتم إجراؤها خلال نوعين من الاحتفالات ؛ التسجيل والمصادقة. الـ clientDataJSON موضوع، يسكنها العميل دائمًا (متصفح أو تطبيق) ، استجابة لخادم RP أثناء التسجيل والمصادقة.

الكائن الذي يملأه العميل ثلاث خصائص مطلوبة : أ اكتب ، أ التحدي ، و الأصل . الـ اكتب يمكن للإثنين webauthn.create“لاستجابة التسجيل أو”webauthn.get“لاستجابة المصادقة. الـ التحدي value هي التحدي الفعلي الذي أرسله RP أثناء خلق أو احصل على مراسم. الـ الأصل يحتوي على اسم المجال الفعال لنقطة النهاية التي يتصل بها العميل أثناء تسجيل WebAuthn أو المصادقة.

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

ClientData استخدام حالات JSON

الـ clientDataJSON يستخدم لتحديد الحالة أو التدفق الحالي لحفل WebAuthn. الـ اكتب تخبر السمة RP ما إذا كانت بيانات العميل هذه عبارة عن استجابة تسجيل أو مصادقة لتحدي الخادم.

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

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

clientDataJSON Properties

ال clientDataJSONcode> الكائن (بعد فك التشفير) له الخصائص التالية:

خاصيةتعريفمطلوب / اختياري
اكتبيحتوي على سلسلة بإحدى القيمتين:

مطلوب القيم): ” webauthn.createcode> “أو” webauthn.getcode>

webauthn.createcode> “← يتم إنشاء بيانات اعتماد جديدة أثناء التسجيل.

webauthn.getcode> ← يتم استرداد بيانات الاعتماد الموجودة أثناء المصادقة

مطلوب
التحدي ال قاعدة 64url نسخة مشفرة من تحدي التشفير مرسلة من خادم الطرف المعتمد (RP). يتم تمرير قيمة التحدي الأصلية عبر الطرف المعتمد (RP) من خلاله PublicKeyCredentialRequestOptions.challenge أو PublicKeyCredentialCreationOptions.challenge . مطلوب
الأصلالمجال الفعال للطالب الذي يمنحه العميل / المستعرض للمصدق. مطلوب

تشفير وفك العميل DataJSON Properties

مع ثلاث سمات رئيسية فقط ، فإن clientDataJSON الكائن واضح ومباشر ؛ ومع ذلك ، وفقًا لمواصفات W3C ، يتم تحويل سلسلة JSON إلى ملف ArrayBuffer قبل نقلها مرة أخرى إلى RP ثم إعادتها إلى سلسلة على جانب الخادم قبل التحقق من الصحة. الـ ArrayBuffer يتم استخدامه لتحقيق الكفاءة والأداء الأمثل عند التحدث الثنائي إلى المصادقين.

التحويل من وإلى ArrayBuffer هو الأكثر إرباكًا للمطورين. الخبر السار هو أنه بالنسبة لمعظم حلول WebAuthn ، يمكن للمطورين الاعتماد على ملف واجهة برمجة تطبيقات مصادقة الويب تدعم متصفح الويب كعميل للتعامل مع المصدق الخارجي. نفذت هذه المتصفحات بالفعل متطلبات واجهة برمجة تطبيقات العميل باستخدام امتداد مواصفات FIDO2 Client to Authenticator Protocol (CTAP). CTAP هو بروتوكول طبقة تطبيق يُستخدم للاتصال بين عميل (مستعرض) أو نظام أساسي (نظام تشغيل) مع مصدق خارجي مثل YubiKey.

إذا كنت تنشئ تطبيقًا للهاتف المحمول أو سطح المكتب أو إنترنت الأشياء دون استخدام متصفح ، فستحتاج إلى تنفيذ CTAP Authenticator API باستخدام أ مكتبة ، أو SDK للجوال لـ iOS أو ذكري المظهر .

على جانب الخادم ، يتلقى RP الكائن كملف ArrayBuffercode> ويجب فك تشفيرها وتحليلها.

هذا ما تجزئة clientDataJSONcode> الكائن في استجابة العميل يبدو كما لو استلمه الطرف المعتمد أثناء التسجيل :

إليك ما يبدو عليه كائن clientDataJSON المجزأ في استجابة العميل عند تلقيه من قبل الطرف المعتمد أثناء التسجيل:

إليك ما تم تحليله clientDataJSONcode> يبدو الكائن كسلسلة JSON:

إليك ما يبدو عليه كائن clientDataJSON الذي تم تحليله كسلسلة JSON:

في الأمثلة أدناه ، يقوم الخادم بتحويل ملف ByteArraycode> إلى كائن JSON ثم تحليل البيانات والتحقق منها.

هنا أ جافا مثال على كيفية عمل Yubico عرض خادم جافا يتعامل مع clientDataJSONcode> :

فيما يلي مثال على Java يوضح كيفية تعامل العرض التوضيحي لـ Yubico Java Server مع العميل DataJSON:

هنا أ جافا سكريبت مثال من دليل مطور Firefox :

إليك مثال على JavaScript من دليل مطور Firefox:

اعتماد الطرف المعتمد على عميل WebAuthnDataJSON

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

ال الأصل القيمة هي أهم عملية تحقق. حدد متصفح العميل أو التطبيق نقطة النهاية / المجال أثناء طلب المصادقة على الخادم. يجب أن يتحقق الخادم بعد ذلك من أن “origin ”تطابق سلسلة فرعية على الأقل من سلسلة المجال الصالحة لـ RP كجزء من الاعتماد على معرف الطرف (معرف RP).

الختام

الـ clientDataJSON يتكون من ثلاث سمات مطلوبة فقط ولكنه يلعب دورًا مهمًا في تدفق مصادقة الويب بين العميل والخادم. في هذا المنشور ، علمنا أن هذا الكائن يتم ملؤه بواسطة العميل أثناء تدفقات التسجيل والمصادقة من أجل تحديد اكتب حفل (التسجيل أو المصادقة) ، و الأصل للعميل المتصل والحالية التحدي من الخادم. يتم نقل البيانات كملف ArrayBuffer بواسطة العميل ثم يقوم الخادم بفك تشفيرها وتحليلها. يمكن لـ RP رفض أي محاولات مصادقة إذا كان كائن العميل غير مشفر بشكل صحيح ، أو يحتوي على اختبار غير صحيح ، أو أن أصل العميل لا يتطابق مع المجال (معرف RP) المرتبط بسلسلة JSON.

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

مصادر

دليل مطور Yubico WebAuthn
W3C مواصفات WebAuthn
Mozilla MDN Web Docs
Yubico iOS SDK – عميل WebAuthn
المجمع Github WebAuthn API غلاف WebAuthn API الذي يترجم من / إلى JSON الخالص باستخدام base64url
خادم Yubico WebAuthn (جافا)

بواسطة Dennis Hills at 2020-08-11 19:00:12 المصدر Yubico:
استكشاف ClientDataJSON في WebAuthn | يوبيكو

No comments:

Post a Comment

كيف يتغلب التصيد الاحتيالي الحديث على المصادقة متعددة العوامل الأساسية | يوبيكو

قبل عامين ، في مؤتمر أمان الإنترنت Black Hat US ، تمت دعوة فريق Yubico للتحدث عن كيفية عمل التصيد الاحتيالي المتقدم وكيف يمكن لمعايير مصادق...