RFC 3112: مطابقة كلمة المرور لم تكن مصادقة

الخلاصة

قسّمت RFC 3112 القيمة المشتقة إلى scheme ومعلومات خاصة به وقيمة مصادقة، وكلها حساسة لحالة الأحرف. كان يمكن لقاعدة المطابقة أن تعيد TRUE أو FALSE أو Undefined، لكن ذلك وصف مقارنة لا ارتباط LDAP مصادَقًا عليه.
أوجبت الوثيقة تنفيذ Bind لإتمام المصادقة. وبما أن السمة تقبل عدة قيم، استطاع من يملك سلطة الكتابة إضافة كلمة مرور ثانية صالحة من غير تعطيل كلمة المرور التي يعرفها المستخدم.

إجابة صحيحة في آلة حالات أخرى

يرسل العميل كلمة مرور إلى قاعدة مطابقة في LDAP. يعثر الخادم على قيمة مخزنة، ويقرأ scheme والـsalt، ويحسب الناتج المتوقع، ثم يعيد true. لقد طابق السر. ومع ذلك، لم يُصادَق على العميل في الدليل بعد.

هذه الحدود هي قلب RFC 3112 التاريخي. نُشرت «LDAP Authentication Password Schema» في مايو 2001 بصفة Informational، وقدّمت طريقة لحفظ معلومات مشتقة من كلمة المرور بدلًا من كلمة المرور الفعلية التي كان استعمال userPassword في سياق ذلك الزمن يفترضها. عرّفت صياغة وقاعدتي matching وسمة قدرات في root DSE وobject class مساعدة. وبعد أن جعلت الاختبار ممكنًا، منعت توسيع معناه: نجاح authPasswordMatch بواسطة Compare أو Search لا يكفي لدخول الدليل؛ فلا بد من Bind.

تجيب المقارنة وBind عن سؤالين مختلفين. تقرر المطابقة هل تتفق السلسلة المقدمة مع قيمة محفوظة واحدة على الأقل وفق آليتها. ويقرر Bind هل قبل الخادم authentication identity لهذا الارتباط. ثم تقرر سياسة الوصول ما الذي تستطيع authorization identity الناتجة فعله. ويظل التطبيق خارج الدليل مسؤولًا عن فعله التجاري.

إذا اختصر السجل هذه المراحل في «نجح الدخول»، ضاع الدليل. قد تنجح المطابقة من دون Bind. وقد ينجح Bind بينما تُرفض كتابة. وقد تنجح قراءة LDAP من دون أن تكتمل العملية التي يراها المستخدم.

حملت القيمة اسم طريقة حسابها

تكوّنت authPasswordSyntax من ثلاثة أجزاء يفصل بينها رمز الدولار: scheme وauthInfo وauthValue. سمّى الأول الآلية؛ وحمل الثاني غالبًا salt مرمّزًا بـbase64؛ وحمل الثالث المادة المشتقة من كلمة المرور.

أتاحت هذه البنية وجود آليات مختلفة في دليل واحد. عرّفت RFC 3112 الاسمين MD5 وSHA1، وطلبت من schemes الخاصة بادئة X- أو OID. أما supportedAuthPasswordSchemes، المسموح بها فقط في root DSE، فكانت تعلن الأسماء التي يقول الخادم إنه يدعمها.

لم يكن الإعلان سجل تنفيذ. لم يثبت أي scheme اختير لمصادقة بعينها، ولا من كتب القيمة، ولا فرادة الـsalt، ولا حماية القناة، ولا القيم التي اختُبرت، ولا نجاح Bind. القدرة المعلنة ليست أثرًا للعملية.

ويجب إبقاء التاريخ ظاهرًا. طبقت آليتا MD5 وSHA-1 في الوثيقة digest على كلمة المرور متبوعة بالـsalt. وجب ألا يقل الـsalt عن 64 bit، وأن تدعم التنفيذات حتى 128 bit. هذه مواصفة من عام 2001 لا إرشاد حديث لتخزين كلمات المرور. جعلت RFC 8018 الـsalt وعدد الدورات معلمين صريحين في تقنيات كلمة المرور، وحددت RFC 9106 دالة Argon2 الصعبة على الذاكرة وفضّلت Argon2id للـpassword hashing واشتقاق المفاتيح. لا تعيد النصوص اللاحقة كتابة الوثيقة القديمة، لكنها تمنع وصف قيمة بأنها «مشفرة بأمان» من غير تسمية الآلية وكلفتها.

مساواة الترميز واختبار السر وBind

قارنت authPasswordExactMatch الأجزاء المرمّزة نفسها. إذا وُجدت قيمة لها scheme وauthInfo وauthValue نفسها فالنتيجة true؛ وإن لم توجد فـfalse؛ وما عدا ذلك undefined. كانت هذه مساواة بين تمثيلين.

أما authPasswordMatch فتلقى كلمة مرور بواسطة extensible-match filter، وطبق scheme كل قيمة مخزنة. كفت مطابقة واحدة لإرجاع true؛ وفشل جميع القيم أعاد false؛ والعجز عن إتمام الاختبار أعاد Undefined.

لم تحدد أي نتيجة الشخص الجالس أمام لوحة المفاتيح. لا تثبت true من يسيطر على القناة ولا حقه في الاختبار. ولا تثبت false أن entry الصحيحة اختيرت أو عدم وجود مخزن خارجي. وليست Undefined كلمة مرور خاطئة؛ بل تحفظ حقيقة أن الخادم لم يصل إلى قرار.

منع شرط Bind نتيجة المقارنة من تجاوز سلطتها. وصفت RFC 4511 لاحقًا نتيجة Bind في مراجعة LDAP، وفصلت RFC 4513 بين authentication identity وauthorization identity. قد تُشتق الثانية من الأولى، أو تُطلب منفصلة بآلية مناسبة، لكن على الخادم التحقق من حق العميل في تمثيلها.

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

قيم متعددة تعني أبوابًا متعددة

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

ذكرت RFC الهجوم صراحة: من يحصل على write access يستطيع إضافة قيمة من غير تعطيل كلمة المرور الحقيقية للمستخدم. يستمر الضحية في الدخول بصورة عادية، فلا يظهر reset أو lockout، بينما يبقى الباب الإضافي مفتوحًا.

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

كانت RFC 3062 قد عرّفت Password Modify extended operation. استطاع الخادم وفق قواعده تحديد الهدف وقبول كلمة جديدة أو توليدها واختيار تخزينها. أمكن جمعها مع RFC 3112، لكن السمة وحدها لم تكن دورة حياة كاملة للحساب.

كما أمكن الجمع بين authPassword وuserPassword ومخزن خارجي. لذلك لم تكن رؤية قيمة واحدة أو حذفها وصفًا لكل طرق المصادقة أو إبطالًا لها.

ظلت القيمة المشتقة سرًا

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

احتاج assertion في authPasswordMatch إلى الحماية نفسها؛ فهو محاولة كلمة المرور نفسها. قد تكشفها قناة غير محمية، وقد تتحول المقارنة المفتوحة إلى oracle للتخمين.

أضافت كلفة الحساب خطر availability. ترفع الآلية الثقيلة ثمن التخمين، لكنها تتيح أيضًا استهلاك CPU الخادم. rate limit وميزانية التوازي والمهلة وحق استدعاء المقارنة أجزاء من السياسة الفعلية. لا يثبت اسم scheme وجود هذه الضوابط.

تغير السياق وبقي الفصل

قارنت RFC 3112 اقتراحها بـuserPassword في سياق RFC 2251 وRFC 2252 وRFC 2256. لا يجوز تحويل ذلك إلى قاعدة دائمة. أوضحت RFC 4519 لاحقًا أن قيم userPassword لا يلزم أن تكون clear text ولا أن تصلح لـBind، كما طورت التنفيذات صيغها الخاصة.

وتمنع صفة Informational الادعاء بالانتشار. يثبت سجلا RFC Editor وIETF Datatracker النشر والتاريخ. تضع RFC 2829 وRFC 4513 كلمة المرور ضمن نموذج الأمن، وتبين RFC 4511 وRFC 4517 وRFC 4519 مسار البروتوكول وقواعد المطابقة والـschema. لا يثبت أي مصدر أن دليلًا بعينه فعّل authPassword.

الدرس الباقي هو فصل الأدلة. لإثبات أن شخصًا «دخل»، ينبغي حفظ entry وتاريخ تعديلها، وscheme والـsalt والمعلمات، وإذن Compare أو Search، والقناة، والطلب ونتيجته true أو false أو undefined، والقيم المختبرة، وطلب Bind وآليته وجوابه، وهويتي المصادقة والتفويض، والعملية التالية وقرار الوصول ونتيجة التطبيق.

كان يمكن لكلمة المرور أن تطابق تمامًا. أدركت RFC 3112 أن هذا الصدق يجب أن يتوقف قبل باب Bind.

طابقت كلمة المرور، لكن المستخدم لم يُصادَق عليه بعد: RFC 3112

لماذا هذا مهم

الخلاصة

إجابة صحيحة في آلة حالات أخرى

حملت القيمة اسم طريقة حسابها

مساواة الترميز واختبار السر وBind

قيم متعددة تعني أبوابًا متعددة

ظلت القيمة المشتقة سرًا

تغير السياق وبقي الفصل

المصادر

سياق أعمق للملف الشخصي

الدائرة الاستراتيجية

تحالف القيادات

إحاطة الدائرة الاستراتيجية

إحاطة تحالف القيادات