TOTP कोड कैसे काम करते हैं

TOTP कोड एक 6-अंकों की संख्या है जिसे एक ऑथेंटिकेटर ऐप और एक सर्वर दोनों स्वतंत्र रूप से गणना करते हैं, उन्हीं दो इनपुट से: एक साझा गुप्त कुंजी और वर्तमान समय, जिसे 30-सेकंड की विंडो में विभाजित किया गया है। कोड स्वयं सेटअप के दौरान कभी प्रसारित नहीं होता और सीक्रेट के बारे में कोई जानकारी नहीं रखता, फिर भी दोनों पक्ष एक ही अंकों पर पहुँचते हैं — क्योंकि TOTP न जादू है न यादृच्छिकता, यह एक ही इनपुट पर लागू एक प्रकाशित एल्गोरिदम (RFC 6238) है। यह लेख गणना को शुरू से अंत तक चलता है, समझाता है कि "गलत कोड" लगभग हमेशा घड़ी की समस्या क्यों होता है, और उन हैंडलिंग नियमों को कवर करता है जो तय करते हैं कि आपका दूसरा कारक दूसरा कारक बना रहता है या नहीं। आप प्रत्येक चरण को स्वयं TOTP जेनरेटर में चला सकते हैं, जो आपके ब्राउज़र में स्थानीय रूप से कोड गणना करता है।

दो इनपुट, एक कोड: सीक्रेट और घड़ी

जब आप दो-कारक प्रमाणीकरण चालू करते हैं, तो सेवा एक यादृच्छिक सीक्रेट उत्पन्न करती है — आमतौर पर 20 बाइट्स, जो आपको Base32 वर्णों की एक स्ट्रिंग के रूप में दिखाया जाता है और, सुविधा के लिए, एक QR कोड में एन्कोड किया जाता है। वह सीक्रेट ठीक दो स्थानों पर संग्रहीत होता है: सेवा के डेटाबेस में और आपके ऑथेंटिकेटर में। उस क्षण से, लॉग इन करना एक सिंक्रनाइज़ गणना बन जाता है। दोनों पक्ष वर्तमान Unix समय लेते हैं, इसे समय चरण (लगभग हर सेवा के लिए 30 सेकंड) से विभाजित करते हैं, और परिणामी काउंटर को, सीक्रेट के साथ, एक हैश फ़ंक्शन में डालते हैं। जो भी मिलान करने वाला आउटपुट प्रस्तुत करता है उसे सीक्रेट का धारक माना जाता है।

डिज़ाइन की सुंदरता इसमें है कि यह क्या छोड़ देता है। भेजने के लिए कोई चुनौती नहीं है, देने के लिए कोई कोड नहीं है, कोई नेटवर्क राउंड ट्रिप नहीं है, और प्रति-लॉगिन ऐसा कुछ नहीं जिसे कोई हमलावर रोक सके: "एक बार" वाला गुण घड़ी से आता है, क्योंकि काउंटर हर 30 सेकंड में बदलता है और पुराने आउटपुट बेकार हो जाते हैं। इसका यह भी मतलब है कि सिस्टम में ठीक दो चीज़ें हैं जो गलत हो सकती हैं — सीक्रेट, और समय। लगभग हर TOTP विफलता, और हर TOTP चोरी, इन्हीं दोनों में से एक से जुड़ी होती है।

गणना, चरण दर चरण

काउंटर को पहले 8-बाइट बिग-एंडियन पूर्णांक के रूप में लिखा जाता है — एक निश्चित-चौड़ाई एन्कोडिंग जिस पर दोनों पक्ष सहमत होते हैं। फिर वह संदेश सीक्रेट को कुंजी बनाकर HMAC से गुज़रता है, सहमत हैश का उपयोग करके: डिफ़ॉल्ट रूप से SHA-1, और चुनने वाली सेवाओं के लिए SHA-256 और SHA-512 परिभाषित हैं। HMAC एक कुंजी-युक्त निर्माण है, साधारण हैश नहीं: केवल काउंटर को हैश करने से एल्गोरिदम जानने वाला कोई भी कोड पुन: उत्पन्न कर सकेगा, जबकि HMAC आउटपुट सीक्रेट के बिना अजेय हैं और इसे पुनर्प्राप्त करने के लिए उल्टा नहीं चलाए जा सकते।

एक डाइजेस्ट 20 बाइट या उससे अधिक का होता है; एक लॉगिन बॉक्स को 6 अंक चाहिए। पुल है गतिशील कटौती: डाइजेस्ट का अंतिम आधा-बाइट एक ऑफ़सेट चुनता है, उस ऑफ़सेट से चार बाइट पढ़े जाते हैं जिनका शीर्ष बिट मास्क किया गया होता है (चिह्न अस्पष्टता से बचने के लिए), और परिणामी 31-बिट संख्या को 10^अंक से घटाया जाता है — मानक छह अंकों के लिए दस लाख — बाईं ओर शून्य से भरा हुआ। यही वह कोड है जो आप टाइप करते हैं। अगली विंडो फिर से शुरू से गणना करती है; एक कोड को अगले से जोड़ने वाली कोई श्रृंखला नहीं है, यही कारण है कि फ़ोटो खींचा गया कोड तीस सेकंड बाद बेकार हो जाता है।

जब कोड अस्वीकृत हो जाता है: आमतौर पर यह घड़ी होती है

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

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

सीक्रेट ही पूरा खेल है

समारोह को हटा दें तो TOTP सुरक्षा एक तथ्य है: जिसके पास सीक्रेट है उसके पास दूसरा कारक है, हमेशा के लिए, कहीं से भी, सेवा के पास उसके कोड को आपके कोड से अलग करने का कोई तरीका नहीं है। सेटअप पर आप जो QR कोड स्कैन करते हैं वह किसी कोड की तस्वीर नहीं है — यह स्वयं सीक्रेट है, साथ में खाता लेबल और पैरामीटर, जिसे otpauth:// URI के रूप में स्वरूपित किया गया है। इसका स्क्रीनशॉट आपके दूसरे कारक की स्थायी प्रति है।

यही कारण है कि हैंडलिंग नियम पासवर्ड की तुलना में सख्त हैं। एक पासवर्ड सर्वर द्वारा सत्यापित किया जाता है और हैश करके संग्रहीत किया जा सकता है; एक TOTP सीक्रेट को दोनों पक्षों द्वारा कच्चे रूप में पुनर्प्राप्त किया जाना चाहिए, इसलिए इसे हैश करके समाप्त नहीं किया जा सकता, और हर प्रति एक जीवित प्रति है। मास्टर प्रति को अपने ऑथेंटिकेटर या एक एन्क्रिप्टेड पासवर्ड मैनेजर में रखें। इसे कभी ऐसी वेबसाइट में न टाइप करें जो अपने सर्वर पर कोड उत्पन्न करती है — आपने एक अजनबी को स्थायी कुंजी सौंप दी है — और इसे कभी चैट में न चिपकाएँ, जैसा कि अगला अनुभाग बताता है।

सीक्रेट को चैट बॉक्स में कभी क्यों नहीं जाना चाहिए

2FA सीक्रेट को चैट में चिपकाना — एक समर्थन वार्तालाप, एक टीम चैनल, एक AI सहायक — हानिरहित लगता है क्योंकि स्ट्रिंग बेतुकी लगती है और वार्तालाप निजी लगता है। यह दोनों में से कोई नहीं है। चैट लॉग किए जाते हैं, बनाए रखे जाते हैं, खाते के हर डिवाइस पर सिंक किए जाते हैं, खोजे जा सकते हैं, और उन सर्वरों पर संसाधित किए जाते हैं जिन्हें आप नियंत्रित नहीं करते; AI चैट उस सूची में प्रशिक्षण पाइपलाइन और लंबी अवधि के प्रतिधारण को जोड़ते हैं। जिस क्षण सीक्रेट वहाँ उतरता है, आपका दूसरा कारक उन प्रणालियों में मौजूद होता है जिन्हें पाठ को रखने और अनुक्रमित करने के लिए बनाया गया है।

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

TOTP क्या नहीं रोकता

TOTP पासवर्ड चोरी, क्रेडेंशियल स्टफ़िंग और डेटाबेस लीक को हराता है: आपका पासवर्ड जानना अब पर्याप्त नहीं है। यह रियल-टाइम फ़िशिंग को नहीं हराता। एक नकली लॉगिन पेज जो आपके क्रेडेंशियल को असली सेवा को रिले करता है और कोड माँगता है, वह कोड को उसके 30-सेकंड विंडो के भीतर आगे बढ़ा सकता है — कोड सीक्रेट के कब्ज़े को साबित करता है, यह नहीं कि आप असली साइट से बात कर रहे हैं। सत्र-कुकी चोरी इसे उतनी ही पूरी तरह से बायपास करती है, क्योंकि कोड केवल एक बार जाँचा जाता है।

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

स्रोत

अक्सर पूछे जाने वाले प्रश्न

क्या कोई मेरे कोड से मेरा सीक्रेट प्राप्त कर सकता है?

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

सेवाएँ पिछले और अगले कोड को क्यों स्वीकार करती हैं?

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

क्या SHA-1 TOTP अभी भी सुरक्षित है, यह देखते हुए कि SHA-1 "टूटा हुआ" है?

हाँ, इस निर्माण में। प्रसिद्ध SHA-1 हमले टकराव प्रतिरोध को तोड़ते हैं, जो हस्ताक्षरों और प्रमाणपत्रों के लिए मायने रखता है। HMAC की सुरक्षा टकराव प्रतिरोध पर निर्भर नहीं करती — यह इस पर निर्भर करती है कि कुंजी-युक्त निर्माण एक छद्म-यादृच्छिक फ़ंक्शन की तरह व्यवहार करता है — और ऐसा कोई व्यावहारिक हमला मौजूद नहीं है जो देखे गए आउटपुट से TOTP सीक्रेट को पुनर्प्राप्त करे या कोड जाली बनाए। सेवाएँ फिर भी SHA-256 चुन सकती हैं; इस साइट पर जेनरेटर तीनों का समर्थन करता है।