उपकरणको घडी सर्दा TOTP कोडहरू किन असफल हुन्छन्

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

यहाँ दुई घडी महत्त्वपूर्ण छन्, र देखिने घडी सुधार्नु भनेको मानिसहरूले पहिले गर्ने भाग हो। सामान्यतया ध्यान चाहिने घडी अर्को हो।

कोड समयको फङ्सन हो, पासवर्ड होइन

TOTP ले साझा गोप्य र वर्तमान समयबाट निकालिएको काउन्टर लिन्छ, दुवैलाई कुञ्जी भएको ह्यासबाट पठाउँछ र नतिजालाई छोटो दशमलव शृंखलामा काट्छ, जुन RFC 6238 मा निर्दिष्ट छ। काउन्टर प्रत्येक समय-चरणमा अगाडि बढ्छ, सामान्यतया तीस सेकेन्ड, त्यसैले चरण बदलिँदा उही गोप्यले नयाँ मान उत्पादन गर्छ। प्रमाणितकर्ताले वर्तमान चरणको अपेक्षित मान पुनः गणना गरेर तुलना गर्छ, जसका लागि उही गोप्य र अहिलेको बारेमा उही बुझाइ चाहिन्छ। पासवर्ड परिवर्तन नगरेसम्म पुनः प्रयोगयोग्य रहन्छ, जबकि यो मान ग्राहकले देख्न नसक्ने सीमामा सकिन्छ।

त्यसैले एउटा कोड काम गर्छ र अर्को केही क्षणमै असफल हुन्छ। च्याट सन्देशबाट कोड कपी गर्नु किन यति अविश्वसनीय बानी हो भन्ने पनि यसले बताउँछ।

दुई घडी मिल्नुपर्छ, एउटा होइन

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

प्रमाणितकर्ताको घडी पनि उपकरणको घडीजत्तिकै जाँचको योग्य छ। जसको समय स्रोत बिग्रेको छ त्यस्तो सर्भरले सबै प्रयोगकर्ताका सही कोडहरू एकैचोटि अस्वीकार गर्छ, र प्रतिवेदनहरूले सर्ने कुराको सट्टा अचानक अवरोध वर्णन गर्नेछन्। यो ढाँचा चिन्न लायक छ, किनकि यसको उपचार सर्भरमा हुन्छ, सय फोनमा होइन।

विन्डो फराकिलो बनाउनुको मूल्य

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

घडी सुधार्नु मर्मत हो, जबकि विन्डो फराकिलो बनाउनु शान्तक हो। पहिलोले कारण हटाउँछ र दोस्रोले त्यसलाई लुकाउँछ।

फेरि प्रयास गर्नुअघि दुवै घडी जाँच्नुहोस्

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

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

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

अस्वीकृतिको समय, अफसेट र त्रुटिको पाठ रेकर्ड गर्नुहोस्, र साझा गोप्य त्यसबाहिर राख्नुहोस्। सहयोगले पहिलो तीनसँग काम गर्न सक्छ र चौथो कहिल्यै देख्नु हुँदैन।