الخلاصة

  • نقل RFC 2069 كلمة المرور من مسار Basic الواضح إلى challenge-response، لكنه أبقى H(A1) لدى الخادم كمعادل لكلمة المرور داخل realm يجب حمايته كما لو كان كلمة مرور غير مشفرة.
  • ربطت الإجابة الأساسية معرفة السر بـnonce وطريقة HTTP وURI؛ ولم تشفر المحتوى أو تغطِّ تلقائياً كل الحقول أو تثبت قصد الإنسان أو التفويض أو نتيجة التطبيق.
  • يستطيع nonce المرتبط بالعنوان والوقت تحديد نافذة الصلاحية من دون حالة معاملات. أما إثبات أن الاستخدام لم يقع من قبل فيتطلب تذكر الإجابات المقبولة حتى انتهاء المدة.

تحسين حقيقي لا وعد شامل

وصف RFC 1945 Basic بأنه يرسل اسم المستخدم وكلمة المرور بعد تمثيلهما بـBase64. التمثيل ليس تشفيراً؛ من يرى الرأس يستطيع استعادة كلمة مرور قابلة لإعادة الاستخدام. جاء RFC 2069 في يناير/كانون الثاني 1997 ليجعل الخادم يرسل nonce ويجعل العميل يحسب response، فلا تعبر كلمة المرور نفسها الشبكة بنص واضح. وكان RFC 2068 إطار HTTP/1.1 المنشور في الشهر نفسه.

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

الحقول التي دخلت الحساب

استخدم النص MD5 كما عرّفه RFC 1321، وكانت البنية الأساسية:

A1 = username : realm : password
A2 = Method : request-URI
response = KD(H(A1), nonce : H(A2))

وجود realm داخل A1 يقسم مجال السر. ويضع A2 الطريقة والـURI داخل الدليل. ويصل nonce الدليل بالتحدي الذي أصدره الخادم. لذلك يثبت التطابق، في حدوده، أن من أنشأه يملك مادة سرية صالحة لهذا realm ولهذه المدخلات.

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

ولا تشمل الصيغة الأساسية سائر الرؤوس أو مسار النقل أو جواب الخادم. لا تشفر body، ولا تقول إن إنساناً ضغط الزر، ولا تمنح صلاحية تجارية، ولا تثبت commit واحداً. عرّف RFC 2069 حقلاً اختيارياً منفصلاً لـdigest يغطي body وبعض metadata، خصوصاً مع POST وPUT. وجود هذا الخيار يبيّن أن response الأساسي لم يكن توقيعاً لكل رسالة HTTP.

H(A1): قيمة غير مقروءة تفتح الباب

لم يكن الخادم مضطراً إلى حفظ كلمة المرور الصريحة؛ كان اسم المستخدم مع H(A1) كافيين لإعادة الحساب. لكن قسم التخزين قال بوضوح إن من يسرق ملف H(A1) يستطيع الوصول فوراً إلى مستندات realm من دون فك كلمة المرور. ولذلك يجب حماية الملف كأنه يحتوي كلمات مرور غير مشفرة.

وصف H(A1) بأنه «معادل كلمة مرور» مقيد بالـrealm. لأن اسم realm يدخل في التجزئة، لا تعمل القيمة تلقائياً في realm آخر حتى لو تكرر اسم المستخدم وكلمة المرور. لكنها في مجالها قدرة قابلة للتنفيذ: يستطيع حاملها صنع response يقبله الخادم. كما تظل كلمات المرور الضعيفة معرضة للتجربة خارج الشبكة.

هذه نقطة حفظ لا نقطة مصطلحات. نسخة احتياطية أو replica من H(A1) ليست مجرد أثر رياضي. كل نسخة توسع عدد الأنظمة التي تحمل قدرة الدخول إلى realm.

nonce صالح لا يعني nonce غير مستعمل

اقترح RFC 2069 أن يتضمن nonce تجزئة عنوان العميل والطابع الزمني ومفتاحاً خاصاً بالخادم:

H(client-IP : timestamp : server-private-key)

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

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

عندما لا يحتمل التطبيق أي replay، ينبغي استخدام responses لمرة واحدة وتذكر القيم المستخدمة حتى انتهاء nonce. قوة الدليل تأتي هنا من التخزين والبحث والحذف بعد الانتهاء، ومن اتساق الحالة بين عقد الخادم. الـDigest وحده لا يتذكر.

ما أضافته المعايير اللاحقة

حل RFC 2617 محل 2069، كما يؤكد سجله الرسمي. وأضاف qop وcnonce من العميل والعداد nc. يحتفظ الخادم بنسخته من العداد، وعند رؤية القيمة نفسها ثانية يستطيع كشف replay. ويضع qop=auth-int تجزئة body داخل A2. أما عند غياب qop فتبقى صيغة RFC 2069 للتوافق؛ لذلك لا يجوز إرجاع هذه الضمانات إلى نص 1997.

أضاف RFC 7616، مع سجله، SHA-256 وSHA-512/256 وجعل MD5 غير موصى به. ومع ذلك كرر أن ملف H(A1) المسروق يمنح دخولاً مباشراً إلى realm، وأن تغيير الخوارزمية لا يعالج كلمة مرور بشرية ضعيفة، وأوصى باستخدام HTTPS.

يساعد RFC 9110 على حفظ الحد الدلالي: قبول credentials قد يدخل في قرار authorization، لكنه ليس القرار ولا نتيجة التنفيذ.

من التطابق إلى الأثر

إذا نجح Digest لطلب POST /approve، يستطيع السجل أن يقول إن عقدة تحققت من علاقة بين مادة سرية وnonce وطريقة وURI. ولا يزال مطلوباً معرفة algorithm وqop، وهل غُطي body، وأي replay state استُخدم، وإلى أي principal رُبط الاسم، وهل كان مفوضاً، وما transaction الذي التزم، وكم مرة ظهر الأثر.

تطلب فكرة Lu Heng عن Running-Code Primacy النظر إلى التحقق العامل لا الاكتفاء بالنص المنشور. وتفصل Minimum Initial Specification بين القاعدة المشتركة القابلة للتحقق والقرارات المحلية اللاحقة. الصيغة مشتركة؛ أما مدة nonce وحالة replay وحفظ verifier والتفويض فقرارات تشغيلية.

وتمنع ملاحظة Reality Layers تحويل الرمز الصحيح إلى سلطة على طبقات لم ينفذها. تطابق الـDigest دليل واحد، وليس تفويضاً للقول إن القصد والنتيجة صحيحان.

المصادر