كانت كلمة المرور صحيحة مرة واحدة: كيف غيّر RFC 1938 معنى الإجابة التالية

الخلاصة

• كان RFC 1938 يقبل القيمة x إذا أعادت H(x) قيمة التحقق المخزنة، ثم يخزن x نفسها مرجعاً جديداً؛ أي إن النجاح يدفع سلسلة التجزئة خطوة إلى الخلف.
• لذلك تعتمد خاصية «مرة واحدة» على تحديث ذري ومنع جلستين متزامنتين من استهلاك الدليل نفسه، وعلى إدارة النفاد وإعادة التهيئة.
• لا تمر العبارة السرية عبر الشبكة، لكن النظام لا يشفر الجلسة ولا يصد الهجمات النشطة عموماً؛ وقد استخدم HOTP وTOTP لاحقاً نماذج حالة مختلفة.

الإجابة ذاتها تصل إلى معيار مختلف

إذا أرسلت محطتان الإجابة الصحيحة نفسها في اللحظة نفسها، فقد ينجح الاختباران في نظام كلمة مرور قابلة لإعادة الاستخدام. لكن RFC 1938 يصف انتقالاً لا مجرد اختبار. يحسب الخادم H(x)، ويقارنها بالقيمة المحفوظة، ثم يقبل x ويضعها مكان القيمة القديمة. بعد هذا التغيير تصبح النسخة الثانية، رغم تطابقها، دليلاً على ماضٍ انتهى.

تؤرخ صفحة RFC Editor الحالية الوثيقة في مايو 1996 وتنسبها إلى N. Haller وC. Metz، وتسجلها معياراً مقترحاً أبطل لاحقاً بـRFC 2289. أما السؤال التاريخي الأعمق فهو كيف تحولت كلمة «لمرة واحدة» من وصف لغوي إلى عملية كتابة ينبغي ألا تقع مرتين.

يبدأ المولّد بعبارة مرور سرية وبذرة غير سرية، ثم يطبق دالة أحادية الاتجاه مراراً. عند العمق N تكون الإجابة الأولى H^N(S)، ثم تأتي H^(N-1)(S). يحتفظ الخادم بقيمة تحقق من 64 بت وبرقم التسلسل، لا بعبارة المرور. من يعرف حلقة حالية يستطيع الحساب نحو القيم المستهلكة، لا نحو الحلقة المطلوبة لاحقاً.

تطور هذا التصميم من S/KEY لدى Bellcore كما وثقه RFC 1760. كانت المشكلة عملية: كلمة مرور دائمة يلتقطها متنصت سلبي تصبح مفتاحاً قابلاً للتكرار. أما الإجابة من السلسلة فتفقد نفعها بعد أن يتقدم المستخدم الشرعي بالحالة.

ولا يعني غياب السر عن مخزن الخادم غياب الحالة. قيمة التحقق ليست سرية بالمعنى نفسه، لكنها تحدد ما سيقبله الحساب. نسخة احتياطية قديمة أو عقدة متأخرة أو تحديثان بلا ترتيب يمكن أن يعيد كتابة معنى «صحيح».

ست كلمات لتمثيل البتات

يعرض التحدي الخوارزمية والتسلسل والبذرة، مثل otp-md5 487 dog2. كان دعم MD5 إلزامياً، وSHA موصى به، وMD4 مسموحاً. يجب أن يتفق الطرفان، وقد يصبح أضعف خيار مقبول سقفاً عملياً للأمن.

ولأن إدخال 64 بت يدوياً صعب، حوّلها النظام إلى ست كلمات من قاموس يضم 2048 كلمة. تحمل كل كلمة 11 بت، فيبلغ الإجمالي 66 بت؛ والبتان الزائدان لفحص بعض أخطاء الإدخال وفك الترميز. هذا الفحص ليس عامل مصادقة ثانياً، ولا تمنح دلالات الكلمات قوة سرية إضافية.

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

السباق خارج الرياضيات

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

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

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

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

خلفٌ معياري وحدود باقية

تسجل صفحة RFC 2289 أنه معيار مقترح صدر في فبراير 1998 وخلف الوثيقة السابقة. ويحتفظ نص RFC 2289 بالسلسلة الهابطة، ويضيف متجهات اختبار ويقوي الإرشاد التشغيلي. وتوصيته باستخدام IPsec ضد اختطاف اتصال TCP توضّح أن نجاح OTP لا يحمي الجلسة التالية تلقائياً.

وضعت أنظمة لاحقة الحركة في موضع آخر. يستخدم HOTP سراً مشتركاً وعداداً صاعداً، ويمكن للمتحقق البحث في نافذة أمامية لاستعادة التزامن ثم التقدم بعد النجاح. أما TOTP فيجعل خطوة الزمن عاملاً متحركاً لـHOTP، ويمنع إعادة قبول قيمة نجحت في الخطوة الزمنية نفسها. هذه مقارنة مفيدة، لكنها لا تثبت اشتقاقهما من S/KEY.

المشترك هو أن سؤال «هل يتطابق الرمز؟» غير كافٍ. ينبغي تحديد الحالة النافذة، والهامش المقبول، وما يستهلكه النجاح، وكيف تتفق عدة عقد على التاريخ.

ويجب ألا يتضخم الادعاء. لم يوفر RFC 1938 الخصوصية أو حماية عامة من الهجوم النشط والهندسة الاجتماعية. القبول يثبت توافق إجابة مع حالة حساب مهيأ. ولا يثبت وحده تفويض أمر، أو سرية الجلسة، أو تنفيذ العمل، أو استمرار الوصول، أو الهوية المدنية للشخص.

ما تحت اسم «مرة واحدة»

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

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

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

إرث RFC 1938 الأهم هو أن نجاح الدليل قد يغيّر العالم الذي سيُحكم فيه على الدليل التالي. عندها لا تصبح المصادقة قراءة لحقيقة، بل كتابة يجب أن يكون لها مالك وترتيب وذاكرة.

المصادر

1. RFC Editor — السجل الحالي لـRFC 1938
2. RFC 1938 — A One-Time Password System
3. RFC 1760 — The S/KEY One-Time Password System
4. RFC Editor — السجل الحالي لـRFC 2289
5. RFC 2289 — A One-Time Password System
6. RFC 4226 — HOTP
7. RFC 6238 — TOTP
8. Heng Lu — Running-Code Primacy
9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile