- فارق الإدخال الجوهري: يحسب HOTP التجزئة بناءً على عداد أحداث تزايدي أحادي (C)، بينما يستبدل TOTP هذا العداد بـ خطوة زمنية مستمدة من التوقيت الفعلي T (توقيت Unix الحالي مقسوماً على 30).
- علاقة التوريث الرياضي المباشر: من الناحية الحسابية، يعد TOTP مجرد حالة خاصة من HOTP:
TOTP(K, Time) = HOTP(K, T). وتستخدم الخوارزميتان نفس دالة الاقتطاع الديناميكي (Dynamic Truncation) تماماً. - العامل المعماري الحاسم: بروتوكول HOTP يحفظ الحالة (Stateful)، حيث يجب على الخادم حجز وتحديث العداد في قاعدة البيانات عند كل مصادقة. بينما بروتوكول TOTP عديم الحالة (Stateless)، مما يتيح للخدمات السحابية الموزعة التحقق من الرموز عبر خوادم متوازنة الأحمال دون عمليات كتابة مركزية.
الجذور التاريخية: من أجهزة التوكن العتادية المملوكة إلى معايير الويب المفتوحة
في أوائل العقد الأول من القرن الحادي والعشرين، كانت المصادقة الثنائية في الشركات الكبرى حكراً على أجهزة التوكن العتادية الاحتكارية مثل مفاتيح RSA SecurID. كانت تلك الأجهزة مغلقة المصدر ومكلفة للغاية، وتحتوي على بلورات كوارتز داخلية متزامنة مع خوادم الشركات المصنعة. وإذا أرادت مؤسسة ما تأمين آلاف الموظفين، كانت تكاليف شراء العتاد وتراخيص البرمجيات خيالية.
لتحرير المصادقة من قيود الموردين الاحتكاريين، تأسس تحالف OATH (Initiative for Open Authentication) من قِبل رواد الصناعة لتقديم معايير مفتوحة وغير خاضعة لحقوق الملكية الفكرية ضمن منظمة IETF، بحيث يستطيع أي مهندس برمجيات فحصها وتطبيقها ومراجعتها بأمان:
HMAC-Based One-Time Password Algorithm. صُمم للمتحكمات الدقيقة منخفضة الطاقة المزودة بزر فيزيائي. يؤدي الضغط على الزر إلى زيادة عداد داخلي وعرض رمز مكون من 6 أرقام على شاشة LCD صغيرة.
Time-Based One-Time Password Algorithm. طُور بالتزامن مع الثورة الهائلة للهواتف الذكية. ومن خلال الاستفادة من مزامنة توقيت شبكات الهاتف الخلوي عبر بروتوكول NTP، تخلص TOTP تماماً من مشكلات عدم تطابق حالات الأزرار الفيزيائية.
معيار HOTP (RFC 4226) وميكانيكا الاقتطاع الديناميكي (DT) على مستوى البايت
التعريف الرياضي الأساسي لخوارزمية HOTP موجز ومحكم للغاية:
تفصيل المعاملات الرياضية:
K: المفتاح السري المشترك المتماثل (عادة ما يكون مفتاحاً ثنائياً مفكوكاً من Base32 بطول 160 بت / 20 بايت).C: عداد صحيح بطول 8 بايت (64 بت) بصيغة Big-Endian.HMAC-SHA-1: كود مصادقة الرسائل المجزأ بمفتاح، وينتج خلاصة تشفيرية بطول 20 بايت (160 بت).
🔍 كيف يحول الاقتطاع الديناميكي (DT) خلاصة 20 بايت إلى 6 أرقام عشرية:
تحتوي خلاصة HMAC-SHA1 على 160 بتاً (20 بايت). ويتطلب استخراج 6 أرقام عشرية منتظمة آلية اختيار قطعية ومقاومة للتصادم محددة في القسم 5.3 من RFC 4226:
0x0F، نعزل البتات الأربعة الأقل رتبة، مما يعطينا عدداً صحيحاً يقع حصراً بين 0 و 15 (0x0 إلى 0xF). وهذا يضمن أن استخراج 4 بايتات تالية لن يتجاوز أبداً حدود مصفوفة الـ 20 بايت (لأن 15 + 4 = 19).
0x7F بتصفير البت الأكثر أهمية (MSB) لتجنب حدوث طفح الأعداد الصحيحة ذات الإشارة عبر مختلف معماريات المعالجات، مما يضمن الحصول على رقم موجب نظيف بطول 31 بتاً.
بافتراض أن المفتاح السري هو سلسلة ASCII "12345678901234567890" والعداد C = 0. تكون خلاصة HMAC-SHA1 بالتمثيل الست عشري هي:
1. البايت الأخير هو 0x71. ويكون 0x71 & 0x0F = 0x01، وبالتالي فإن قيمة الإزاحة Offset = 1.
2. البايتات من 1 إلى 4 هي: 93 cf 18 50. تصفير البت الأول يعطي 0x13cf1850، وهو ما يساوي بالترميز العشري 332,339,280.
3. 332339280 mod 1000000 = 339280. الرمز الناتج المكون من 6 أرقام هو 339280!
تطور معيار TOTP (RFC 6238): سحر النوافذ الزمنية والتعريف الموحد
تطلب بروتوكول HOTP بقاء العداد على جهاز المستخدم متزامناً بدقة مع العداد على خادم الويب. ولكن على الأجهزة والتطبيقات البرمجية، يؤدي الضغط العرضي أو فشل الشبكة إلى خطأ بشري مستمر في تزامن العدادات.
استبدل معيار RFC 6238 العداد C بـ خطوة زمنية متقطعة T مشتقة مباشرة من توقيت Unix الفعلي:
- CurrentUnixTime: عدد الثواني المنقضية منذ 1970-01-01 00:00:00 بتوقيت UTC.
- T0: نقطة بدء الحقبة الزمنية المرجعية (وقيمتها الافتراضية 0 في كافة الأنظمة الحديثة).
- X (نافذة الخطوة الزمنية): المدة القياسية الموصى بها وهي 30 ثانية.
- دالة الجزء الصحيح ⌊ ⌋: بالنسبة لأي ختم زمني يقع ضمن نفس نافذة الـ 30 ثانية، تظل قيمة T ثابتة دون تغيير. فعلى سبيل المثال، بين الثواني 1728211200 و 1728211229، ينتج نفس الرقم الصحيح T بالضبط.
التحويل الثنائي: بمجرد حساب T، يتم تحويله إلى مصفوفة بايتات بطول 8 بايت بتنسيق Big-Endian (مطابقة تماماً في الذاكرة لهيكل العداد C في HOTP). ولهذا فإن المعادلة الشاملة تتبسط إلى:
TOTP(K, Time) = HOTP(K, T)
هذه الأناقة الرياضية تفسر كيف تقوم تطبيقات المصادقة بتوليد رموز جديدة متزامنة كل 30 ثانية دون الحاجة لأي اتصال أو مزامنة للحالة مع الخوادم.
HS[31] & 0x0F)؛ وفي SHA-512 (خلاصة 64 بايت)، تؤخذ الإزاحة من البايت رقم 63 (HS[63] & 0x0F). ورغم ذلك، تظل خوارزمية SHA-1 هي المعيار الافتراضي السائد في 99.9% من الخدمات العالمية (مثل Google و Microsoft و GitHub و AWS) لضمان التوافق مع كافة تطبيقات الهواتف.
مصفوفة المقارنة الشاملة وجهاً لوجه بين HOTP و TOTP
| بُعد المقارنة | HOTP (RFC 4226) | TOTP (RFC 6238) |
|---|---|---|
| متغير الإدخال | عداد الأحداث C (تزايدي أحادي) | الفاصل الزمني T (نافذة 30 ثانية لتوقيت Unix) |
| صلاحية الرمز | غير محددة (صالح حتى يتم استهلاكه) | 30 ثانية صارمة (يبطل تلقائياً) |
| بنية الخادم | يحفظ الحالة Stateful (يتطلب قفل وتحديث قاعدة البيانات) | عديم الحالة Stateless (تحقق مستقل عبر مزامنة NTP) |
| التعرض لهجمات إعادة الإرسال (Replay) | متوسط (الرمز الذي تم اعتراضه صالح للاستخدام) | منعدم تقريباً (محصور بالثواني المتبقية في النافذة) |
| وضع الفشل الرئيسي | عدم تزامن العداد (الضغط المتكرر على الزر بالخطأ) | انحراف ساعة الجهاز (عدم دقة وقت الهاتف) |
| دوال التجزئة المدعومة | HMAC-SHA-1 حصراً | HMAC-SHA-1 و HMAC-SHA-256 و HMAC-SHA-512 |
| الانتشار في الصناعة | أجهزة التوكن المصرفية القديمة، بوابات العتاد المخصصة | 99.9% من تطبيقات ومواقع المصادقة الحديثة |
عدم التزامن مقابل انحراف الوقت: الحلول الهندسية وآليات التعويض
في بيئات الإنتاج الموزعة، تختلف ساعات الأجهزة وخوادم الويب حتماً. وقد صمم خبراء التشفير نوافذ تعويض مخصصة للحفاظ على كفاءة التحقق:
إذا ضغط المستخدم على زر التوكن 5 مرات دون تسجيل دخول، يصل عداد الجهاز إلى C+5 بينما يظل الخادم عند C.
ينص معيار RFC 4226 على أن يقوم الخادم عند فحص الرمز بمسح نافذة استشرافية تمتد عبر [C+1, C+s] (عادة s=20). فإذا وجد تطابقاً، يقفز الخادم للأمام ويزامن العداد C فوراً.
نظراً لتأخير الشبكة أو انحراف ساعة هاتف المستخدم (كتأخر الساعة 10 ثوانٍ)، قد تصل الرموز في خطوة زمنية سابقة أو لاحقة.
تقوم الخوادم الاحترافية باختبار مصفوفة من 3 نوافذ: [T-1, T, T+1]، مما يوسع نافذة القبول العملية إلى 90 ثانية.
عندما يتحقق الخادم مما إذا كان الرمز المدخل يطابق الرمز المحسوب، تتوقف دوال المقارنة النصية البسيطة (مثل userOtp === serverOtp) عند أول حرف غير متطابق. ويستطيع المهاجم الذي يقيس زمن الاستجابة على مستوى الميكروثانية استنتاج الأرقام بالتتابع عبر هجمات التوقيت الجانبية. لذلك تطبق الخوادم المتقدمة مقارنة ذات وقت ثابت (مثل crypto.timingSafeEqual في Node.js) لإحباط هذا النوع من الهجمات تماماً.
لماذا انتصر بروتوكول TOTP في الويب الحديث؟
يعود الانتصار الكاسح لبروتوكول TOTP على حساب HOTP في شبكة الإنترنت إلى ثلاثة متطلبات معمارية حاسمة:
في البنى السحابية الموزعة متعددة المناطق، يمكن لأي خادم لديه ساعة متزامنة عبر NTP التحقق من رمز TOTP دون الحاجة لإجراء استعلامات أو عمليات قفل على قاعدة بيانات مركزية.
تقوم الهواتف الذكية بمعايرة ساعاتها باستمرار عبر أبراج الاتصالات الخلوية ونظام GPS، مما يقضي على مشكلة انحراف التوقيت دون الحاجة لصيانة الأجهزة العتادية.
تظل رموز HOTP صالحة إلى ما لا نهاية حتى تُستخدم. أما رموز TOTP فتنتهي صلاحيتها خلال 30 ثانية، مما يبطل مفعول السجلات المخترقة وحزم البيانات الملتقطة فوراً.
الأسئلة الشائعة والمفاهيم التشفيرية (FAQ)
س1: لماذا يعد بروتوكول HOTP عرضة لخلل عدم تزامن العداد (Desynchronization)؟
يقوم HOTP بزيادة عداد داخلي C في كل مرة يُضغط فيها على الزر العتادي للتوكن. فإذا ضغط المستخدم على الزر 20 مرة دون إدخال الرموز المولدة في الخادم، يتقدم عداد التوكن إلى C+20 بينما يظل الخادم عند C. فإذا تجاوز الفارق نافذة التحقق الاستشرافية للخادم (s)، تُرفض الرموز نهائياً حتى يتم تشغيل بروتوكول إعادة المزامنة اليدوي.
س2: هل يعد استخدام خوارزمية SHA-1 في TOTP غير آمن نظراً لثغرات التصادم المعروفة؟
لا، فبروتوكول TOTP يستخدم HMAC-SHA1 وليس دالة التجزئة SHA-1 المجردة. يعتمد أمان HMAC على خصائص الدالة العشوائية الزائفة (PRF)، حيث لا تتحول ثغرات التصادم إلى هجمات استخراج للمفتاح السري أو تزوير للرموز. بالإضافة إلى ذلك، تنتهي صلاحية الرموز كل 30 ثانية، مما يجعل هجمات القوة الغاشمة غير مجدية تشفيرياً واقتصادياً.
س3: لماذا تتيح خوارزمية TOTP التحقق عديم الحالة (Stateless) على مستوى الخوادم؟
في معيار HOTP، يجب على الخادم كتابة العداد C وتحديثه في قاعدة بيانات مركزية بعد كل تسجيل دخول ناجح لمنع إعادة الاستخدام، مما يسبب اختناقات القفل في الأنظمة الموزعة. أما في معيار TOTP، فيُشتق الفاصل الزمني T مباشرة من ساعة النظام عبر NTP، مما يسمح لأي عقدة خادم موزعة بالتحقق من الرموز باستقلالية تامة دون عمليات كتابة مركزية.
جرّب حسابات TOTP اللحظية في أداة 2FA-Tool
شاهد كيف تتحول سلسلة المفتاح السري Base32 إلى رموز ديناميكية من 6 أرقام عبر الاقتطاع الديناميكي لـ HMAC-SHA1. يعمل 100% دون اتصال في متصفحك.
📚 أدلة أمان ذات صلة
كيفية نقل حسابات 2FA بين الهواتف الذكية عبر رموز QR دون اتصال والمزامنة السحابية.
قواعد الامتثال، حفظ أكواد الاسترداد، مفاتيح SSH واستراتيجيات الإنقاذ في الطوارئ.
كيفية استعادة الوصول عبر Google و Microsoft و Steam و Binance و Apple و Discord.