الخلاصة

  • يعبّر nc عن عدد الطلبات التي يقول العميل إنه أرسلها باستخدام nonce الموجود في الطلب الحالي؛ ولا يستطيع الخادم كشف القيمة المكررة إلا إذا احتفظ بالحالة المقابلة.
  • تربط معادلة Digest العدّاد بمادة مشتقة من بيانات الاعتماد وبقيم nonce وعناصر HTTP مختارة، من دون أن تحوّله إلى معرّف عالمي أو قرار تفويض أو سجل تنفيذ للتطبيق.
  • تحتاج العملية ذات الأثر إلى هوية دائمة ونتيجة قابلة للاستعلام بصورة مستقلة. نجاح مصادقة محاولة جديدة لا يثبت أن المحاولة السابقة لم تُحدث أثراً.

رقم يبدأ من واحد ولا يبدأ تاريخ العمل

يرسل العميل في أول طلب مرتبط بقيمة nonce الحقل nc=00000001، ثم يزيد القيمة السداسية عشرية. إذا كان الخادم يحتفظ بنسخته من العدّ، ورأى القيمة نفسها مرة ثانية في السياق الذي يتابعه، أمكنه اعتبار الطلب معاد التشغيل. إنها إشارة أمنية نافعة لأن التقدم المتوقع تكرر بدلاً من أن يتقدم.

لكن التعريف المعياري أضيق من هيئة الرقم. فهو يعدّ الطلبات التي أرسلها العميل باستخدام nonce المعروض، بما فيها الطلب الحالي. لا يقول إن الخادم قبل كل الطلبات السابقة، أو إن مثيلاً واحداً عالجها، أو إن التطبيق ثبّت آثارها بالترتيب نفسه. كما أن nc ليس فريداً خارج قيمة nonce التي ترافقه.

عندما يغيّر الخادم nonce تبدأ سلسلة جديدة. ولعميل آخر أو realm آخر أو مجال حماية آخر سلسلة مستقلة. عودة العدّ إلى واحد تعني أن سياق المصادقة تبدّل، لا أن تاريخ المعاملات مُسح. لذلك يحدد nc موقعاً داخل حوار أمني قصير، ولا يحدد موقع العملية في دفتر أعمال عالمي.

حتى كدليل على الإعادة، لا يكفي الرقم منفرداً. لا معنى عملياً لثماني خانات في سجل بلا server nonce وclient nonce والهوية وrealm وقرار الخادم. ومع اكتمال هذه العناصر يبقى السجل شاهداً على المصادقة، لا على commit التطبيق.

الذاكرة التي تمنح العدّاد معناه

يربط RFC 7616 كشف إعادة التشغيل باحتفاظ الخادم بنسخة من العدّ. لا تصبح القيمة التي يرسلها العميل دليلاً ذاتياً. يجب أن يعرف الخادم إلى أي حالة يقارنها وكيف أصدر nonce وحدد صلاحيته.

هذه السياسة متروكة للتنفيذ. قيمة nonce غير شفافة للعميل، ويمكن تقييدها بزمن أو مورد أو عميل أو عدد استعمالات. يستطيع الخادم قبولها مرة واحدة وتسجيل أنها استُهلكت؛ فيحصل على حماية قوية من الإعادة الفورية مقابل ذاكرة أكبر وتعطيل محتمل للطلبات المتعاقبة في pipeline. ويمكنه إبقاء nonce صالحاً لطلبات عدة واستخدام nc، محتفظاً بجزء كبير من الحماية مع كلفة أقل.

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

ما الذي تدخله Digest في الحساب فعلاً

عند استخدام qop، تتكون الاستجابة من مادة مشتقة من كلمة المرور، وserver nonce، وnc، وclient nonce، واختيار qop، وتجزئة A2. مع qop=auth تحتوي A2 على طريقة HTTP وURI الطلب. ومع qop=auth-int تضاف تجزئة جسم الكيان. وهكذا يتحقق الخادم من معرفة السر ضمن مجال الحماية، ويمكنه كشف أنواع محددة من التكرار أو التعديل.

ليست الحماية شاملة للرسالة. ينبّه RFC إلى أن معظم حقول HTTP تبقى خارج سلامة auth-int ويمكن لوسيط معادٍ تعديلها. كما لا توفر Digest سرية لبقية التبادل، ولذلك يُنصح باستخدامها فوق HTTPS.

وهناك حد آخر: المصادقة ليست تفويضاً. النتيجة الصحيحة تؤيد أن صاحب الطلب يعرف السر المرتبط بـrealm، لكنها لا تقرر حقه في تحويل مال أو حذف سجل أو تدوير مفتاح. تلك سلطة سياسة التطبيق وحالته الراهنة.

يجب ضبط نسبة العمل إلى صاحبه أيضاً. Rifaat Shekh-Yusef هو المحرر المسمّى وأحد المؤلفين المشاركين لوثيقة إجماع IETF؛ وليس مخترع كل عنصر فيها. كان nonce count موجوداً في RFC 2617. أبقى RFC 7616 الآلية، وأضاف SHA-256 وSHA-512/256 والتفاوض على الخوارزمية وuserhash وشرحاً أمنياً أوضح. ويقول صراحة إن مرونة الخوارزمية لا تعالج هجوم القاموس على كلمات المرور التي يحفظها البشر.

تأكيد المصادقة ليس إيصال النتيجة

قد تحمل الاستجابة Authentication-Info وفيها rspauth، إلى جانب cnonce وnc العائدين إلى الطلب المقابل. بذلك يثبت الخادم معرفته بسر المستخدم، ويمكن أن يوفر auth-int سلامة محدودة للاستجابة. هذه مصادقة متبادلة نافعة.

لكنها لا تسمّي دفعة أو مهمة أو commit أو تعويضاً. يمكن للخادم قبول Digest، وتسليم العمل إلى queue، ثم يثبّت العامل النتيجة بينما تضيع استجابة HTTP. يحصل العميل على nonce جديد ويرسل محاولة صحيحة أخرى. صحة التبادلين لا تمنع تنفيذ النية التجارية مرتين.

الحل ليس توسيع معنى nc. يحتاج التطبيق إلى مفتاح idempotency يربط المحاولات بنية واحدة قبل إحداث الأثر، وإلى واجهة تستعلم عن النتيجة بهذا المفتاح بعد timeout. لا يعرّف RFC 7616 أياً منهما؛ إنهما جزء من تصميم الخدمة وحفظ حالتها.

خمس حالات بدلاً من ضوء نجاح واحد

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

الاستخدام الدقيق لـnonce count لا يقلل من شأنه. على المشغّل حماية حالة الخادم التي تجعل المقارنة ممكنة، واختيار nonce محدود عندما يبرر الخطر ذلك، وتحديد qop وفق ما يحتاج إلى سلامة، والإبقاء على HTTPS. ثم يجب وقف الاستنتاج. عدّاد المصادقة لا يرى دفتر التطبيق، ولا يجوز تحميله شهادة عن نتيجة لم يراقبها.

المصادر