الخلاصة

  • تتيح RFC 9807 التسجيل والمصادقة من دون كشف كلمة المرور للخادم، لكن تسرب سجل المستخدم والأسرار اللازمة من خادم منفرد يظل يتيح هجوم قاموس شاملاً خارج الاتصال على ذلك الحساب.
  • قد تكون مفاتيح OPRF منفصلة لكل مستخدم فيما تنحدر كلها من oprf_seed مشتركة؛ أما البذور المستقلة والاستجابات الوهمية وOPRF العتبي وإعادة التسجيل فتنقل المخاطر وتضيف التزامات جديدة.

قد تكون الجملة الأمنية صحيحة تماماً، ومع ذلك تعجز عن وصف النظام.

القول إن «الخادم لا يرى كلمة المرور» صحيح في OPAQUE. لكنه لا يجيب عمن يملك الجذر الذي تُشتق منه مفاتيح OPRF، ولا عن عدد الحسابات المرتبطة بذلك الجذر، ولا عما إذا كانت قاعدة السجلات ومفتاح AKE والبذرة تمر عبر مسار الاستعادة الإداري نفسه. كما لا يثبت إمكان نقل الحسابات الخاملة إلى إعداد جديد أثناء أزمة.

تصف RFC 9807، المنشورة في يوليو 2025، بروتوكول OPAQUE لتبادل المفاتيح المعزّز والمصادق عليه بكلمة مرور. يستخدم العميل دالة شبه عشوائية غافلة وغلافاً لاستعادة بيانات الاعتماد وتبادل مفاتيح مصادقاً عليه. يثبت معرفته بكلمة المرور ويتوصل إلى مفتاح جلسة مشترك من دون تسليم الكلمة، حتى في مرحلة التسجيل.

وللوثيقة حدود مؤسسية واضحة أيضاً. تصنفها صفحة RFC Editor وDatatracker وثيقة Informational ضمن مسار IRTF وتمثل توافق Crypto Forum Research Group. وينص متنها على أنها ليست منتجاً لـ IETF وليست معياراً. الربط بدليل IETF يفيد الاكتشاف، لكنه لا يمنحها صفة Standards Track.

ما الذي لم يعد يعبر إلى الخادم؟

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

يغيّر OPAQUE الشيء الذي يعبر الحد. في OPRF الموصوفة في RFC 9497، يحتفظ الخادم بمفتاح الدالة ويرسل العميل مدخلاً معمّى. يحصل العميل على الخرج، بينما لا يعرف الخادم المدخل ولا الخرج. ثم ينفذ العميل عملية التقوية ويبني الغلاف الذي يحمي مادة المصادقة.

تجري مرحلة الاتصال عبر KE1 ثم KE2 ثم KE3. لا تكتمل المصادقة الصريحة للعميل قبل الرسالة الثالثة. لذلك لا يمثل إرسال KE2 نجاحاً؛ الإثبات يتطلب KE3 صحيحة ونجاح ServerFinish. ويتلقى العميل session_key مشتركة وexport_key لا يملكها الخادم. لا يقرر أي منهما صلاحية عملية تجارية؛ المصادقة والتفويض إيصالان مختلفان.

التخمين لم يختفِ

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

ترفع KSF هذه التكلفة. تقترح RFC 9807 إعدادات تستخدم Argon2id أو scrypt، وتقدم RFC 9106 إرشادات Argon2. لكن الحساب يجري عند العميل. زيادة الذاكرة والوقت تعاقب المهاجم، وتعاقب كذلك الهاتف المحدود والجهاز المضمّن ومسار الاسترداد. الدليل المطلوب هو زمن الذيل والذاكرة ونسبة الفشل على أضعف الأجهزة المدعومة، لا متوسط حاسوب حديث.

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

جذر واحد وراء مفاتيح منفصلة

ينشئ الخادم زوج مفاتيح AKE وoprf_seed. وتنتج البذرة مع معرّف اعتماد فريد مفتاح OPRF مختلفاً لكل عميل. الأوراق منفصلة، لكن الجذر قد يكون واحداً.

توصي RFC 9807 ببذرة مشتركة عند تطبيق آلية منع تعداد المستخدمين، ثم تذكر صراحة أن تسربها يضر بأمن جميع العملاء المعتمدين عليها. ولهذا قد يكون وصف «مفتاح لكل مستخدم» صحيحاً حسابياً ومضللاً تشغيلياً.

حللت دراسة 2024، (Strong) aPAKE Revisited، النسخة متعددة المستخدمين في سلالة المسودة. لا تقول إن البذرة وحدها تكشف كل الكلمات. يكشف ملف مستخدم مخترق الجذر العام؛ يشتق المهاجم منه مفتاح مستخدم آخر؛ ثم توفر معاملة عادية واحدة مع الخادم الصادق المادة الإضافية اللازمة لنقل التخمين ضد ذلك المستخدم إلى وضع خارج الاتصال. يستشهد النص النهائي بالدراسة ويذكر النتيجة العابرة للحسابات.

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

يسأل مبدأ أولوية الشيفرة العاملة السؤال الواقعي: أي مسؤول أو عملية أو نسخة احتياطية أو بيئة محصنة تستطيع إعادة تكوين مفاتيح كم حساب؟

إخفاء وجود الحساب عقد منفصل

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

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

تحتاج masking_key إلى السرية أثناء التسجيل. تشير RFC إلى TLS وإلى HPKE لإضافة السرية فوق قناة مصادق عليها. إخفاء كلمة المرور لا يبرر إهمال المراسم التي تثبت بقية أسرار الحساب.

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

ثلاثة مجالات للحراسة

تمنح بذرة OPRF ومفتاح AKE الخاص وقاعدة RegistrationRecord قدرات هجومية مختلفة. تسمح RFC بحفظ مفتاح AKE داخل HSM غير قابل للتصدير، مع إتاحة عملية السر المشترك فقط. وقد يمنع ذلك انتحال الخادم بعد تسرب البذرة والأغلفة، لكنه لا يمنع تلقائياً تخمين الكلمات الذي تتيحه مادة OPRF والسجلات.

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

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

أما HKDF والتحويل إلى المنحنيات في RFC 9380 ومتطلبات PAKE في RFC 8125، فهي مكونات لازمة وليست شهادة على تركيب خدمة بعينها.

إعادة التسجيل هي الهجرة

تغيير KSF أو الخوارزميات أو المادة المرتبطة بـRegistrationRecord مثل المفتاح العام للخادم يتطلب سجلاً جديداً. كما أن تغيير كلمة المرور تسجيل جديد بعشوائية جديدة. تكشف هذه القاعدة كلفة «المرونة التشفيرية» التي يخفيها نشر برنامج جديد.

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

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

الإيصال هو سجل أفواج: الحسابات المؤهلة، السجلات الجديدة، القديمة المقبولة، الخاملة، إخفاقات الاسترداد، الأجهزة العاجزة عن KSF الجديدة، اعتماد البيانات على مفتاح التصدير السابق، استخدام التراجع، وتاريخ إبطال مواد OPRF وAKE والسجلات القديمة.

يجيب OPAQUE بقوة عن سؤال محدود: هل يمكن المصادقة بكلمة مرور من دون تسليمها للخادم ومن دون حساب مسبق قابل لإعادة الاستخدام؟ نعم ضمن النموذج المعلن. الخطأ القيادي هو تحويل هذه الإجابة إلى شهادة سلامة عامة.

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

Sources