مولد TOTP

سر مشترك بالإضافة إلى الساعة

يُعرف TOTP في RFC 6238 وهو طبقة رقيقة فوق HOTP. يحتفظ كلا الطرفين بنفس السر، الذي يُسلَّم عادةً مرة واحدة كرمز QR ويُخزن في تطبيق مصادقة. لإنتاج رمز، يأخذ كل طرف وقت يونكس الحالي، ويقسمه على حجم الخطوة (30 ثانية افتراضيًا) للحصول على عداد، ويحسب HMAC-SHA1 لذلك العداد تحت السر، ثم يقص النتيجة إلى العدد المطلوب من الأرقام.

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

القص وعدد الأرقام

يكون ناتج HMAC 20 بايت، وهو أكثر بكثير من رمز من 6 أرقام. يستخدم القص الديناميكي النمط المنخفض للبايت الأخير كإزاحة، ويقرأ أربعة بايتات تبدأ من هناك، ويقنّع البت الأعلى لتجنب مشاكل الإشارة، ويأخذ ذلك الرقم مودولو 10^أرقام. استخدام إزاحة متغيرة بدلاً من ثابتة يعني أن المهاجم لا يمكنه تركيز التحليل على شريحة معروفة من الملخص.

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

انحراف الساعة وإعادة التشغيل

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

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