چرا کدهای TOTP وقتی ساعت دستگاه منحرف می‌شود شکست می‌خورند
کد هشی از راز و گام زمانی جاری است. اختلاف‌ها را در دو سر مقایسه کنید، سپس ساعت را درست کنید نه اینکه پنجره را گسترده‌تر کنید.
کدهای یک‌بارمصرف می‌توانند روی گوشی شما کاملاً درست باشند و همان ثانیه سرور آن‌ها را رد کند. هر دو طرف تابع یکسانی را از یک راز مشترک و گام زمانی جاری محاسبه می‌کنند، پس اختلاف دربارهٔ زمان به اختلاف دربارهٔ کد می‌انجامد. همین، انحراف ساعت را به عیبی مرتبط با امنیت تبدیل می‌کند نه فقط یک آزار.
دو ساعت در اینجا مهم‌اند و درست کردن ساعت قابل مشاهده کاری است که مردم اول انجام می‌دهند. ساعتی که معمولاً به توجه نیاز دارد همان دیگری است.
کد تابعی از زمان است، نه گذرواژه
TOTP راز مشترک و شمارنده‌ای برگرفته از زمان جاری را می‌گیرد، هر دو را از یک هش کلیددار می‌گذراند و نتیجه را به رشتهٔ دهدهی کوتاهی می‌برد، همان‌گونه که در RFC 6238 مشخص شده است. شمارنده با هر گام زمانی جلو می‌رود، معمولاً سی ثانیه، پس همان راز هنگام تغییر گام مقدار تازه‌ای تولید می‌کند. بازبین مقدار مورد انتظار گام جاری را دوباره محاسبه و مقایسه می‌کند، که نیازمند همان راز و همان تصور از اکنون است. گذرواژه تا زمانی که تغییر نکند قابل استفادهٔ مجدد می‌ماند، در حالی که این مقدار در مرزی که مشتری نمی‌بیند منقضی می‌شود.
به همین دلیل یک کد کار می‌کند و کد بعدی لحظاتی بعد شکست می‌خورد. این همچنین توضیح می‌دهد که چرا کپی کردن کد از یک پیام گفتگو عادتی چنان غیرقابل‌اعتماد است.
دو ساعت باید هم‌خوان باشند، نه یکی
مادهٔ ثبت نخستین چیز مشترک است و زمان دومی. اگر راز درست باشد در حالی که ساعت‌ها بیش از پنجرهٔ مجاز اختلاف دارند، هر مقدار تولیدشده در گام اشتباه می‌افتد و رد می‌شود. اگر ساعت‌ها هم‌خوان باشند در حالی که راز نادرست است، هر مقدار نیز رد می‌شود، و هر دو شکست از صفحهٔ ورود یکسان به نظر می‌رسند. جدا کردن آن‌ها یعنی بررسی مستقل ورودی حساب و زمان، به همین ترتیب.
ساعت بازبین همان دقت ساعت دستگاه را می‌طلبد. سروری که منبع زمانش خراب است، کدهای درست همهٔ کاربران را یک‌جا رد می‌کند و گزارش‌ها قطع ناگهانی را توصیف می‌کنند نه انحراف را. این الگو ارزش شناختن دارد، چون رفع آن به سرور تعلق دارد نه به صد گوشی.
گسترده‌تر کردن پنجره چه هزینه‌ای دارد
پیاده‌سازی‌ها ممکن است برای جذب تفاوت‌های کوچک کدی از گام مجاور بپذیرند، و این تحمل یک تصمیم طراحی است نه تنظیمی رایگان. هر گام اضافه تعداد مقادیر معتبر در هر لحظه را چند برابر می‌کند، که دقیقاً همان چیزی است که مهاجم حدس‌زننده ترجیح می‌دهد. قاعدهٔ جلوگیری از تکرار به همین دلیل مهم است، چون کدی که دو بار پذیرفته شود کدی است که به‌شکلی سودمند نشت کرده. مدیری که پنجره را برای خاموش کردن شکایت‌ها گسترده می‌کند، ویژگی واقعی را با بهبودی ظاهری معاوضه می‌کند.
اصلاح ساعت درمان است، در حالی که گسترده‌تر کردن پنجره مسکنی است. اولی علت را برمی‌دارد و دومی آن را پنهان می‌کند.
پیش از تلاش دوباره هر دو ساعت را بررسی کنید
زمان را روی دستگاه و روی سرور بخوانید و اختلاف‌ها را مقایسه کنید نه زمان‌های محلی نمایش‌داده‌شده را. دستورهای زیر وضعیت همگام‌سازی و لحظهٔ خام UTC را روی میزبان یا سرور لینوکس نشان می‌دهند. پیش از تغییر هر تنظیم احراز هویت آن‌ها را در دو سر اجرا کنید.
timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-statusاختلاف اندازه‌گیری‌شده با ثانیه بی‌ضرر است، اختلاف با دقیقه رد شدن را توضیح می‌دهد، و سامانه‌ای که هیچ منبع همگام‌سازی گزارش نمی‌کند نامزد هر دو است. دو نشان زمانی UTC را مستقیم مقایسه کنید، چون زمان محلی شامل منطقهٔ زمانی است که الگوریتم هرگز نمی‌بیند. اگر اختلاف‌ها کوچک است و کدها هنوز شکست می‌خورند، تنظیم ساعت‌ها را متوقف کنید و در عوض ورودی ثبت را بررسی کنید. تلاش‌های مکرر علیه حساب قفل‌شده مشاهدهٔ عیب اصلی را دشوارتر می‌کند.
زمان رد شدن، اختلاف و متن خطا را ثبت کنید و راز مشترک را بیرون از آن بگذارید. پشتیبانی می‌تواند با سه مورد اول کار کند و هرگز نباید چهارمی را ببیند.