مفاتيح المرور وملحق WebAuthn PRF للتشفير من طرف إلى طرف (2025)

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

• حالات استخدام Passkey PRF: ما هي حالات الاستخدام المثيرة للاهتمام لملحق WebAuthn PRF؟
• دعم ملحق PRF: ما هو الدعم الفعلي الحالي لملحق WebAuthn PRF عبر أنظمة التشغيل والمتصفحات اليوم؟

يحلل هذا المقال ملحق WebAuthn PRF، ويستكشف مواصفاته الفنية، وحالات الاستخدام، وتفاصيل التنفيذ، والاعتبارات الأمنية، والمشهد الحالي لدعم المتصفحات وأنظمة التشغيل. نركز على التغييرات في النظام البيئي لعام 2025 ونوسع العمل التأسيسي الذي وضعه Matthew Miller وLevi Schuck في عام 2023، واللذين قدمت مقالاتهما السابقة خلفية تقنية مفصلة وأمثلة حية واختبارات عبر الإنترنت (بما في ذلك التشفير).

يُعرَّف ملحق WebAuthn PRF (PRF) رسميًا في مواصفات WebAuthn المستوى 3. والغرض الأساسي منه هو السماح للطرف المعتمد (تطبيق الويب الخاص بك) بطلب تقييم دالة شبه عشوائية مرتبطة ببيانات اعتماد WebAuthn معينة (مفتاح مرور) أثناء عملية المصادقة (navigator.credentials.get()).

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

تنفذ العديد من أدوات المصادقة، وخاصة مفاتيح أمان FIDO2، قدرة أساسية محددة في بروتوكول العميل إلى أداة المصادقة (CTAP2) تسمى ملحق hmac-secret. يوفر ملحق CTAP2 هذا الوصول إلى وظيفة HMAC (رمز مصادقة الرسائل القائم على التجزئة) المدعومة بالأجهزة، والتي تعمل كدالة شبه عشوائية. يعمل ملحق WebAuthn PRF كطريقة موحدة لتطبيقات الويب للوصول إلى قدرة hmac-secret هذه من خلال واجهة برمجة تطبيقات WebAuthn الخاصة بالمتصفح.

لمنع التعارضات المحتملة أو المشكلات الأمنية حيث قد يخدع موقع ويب أداة المصادقة لتوليد HMACs مخصصة لأغراض غير متعلقة بالويب (مثل تسجيل الدخول إلى نظام التشغيل المحلي)، تفرض مواصفات WebAuthn خطوة مهمة: يتم أولاً تجزئة المدخلات التي يقدمها موقع الويب (الأملاح الأولى والثانية) مع سلسلة سياق محددة ("WebAuthn PRF" وبايت فارغ) قبل تمريرها إلى وظيفة hmac-secret الأساسية. يؤدي هذا إلى تقسيم مساحة إدخال PRF بشكل فعال، مما يضمن أن المخرجات المشتقة من الويب متميزة عن تلك التي قد تستخدم في سياقات أخرى.

تفتح القدرة على اشتقاق مفاتيح مرتبطة بأداة المصادقة العديد من حالات الاستخدام الجذابة للمطورين:

1. التشفير من جانب العميل / من طرف إلى طرف (E2EE): هذا هو الدافع الأساسي لملحق WebAuthn PRF. يمكن للتطبيقات المستندة إلى المتصفح اشتقاق مفتاح تشفير فريد لكل بيانات اعتماد أثناء تسجيل الدخول. يمكن بعد ذلك استخدام هذا المفتاح مع WebCrypto API لتشفير بيانات المستخدم المخزنة محليًا أو على الخادم. تظل البيانات مشفرة في حالة السكون ولا يمكن فك تشفيرها إلا من قبل المستخدم بعد المصادقة بنجاح باستخدام مفتاح المرور المحدد، مما يعزز الخصوصية وأمن البيانات. يمكن لمقدمي الخدمات تخزين بيانات المستخدم دون الوصول إلى النص العادي على الإطلاق. هذا مفيد بشكل خاص للتطبيقات في عالم بدون كلمات مرور، لأنه بدون ملحق PRF، سيحتاجون إلى طلب سر إضافي في شكل كلمة مرور، وهو ما يتعارض مع بنية عدم استخدام كلمات المرور.

2. فك تشفير الخزنة بدون كلمة مرور: يمكن لخدمات مثل مديري كلمات المرور (على سبيل المثال، Bitwarden، 1Password) أو تطبيقات الملاحظات الآمنة (مثل Notesnook، Reflect) استخدام PRF لاستبدال كلمة المرور الرئيسية التقليدية. يقوم المستخدم بالمصادقة باستخدام مفتاح المرور الخاص به، ويقوم ملحق PRF باشتقاق مفتاح فك تشفير الخزنة ويتم فتح الخزنة - لا حاجة لكلمة مرور رئيسية. أعلن Bitwarden عن دعمه لهذه الميزة. علاوة على ذلك، اعتمدت Dashlane مؤخرًا ملحق WebAuthn PRF لتعزيز مقاومة التصيد الاحتيالي وتحسين أمان الوصول إلى الخزائن المشفرة. يقوم المستخدمون بالمصادقة باستخدام مفاتيح المرور الخاصة بهم، مما يسمح لـ PRF باشتقاق مفاتيح فك تشفير الخزنة بأمان، مما يلغي تمامًا الحاجة إلى كلمة مرور رئيسية.

3. تدوير المفاتيح الآمن: يسمح ملحق WebAuthn PRF بتوفير "ملحين" (salt) للإدخال (الأول والثاني) أثناء المصادقة. هذا يسهل مخططات تدوير المفاتيح التشفيرية. يمكن للخادم طلب المفتاح "الحالي" باستخدام الملح الأول والمفتاح "التالي" باستخدام الملح الثاني. بمرور الوقت، يمكن للخادم تحديث الملح الذي يتوافق مع المفتاح الحالي، مما يسمح بالتدوير السلس دون تعطيل تجربة المستخدم. هذا مهم بشكل خاص في حالة وجود متطلبات تنظيمية أو سياسات داخلية تتطلب تدوير جميع المفاتيح ضمن جدول زمني محدد ويزيد من الأمان.

4. محافظ الهوية والأنظمة غير الاحتجازية: يمكن لـ PRF اشتقاق مفاتيح لتأمين بيانات الهوية داخل المحافظ الرقمية أو تمكين الأنظمة غير الاحتجازية حيث لا يتم كشف المفاتيح الخاصة من جانب الخادم أبدًا.

على الرغم من أن المواصفات محددة، إلا أن الدعم الفعلي من المتصفحات والمنصات هو العامل الحاسم للمطورين. لقد كان الدعم يتطور، وحتى وقت قريب، كان يقتصر بشكل أساسي على المتصفحات المستندة إلى Chromium. قد يكون تتبع الدعم أمرًا صعبًا لأنه لا يوجد إدخال مخصص على CanIUse.com لملحق PRF نفسه (يُظهر البحث عن "webauthn" دعمًا عامًا لواجهة برمجة التطبيقات، ولكن ليس ملحقات محددة). يجب غالبًا جمع المعلومات من ملاحظات إصدار المتصفح ومتتبعات الأخطاء وصفحات الحالة. يتطلب استخدام ملحق WebAuthn PRF بنجاح جهدًا منسقًا عبر ثلاث طبقات متميزة من حزمة التكنولوجيا. يجب أن يكون دعم ملحق PRF موجودًا في كل مستوى حتى تعمل الميزة:

1. أداة المصادقة (The Authenticator): هذا هو الجهاز (مثل مفتاح الأمان) أو مكون المنصة (مثل Windows Hello، iCloud Keychain ووحدة الأجهزة المقابلة مثل TPM أو Secure Enclave) الذي يخزن بأمان المفتاح السري لبيانات الاعتماد ويقوم بحساب الدالة شبه العشوائية الفعلي (عادةً باستخدام قدرة CTAP2 hmac-secret). إذا كانت أداة المصادقة تفتقر إلى هذه القدرة التشفيرية الأساسية، فلا يمكن لـ PRF العمل.

2. نظام التشغيل (The OS): يعمل نظام التشغيل كجسر بين المتصفح وأداة المصادقة. يوفر برامج التشغيل اللازمة وواجهات برمجة التطبيقات على مستوى النظام للمتصفح لاكتشاف أدوات المصادقة والتواصل معها وطلب العمليات منها (خاصة أدوات المصادقة الخاصة بالمنصة وتلك المتصلة عبر USB/NFC/Bluetooth). يجب أن يكون نظام التشغيل قادرًا على التعرف على قدرة PRF (hmac-secret) الخاصة بأداة المصادقة وكشفها للمتصفح. إذا لم يوفر نظام التشغيل هذا المسار، فلن يتمكن المتصفح من الوصول إلى الميزة.

3. المتصفح (The Browser): كواجهة لتطبيق الويب، يجب على المتصفح تنفيذ واجهة برمجة تطبيقات WebAuthn JavaScript، وتحديدًا التعرف على ملحق prf، وترجمة طلب الويب إلى الأوامر المناسبة لنظام التشغيل/أداة المصادقة، والتعامل مع الخطوة الأمنية الحاسمة المتمثلة في تجزئة المدخلات مع سلسلة السياق، وتحليل النتائج وإعادتها بشكل صحيح إلى التطبيق.

سيؤدي الفشل أو نقص الدعم في أي من هذه المستويات الثلاثة - قدرة أداة المصادقة، أو كشف نظام التشغيل، أو تنفيذ المتصفح - إلى منع ملحق PRF من العمل.

يوضح مخطط التسلسل هذا نسخة مبسطة لكيفية عمل هذه الجهات الفاعلة معًا لتسهيل دعم PRF.

يتطلب سير عمل PRF الفعال تعاون كل طبقة في سلسلة WebAuthn ↔ CTAP. للتوضيح، نفصل المناقشة إلى (1) سلوك المتصفح + نظام التشغيل و (2) سلوك أداة المصادقة.

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

أدناه، نقوم بتفصيل الدعم حسب نظام التشغيل.

دعم ملحق WebAuthn PRF على Windows محدود، حيث تفتقر أداة المصادقة الأصلية للمنصة (Windows Hello) حاليًا إلى قدرة hmac-secret اللازمة. وبالتالي، تعتمد وظيفة PRF على مفاتيح الأمان الخارجية.

مع macOS 15، وصل دعم PRF لأدوات مصادقة المنصة. يدعم كل من Safari و Chrome PRF عبر iCloud Keychain. لا يزال دعم Firefox لأداة مصادقة المنصة معلقًا. تعمل مفاتيح الأمان فقط مع Chrome.

يعكس الوضع على iOS و iPadOS نظام macOS، حيث يعمل PRF عبر iCloud Keychain. ومع ذلك، هناك محاذير كبيرة: يمكن أن يؤدي خطأ في الإصدارات المبكرة من iOS 18 إلى فقدان البيانات، ولم يتم تنفيذ دعم مفاتيح الأمان الخارجية بعد.

يقدم Android حاليًا الدعم الأكثر قوة وانتشارًا لملحق WebAuthn PRF. تتضمن مفاتيح المرور المخزنة في Google Password Manager دعم PRF افتراضيًا، ويعمل عبر معظم المتصفحات الرئيسية، باستثناء Firefox.

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

بينما تحدد WebAuthn ماذا يمكن للطرف المعتمد أن يطلب، يحدد بروتوكول العميل إلى أداة المصادقة (CTAP) كيف يجب أن تتصرف أداة المصادقة. في الممارسة العملية، تقع أدوات المصادقة في أربع فئات:

1. لا يوجد دعم لـ PRF: أدوات مصادقة المنصة القديمة (مثل Windows Hello)، ومفاتيح الأمان القديمة بدون ملحق hmac-secret ومقدمو الخدمات من الطرف الثالث الذين لم يعتمدوا ملحق prf بعد.

2. PRF فقط إذا تم تعيين علامة PRF عند إنشاء بيانات الاعتماد: تعرض بعض مفاتيح أمان CTAP 2.0/2.1 hmac-secret، لكنها سترفض تقييمات PRF ما لم يطلبها الطرف المعتمد عند إنشاء بيانات الاعتماد لأول مرة لتهيئة الأسرار.

3. PRF متاح عند المصادقة حتى لو لم يتم طلبه عند الإنشاء: تعرض رموز الأجهزة من الجيل الجديد و iCloud و Google Password Manager وظيفة hmac-secret دون قيد أو شرط؛ لا تزال بيانات الاعتماد التي تم إنشاؤها بدون العلامة تعمل مع PRF أثناء navigator.credentials.get().

4. توافق كامل مع CTAP 2.2 (PRF + أول قيمة PRF عند الإنشاء): يمكن لأدوات مصادقة المنصة التي تزامن مفاتيح المرور - مثل iCloud Keychain و Google Password Manager - عند الطلب، إرجاع أول ناتج PRF بالفعل أثناء navigator.credentials.create()، مما يبسط تدفقات إنشاء المفاتيح.

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

يمكنك تجربة ملحق WebAuthn PRF مباشرة باستخدام تطبيقنا التوضيحي التفاعلي لـ WebAuthn PRF. في هذا العرض التوضيحي، ستتمكن من:

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

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

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

هل أنت مستعد لاختبار قوة PRF؟ انقر على الصورة أعلاه أو اتبع هذا الرابط لبدء استكشافك العملي.

ملحق WebAuthn PRF ليس ملحق WebAuthn الوحيد المتعلق بتخزين أو اشتقاق البيانات. كيف يُقارن passkey PRF بالبدائل الأخرى؟

• PRF مقابل credBlob / largeBlob:

  • credBlob: يسمح بتخزين كتلة بيانات ثابتة صغيرة (32 بايت) مع بيانات الاعتماد، ربما في وقت الإنشاء. لم يتم تصميمه بشكل أساسي للأسرار، والدعم محدود، خاصة لبيانات الاعتماد غير القابلة للاكتشاف.

  • largeBlob: يتيح تخزين المزيد من البيانات (حوالي 1 كيلوبايت) مع بيانات الاعتماد القابلة للاكتشاف، وغالبًا ما يكون مخصصًا للبيانات المساعدة مثل الشهادات. الدعم محدود أيضًا (مدعوم من iCloud Keychain منذ iOS 17، ولكن ليس من GPM). فضل مطورو Chrome صراحة التركيز على PRF بدلاً من largeBlob لمعظم حالات الاستخدام، على الرغم من أن التطوير قد يحدث في المستقبل.

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

• PRF مقابل المفاتيح المشتقة من كلمة المرور (مثل PBKDF2): تقليديًا، كانت مفاتيح التشفير من جانب العميل تُشتق من كلمات مرور المستخدم. يقدم PRF مزايا كبيرة:

  • مصدر أقوى: تُشتق المفاتيح من مادة تشفير قوية داخل أداة المصادقة، وليس من كلمات مرور قد تكون ضعيفة أو معاد استخدامها.

  • مقاومة التصيد الاحتيالي: يرتبط الاشتقاق بتدفق مصادقة WebAuthn المقاوم للتصيد الاحتيالي.

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

• PRF مقابل بيانات WebAuthn الأخرى: محاولة اشتقاق المفاتيح من أجزاء أخرى من استجابة WebAuthn (مثل التوقيع، أو authenticatorData، أو المفتاح العام) غير آمنة وغير صحيحة بشكل أساسي. هذه المكونات إما عامة أو غير سرية أو مصممة للتحقق، وليس لاشتقاق المفاتيح.

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

عند دمج ملحق PRF في تطبيقك، نوصي باتباع هذه الإرشادات العملية:

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

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

• تجنب الاعتماد الحاسم على PRF: تجنب جعل PRF ضروريًا للوظائف الحيوية. لا يزال الدعم الحالي، خاصة على منصات مثل Safari على macOS و iOS، غير متسق وغير مكتمل.

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

• توقع دعمًا أوسع بحلول عام 2026: ينضج دعم ملحق PRF بسرعة. بحلول عام 2026، توقع توفرًا ثابتًا عبر المتصفحات الرئيسية وأنظمة التشغيل وأدوات المصادقة، خاصة مع مزودي مفاتيح المرور من الطرف الأول.

• راقب النظام البيئي لـ Windows: دعم أداة مصادقة المنصة عبر Windows Hello غائب حاليًا. يعتمد دمج PRF الكامل في بيئات Windows بشكل كبير على استراتيجية تبني Microsoft، لذا راقب هذا النظام البيئي عن كثب.

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

يساعدك فهم كيفية توافق PRF مع استراتيجية مفاتيح المرور الشاملة على تعظيم فوائده دون تعقيدات غير ضرورية:

• دمج مرن: ليس من الضروري تحديد ما إذا كنت ستستفيد من PRF في لحظة إنشاء مفتاح المرور. يمكن دمج مفاتيح المرور الحالية لاحقًا بسلاسة مع حالات استخدام PRF دون عبء إضافي لإدارة بيانات الاعتماد.

• تعديل PRF لاحقًا: نظرًا لأن PRF يعمل أثناء مرحلة المصادقة (navigator.credentials.get())، يمكن لمفاتيح المرور التي تم إنشاؤها مسبقًا دعم مهام سير العمل القائمة على PRF في مرحلة لاحقة. يتيح هذا لتطبيقك تعزيز الأمان بشكل تدريجي دون تعطيل طرق المصادقة المعمول بها. يعمل هذا النهج مع iCloud Keychain و Google Password Manager (GPM) ومفاتيح الأمان الأحدث. بالنسبة لمفاتيح الأمان القديمة، قد يتم إنشاء hmac-secret فقط إذا طُلب عند إنشاء بيانات الاعتماد.

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

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

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

إليك كيف يمكن لـ Corbado مساعدة المؤسسات التي تتطلع إلى دمج PRF:

• تسهيل PRF للتخزين المشفر: في إعدادات المؤسسات، هناك أحيانًا شرط لتخزين المعلومات الحساسة بشكل آمن، وربما في بعض الأحيان مباشرة على جانب العميل لتقليل تعرض PII من جانب الخادم. يمكن تكوين Corbado Connect لطلب قيم PRF أثناء تدفق مصادقة مفتاح المرور (navigator.credentials.get())، مما يمكّن التطبيقات من اشتقاق مفاتيح التشفير اللازمة.
• أنماط تخزين مرنة: يمكن تخزين البيانات المشفرة باستخدام مفاتيح مشتقة من PRF بطرق مختلفة اعتمادًا على متطلبات الأمان والبنية:
  • جانب العميل: يتم تخزينها مباشرة في المتصفح باستخدام آليات مثل localStorage أو ملفات تعريف الارتباط الآمنة. توجد البيانات النصية العادية فقط بشكل عابر على العميل أثناء فك التشفير.
  • الواجهة الخلفية لـ Corbado (E2EE): بينما يتجنب Corbado عمومًا تخزين PII للعملاء، تسمح آلية PRF تقنيًا بتخزين البيانات المشفرة من جانب العميل على خوادم Corbado. لن يمتلك Corbado المفاتيح لفك تشفير هذه البيانات؛ سيظل فك التشفير يحدث من جانب العميل بعد مصادقة المستخدم الناجحة.
  • الواجهة الخلفية للعميل: يمكن أيضًا إرسال البيانات المشفرة وتخزينها على أنظمة الواجهة الخلفية الخاصة بالمؤسسة، مع الاستفادة من التشفير من جانب العميل.
• تدفق اشتقاق المفاتيح الآمن: تدير مكونات Corbado Connect التفاعل مع واجهة برمجة تطبيقات WebAuthn. عند طلب PRF:
  1. يتم إنشاء ناتج PRF خاص بالمستخدم بواسطة أداة المصادقة، مرتبط بمفتاح المرور الفردي.
  2. يتم إرجاع هذا الناتج بأمان إلى التطبيق من جانب العميل.
  3. يجب على التطبيق بعد ذلك استخدام دالة اشتقاق المفاتيح (KDF) عبر WebCrypto API (مثل HKDF) لاشتقاق مفتاح تشفير متماثل قوي من ناتج PRF.
  4. يتم استخدام هذا المفتاح المتماثل مع WebCrypto (مثل AES-GCM) لتشفير أو فك تشفير المعلومات المستهدفة (مثل PII).
• فك تشفير سلس عند تسجيلات الدخول اللاحقة: عندما يقوم المستخدم بالمصادقة مرة أخرى باستخدام نفس مفتاح المرور، يبدأ Corbado Connect نفس طلب PRF. ينتج عن هذا ناتج PRF مطابق، مما يسمح للتطبيق بإعادة اشتقاق نفس المفتاح المتماثل وفك تشفير المعلومات المخزنة مسبقًا من جانب العميل.
• ذكاء تبني PRF: يتطلب تنفيذ PRF معرفة ما إذا كانت بيئة المستخدم (نظام التشغيل، المتصفح، أداة المصادقة) تدعمه. يجمع Corbado Connect إشارات حول جهاز المستخدم وقدراته أثناء المصادقة. يمكن استخدام هذا الذكاء من أجل:
  • تحديد جاهزية PRF عبر قاعدة المستخدمين قبل التفعيل الكامل للميزات المعتمدة على PRF.
  • تنفيذ PRF بشكل انتهازي، وتوفيره كتحسين للمستخدمين المدعومين مع الحفاظ على آليات احتياطية (مثل المطالبة بإعادة التحقق أو استخدام طرق بديلة) لأولئك الذين لا يدعمونه.
• تبسيط توفر PII: باستخدام PRF لتشفير PII التي تم التحقق منها (مثل سمات الهوية التي تم الحصول عليها من خلال تدفق التحقق) وتخزينها من جانب العميل، يمكن للتطبيقات إتاحة هذه البيانات على الفور بعد تسجيل الدخول بمفتاح المرور للتفاعلات أو المعاملات اللاحقة، مما يقلل بشكل كبير من الاحتكاك مقارنة بإعادة التحقق أو التدفقات القائمة على التطبيق.
• تمكين أنظمة E2EE المخصصة: بينما يقدم Corbado Connect مكونات واجهة مستخدم للتدفقات القياسية، يمكن للمبادئ الأساسية أن تسمح للمطورين بدمج وظيفة PRF بشكل أعمق في التطبيقات الحساسة. يتيح هذا بناء أنظمة مشفرة من طرف إلى طرف حيث يستفيد تطبيق الواجهة الأمامية مباشرة من المفاتيح المشتقة من PRF لعمليات تشفير معقدة على البيانات الحالية أو الجديدة. في الوقت الحالي، سيظل هذا ممكنًا فقط بشكل انتهازي ويجب تنفيذ آليات احتياطية بطريقة مختلفة لتخزين تلك المعلومات.

يهدف Corbado إلى تبسيط تعقيدات دمج مفاتيح المرور و PRF، مما يسمح للمؤسسات بالاستفادة من المعايير بشكل آمن وفعال، والتكيف مع حالات الاستخدام المحددة مثل تشفير PII من جانب العميل أثناء التنقل في المشهد المتطور.

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

للإجابة مباشرة على الأسئلة المطروحة في بداية هذا المقال:

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

• الحالة الحالية لدعم PRF (يونيو 2025): لا يزال الدعم مجزأ ومتطورًا. بينما يتمتع Android بدعم قوي عبر المتصفحات وأدوات المصادقة، فإن منصات مثل macOS وخاصة iOS غير مستقرة، لا سيما كمصدر CDA مع خطأ فادح. يقتصر دعم Windows بشكل أساسي على مفاتيح الأمان الخارجية، مع غياب ملحوظ لدعم المنصة الأصلي عبر Windows Hello.

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