الخلاصة

  • استبدل RFC 2444 التحليل الارتجالي لكلمات المرور لمرة واحدة في كل تطبيق بآلية SASL محددة الاسم وصيغ تبادل واضحة.
  • تنفّذ آلية OTP تبادل المصادقة، لكنها لا توفر طبقة أمنية أو خصوصية للجلسة أو مصادقة للخادم أو حماية من الهجمات النشطة.

في أواخر التسعينيات، لم تكن المشكلة أن بروتوكولات البريد تفتقر إلى أوامر الدخول؛ بل أن كل تطبيق كان يستطيع إضافة المصادقة بطريقته. أشار RFC 2444 إلى أن كلمات المرور لمرة واحدة كانت تُلحق «على نحو ارتجالي» مع تحليل استدلالي للمدخلات. فوضع لها آلية مسمّاة ضمن Simple Authentication and Security Layer (SASL)، حتى يستطيع بروتوكول التطبيق طلب تبادل معروف بدلاً من ابتكار محلّل محلي لكلمات المرور.

هذا توحيد لواجهة المصادقة، لا وعد بحماية الاتصال كله. ميّز RFC 2222 بين إثبات هوية المستخدم والتفاوض الاختياري على طبقة أمنية للتفاعلات اللاحقة. ويحدد RFC 2444 حدّه بوضوح: آلية OTP لا توفر طبقة أمنية. كما أنها لا تقدم خصوصية للجلسة، ولا مصادقة للخادم، ولا حماية من الهجمات النشطة. لذلك قد تنتهي عملية الدخول برسالة نجاح بينما يظل المسار الذي يحمل الأمر التالي معتمداً على حماية أخرى.

استند ملف الآلية إلى نظام OTP في RFC 2289 وإلى الردود الموسعة في RFC 2243. على الخادم دعم أربع صيغ: hex وword وinit-hex وinit-word. تحمل الصيغتان الأوليان الرد، أما صيغتا init- فتسمحان أيضاً بإعادة ضبط التسلسل. دعم MD5 إلزامي ودعم SHA-1 موصى به. وينبغي للعميل أن يوضح انخفاض رقم التسلسل وأن يتيح للمستخدم خيار إعادة ضبطه. وكل استعمال يحدّث سجل المستخدم في قاعدة بيانات المصادقة. بهذا تصبح صيغ الرسائل قابلة للتوافق، لكن إدارة الحالة والنسخ البرمجية المتوافقة تبقى مسؤولية تنفيذية.

يذكر RFC 2444 عميلاً غير موثوق، مثل جهاز عام، مثالاً للاستخدام. فإذا التقط الجهاز كلمة المرور، يفترض أن تمنحه فرصة واحدة فقط للتصرف باسم المستخدم. لكن هذه المحدودية لا تحمي الجلسة التي تبدأ بعد ذلك. ويحذر النص أيضاً من أن قاعدة بيانات المصادقة المخترقة تظل عرضة لهجمات القاموس، مع أنها لا يلزم أن تكون مكافئة لقاعدة كلمات مرور بنص صريح. كما يتناول هجوم القاموس السلبي، ويلزم التطبيقات بالحماية من سباق التحديث الذي يصفه نظام OTP الأساسي. عبارة «مرة واحدة» تضيق نوعاً من المخاطر ولا تلغي البقية.

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

حدّث RFC 2444 مواصفة SASL لعام 1997 وجعل الاستخدام المقصود لآلية S/Key ضمن SASL قديماً. ثم استبدل RFC 4422 إطار SASL الأول، ووثّق RFC 5034 ملفاً لبروتوكول POP3، بينما عرّف RFC 5802 آلية مختلفة هي SCRAM. تشرح هذه الوثائق تطور الإطار؛ لكنها لا تثبت الانتشار الشامل لـRFC 2444 ولا صلاحية توصياته التشفيرية الصادرة في 1998 للاستخدام اليوم. المعيار يصف تصميماً وسلوكاً مطلوباً، لا عدد الأنظمة التي نفذته.

إسهامه التاريخي محدد: منح التطبيقات طريقة معيارية لطلب OTP بدلاً من تفسيره وفق أعراف محلية مختلفة. وما بقي بعد ذلك واضح في حدود الوثيقة. على مصمم البروتوكول تحديد نقل رموز SASL؛ وعلى المنفّذ إبقاء تحديث التسلسل متسقاً؛ وعلى المشغّل حماية الاتصال بعد المصادقة؛ وعلى التطبيق ربط الهوية بالصلاحيات المناسبة. «لمرة واحدة» تصف إعادة استخدام الإجابة، لا أمن الجلسة.

المصادر