डिवाइस की घड़ी खिसकने पर TOTP कोड क्यों विफल होते हैं

एक बार उपयोग होने वाले कोड आपके फ़ोन पर बिल्कुल सही हो सकते हैं और उसी सेकंड सर्वर उन्हें अस्वीकार कर सकता है। दोनों पक्ष एक साझा गुप्त और मौजूदा समय-चरण से वही फ़ंक्शन गणना करते हैं, इसलिए समय पर मतभेद कोड पर मतभेद पैदा करता है। यह घड़ी के खिसकाव को केवल झुंझलाहट नहीं, सुरक्षा से जुड़ी खराबी बना देता है।

यहाँ दो घड़ियाँ मायने रखती हैं, और दिखने वाली घड़ी ठीक करना वह हिस्सा है जो लोग पहले करते हैं। जिस घड़ी पर आमतौर पर ध्यान चाहिए, वह दूसरी है।

कोड समय का फ़ंक्शन है, पासवर्ड नहीं

TOTP साझा गुप्त और मौजूदा समय से निकला काउंटर लेता है, दोनों को कुंजी वाले हैश से गुज़ारता है और परिणाम को छोटी दशमलव श्रृंखला में काट देता है, जैसा कि RFC 6238 में निर्दिष्ट है। काउंटर हर समय-चरण पर आगे बढ़ता है, आमतौर पर तीस सेकंड, इसलिए चरण बदलने पर वही गुप्त नया मान बनाता है। सत्यापनकर्ता मौजूदा चरण का अपेक्षित मान फिर से गणना करके तुलना करता है, जिसके लिए वही गुप्त और अभी के बारे में वही धारणा चाहिए। पासवर्ड बदले जाने तक पुन: प्रयोग योग्य रहता है, जबकि यह मान उस सीमा पर समाप्त होता है जिसे क्लाइंट नहीं देख सकता।

इसीलिए एक कोड काम करता है और अगला कुछ ही पलों बाद विफल हो जाता है। यह यह भी समझाता है कि चैट संदेश से कोड कॉपी करना इतनी अविश्वसनीय आदत क्यों है।

दो घड़ियों को मेल खाना चाहिए, एक को नहीं

नामांकन सामग्री पहली साझा चीज़ है, और समय दूसरी। अगर गुप्त सही है जबकि घड़ियाँ सहन की जाने वाली विंडो से अधिक भिन्न हैं, तो हर उत्पन्न मान गलत चरण में पड़ता है और अस्वीकार हो जाता है। अगर घड़ियाँ मेल खाती हैं जबकि गुप्त गलत है, तो हर मान भी अस्वीकार हो जाता है, और दोनों विफलताएँ लॉगिन स्क्रीन से एक जैसी दिखती हैं। उन्हें अलग करने का अर्थ है खाता प्रविष्टि और समय की स्वतंत्र रूप से, उसी क्रम में जाँच करना।

सत्यापनकर्ता की घड़ी उतनी ही जाँच की हकदार है जितनी डिवाइस की घड़ी। जिस सर्वर का समय स्रोत खराब है, वह एक साथ सभी उपयोगकर्ताओं के सही कोड अस्वीकार कर देता है, और रिपोर्टें खिसकाव के बजाय अचानक रुकावट बताएँगी। उस पैटर्न को पहचानना ज़रूरी है, क्योंकि उसका उपचार सर्वर पर है, सौ फ़ोन पर नहीं।

विंडो चौड़ी करने की क़ीमत

कार्यान्वयन छोटे अंतरों को सोखने के लिए पड़ोसी चरण का कोड स्वीकार कर सकते हैं, और वह सहनशीलता डिज़ाइन निर्णय है, मुफ़्त समायोजन नहीं। हर अतिरिक्त चरण किसी भी क्षण मान्य मानों की संख्या को गुणा कर देता है, जो ठीक वही है जो अनुमान लगाने वाले हमलावर को पसंद है। पुनरावृत्ति नियम भी इसी कारण मायने रखता है, क्योंकि दो बार स्वीकार किया गया कोड ऐसा कोड है जो उपयोगी रूप से लीक हुआ। शिकायतें शांत करने के लिए विंडो चौड़ा करने वाला प्रशासक वास्तविक गुण को दिखावटी सुधार से बदल देता है।

घड़ी ठीक करना मरम्मत है, जबकि विंडो चौड़ी करना शामक है। पहला कारण हटाता है और दूसरा उसे छिपाता है।

फिर से प्रयास करने से पहले दोनों घड़ियाँ जाँचें

डिवाइस और सर्वर पर समय पढ़ें, और दिखाए गए स्थानीय समय के बजाय ऑफ़सेट की तुलना करें। नीचे दिए आदेश लिनक्स होस्ट या सर्वर पर सिंक्रोनाइज़ेशन की स्थिति और कच्चा UTC क्षण दिखाते हैं। कोई भी प्रमाणीकरण सेटिंग बदलने से पहले इन्हें दोनों सिरों पर चलाएँ।

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

सेकंड में मापा गया ऑफ़सेट हानिरहित है, मिनट में मापा गया अस्वीकृति समझाता है, और ऐसा सिस्टम जो किसी सिंक्रोनाइज़ेशन स्रोत की रिपोर्ट नहीं करता, दोनों के लिए उम्मीदवार है। दोनों UTC टाइमस्टैम्प की सीधे तुलना करें, क्योंकि स्थानीय समय में ऐसा समय क्षेत्र शामिल होता है जिसे एल्गोरिदम कभी नहीं देखता। अगर ऑफ़सेट छोटे हैं और कोड फिर भी विफल हो रहे हैं, तो घड़ियाँ समायोजित करना बंद करें और इसके बजाय नामांकन प्रविष्टि की जाँच करें। लॉक किए गए खाते पर बार-बार प्रयास मूल खराबी को देखना कठिन बना देते हैं।

अस्वीकृति का समय, ऑफ़सेट और त्रुटि का पाठ दर्ज करें, और साझा गुप्त को इससे बाहर रखें। सहायता पहले तीन के साथ काम कर सकती है और चौथा कभी नहीं देखना चाहिए।