वैध एक-वेळ कोडही VPN लॉगिनमध्ये का अयशस्वी होतो

तुम्ही VPN क्लायंट उघडता, पासवर्ड टाइप करता, आणि तुमच्या ऑथेंटिकेटरमधील सहा अंक अवैध म्हणून परत येतात — दोन वेळा, नंतर तिसऱ्यांदा. खात्यात कालपासून काहीही बदललेले नाही, त्यामुळे पहिली प्रवृत्ती ऑथेंटिकेटरमधील नोंद काढून पुन्हा स्कॅन करण्याची असते — सहसा ही चुकीची दुरुस्ती असते. एक-वेळ कोड हा दुसरा पासवर्ड नाही: गेटवेने तो विशिष्ट टप्प्यात, विशिष्ट नोंदणीकृत नोंदीतून, विशिष्ट कालावधीत मागवला पाहिजे, आणि बहुतेक नकार अंकांची तुलना होण्यापूर्वीच होतात. नोंदणीला हात लावण्यापूर्वी तुम्ही कोणत्या टप्प्यात आहात ते ठरवा.

प्रॉम्प्टचा क्रम सांगतो तुम्ही कोणत्या प्रवाहात आहात

कोड असलेल्या जवळपास प्रत्येक VPN लॉगिनचा समावेश तीन आकारांत होतो. दोन-टप्प्यांच्या आकारात क्लायंट पासवर्ड पाठवतो, सर्व्हर आव्हान देते, आणि क्लायंट पुन्हा विचारतो. एकत्रित आकारात गेटवे पासवर्ड आणि कोड एकाच सबमिशनमध्ये मागतो — कधी जोडून, कधी फक्त ऑपरेटरने दस्तऐवजीकृत केलेल्या विभाजकानंतर. ब्राउझरच्या आकारात क्लायंटकडे कोणतेही फील्ड नसते: कोड वेब पेजमध्ये जातो, किंवा पुश मंजुरी त्याची जागा घेते, आणि डेस्कटॉप क्लायंट निकालाची वाट पाहतो.

चुकीचा आकार वाईट कोडसारखा दिसतो. फक्त पासवर्डसाठी असलेल्या फील्डमध्ये ताजा कोड पेस्ट करा, आणि सर्व्हर तो पासवर्डचा भाग म्हणून वाचेल. क्लायंटच्या बाजूला, OpenVPN 2.4 आणि नंतरच्या आवृत्त्या फरक दृश्यमान करतात: AUTH_FAILED,CRV1: ने उत्तर देणारा सर्व्हर आव्हान-प्रतिसादाची अपेक्षा करतो, त्यामुळे प्रोफाइलला static-challenge किंवा SCRV1: स्वरूपातील पासवर्ड फाइल लागते. फक्त auth-user-pass असलेले जुने प्रोफाइल पासवर्ड सत्यापित करून थांबते, जे लॉगमध्ये OTP अयशस्वीतेसारखे दिसते, जरी कोणताही कोड पाठवला गेला नाही.

WireGuard अपवाद म्हणून नमूद करण्यासारखा आहे: तो लोकांची नाही तर किल्ली-जोड्यांची प्रमाणीकरण करतो, त्यामुळे कोडसाठी कोणतेही फील्ड नाही. पुरवठादार अशी जाहिरात करत असेल, तर बोगद्याबाहेरचे काहीतरी ती स्वीकारत आहे.

सर्व्हर सहा अंकांसह काय करतो

वेळ-आधारित कोड RFC 6238 चे अनुसरण करतात, जे RFC 4226 मधील जुन्या काउंटर-आधारित रचनेला गुंडाळते: गतिशील घटकावर HMAC, डीफॉल्टनुसार सहा अंकांत कापलेला. TOTP मध्ये गतिशील घटक म्हणजे सध्याची Unix वेळ एका पायरीने भागलेली, ऑपरेटरने बदलले नसेल तर 30 सेकंद. सत्यापनकर्ता तुमच्या अंकांची साठवलेल्या मूल्याशी कधीही तुलना करत नाही; तो सामायिक बीजातून अपेक्षित कोड पुन्हा मोजतो आणि सहसा शेजारील पायऱ्याही स्वीकारतो, त्यामुळे संथ फेरी लॉगिन अयशस्वी करत नाही.

दोन परिणाम दुर्लक्षित राहतात. फोनचा वेळ क्षेत्र अप्रस्तुत आहे, कारण बीज कधीही स्थानिक घड्याळ पाहत नाही — फक्त खऱ्या UTC पासूनचे विचलन महत्त्वाचे आहे, आणि दोन मिनिटे पुढे धावणारे उपकरण स्वच्छ उलटी गिनती दाखवत असतानाही प्रत्येक कोडमध्ये अयशस्वी होते. आणि कोड रचनेनुसार एक-वेळचा आहे: सत्यापनकर्ता त्या बीजासाठी शेवटचे स्वीकारलेले काउंटर मूल्य लक्षात ठेवतो, त्यामुळे तेच अंक पुन्हा पाठवल्यास त्याच कालावधीतही नाकारले जातात. कालबाह्य झाल्यावर पुन्हा प्रयत्न करणारा क्लायंट नुकताच पाठवलेला कोड जाळू शकतो.

काउंटर-आधारित टोकन प्रत्येक दाबल्यावर काउंटर हलवतात, त्यामुळे कोड तयार झाल्यावर कधीही न पाठवल्यास ते सुसंगतीबाहेर जातात; नेहमीची दुरुस्ती म्हणजे पुढील काही मूल्ये स्वीकारणारी पुनर्सुसंगती खिडकी. ऑपरेटरने HOTP नोंदवले असेल आणि तुमचे अ‍ॅप TOTP दाखवत असेल, तर प्रत्येक मूल्य घड्याळाच्या समस्येसारखे दिसणाऱ्या पद्धतीने चुकीचे आहे. QR कोडमागील प्रोव्हिजनिंग URI प्रकार, अंक, कालावधी आणि हॅश सांगते.

चुकीच्या कोडसारख्या दिसणाऱ्या अयशस्वीता

नोंदणीकृत नोंद हा सर्वात सामान्य दोषी आहे. ऑथेंटिकेटर अ‍ॅप नोंदी जारीकर्ता आणि खात्यानुसार लेबल करतात, त्यामुळे एकाच VPN वर दोन ओळखी असलेल्याकडे लेबल एका अक्षराने वेगळी असलेली दोन नोंदी असू शकतात. कोड तो तयार करणाऱ्या बीजासाठी वैध आहे, दुसऱ्या कशासाठीही नाही. फोनवरील लेबल सर्व्हर नोंदवत असलेल्या वापरकर्तानावाशी तुलना करा, तुम्ही टाइप केले होते असे आठवत असलेल्याशी नाही.

दुसरे म्हणजे न जुळणारा घटकांचा संच. आठ अंक, 60 सेकंदांचा कालावधी किंवा SHA-256 ने नोंदवलेले बीज असे कोड देते जे सहा अंक, 30 सेकंद आणि SHA-1 अपेक्षणाऱ्या सत्यापनकर्त्याने नाकारले जातात, आणि क्लायंटवर ते चुकीच्या कोडपासून वेगळे ओळखता येत नाही. QR कोडच्या फोटोवरून नोंद पुन्हा जोडली गेलेली किंवा टोकन रेकॉर्ड डीफॉल्ट मूल्यांनी पुन्हा बांधलेली स्थलांतरे झाल्यावर हे दिसते.

तिसरे कोडबद्दल नाही. गेटवे सहसा चुकीचा पासवर्ड, कालबाह्य कोड आणि निष्क्रिय खात्यासाठी एकच सामान्य प्रमाणीकरण अयशस्वीता परत देतात, हेतुपुरस्पर, जेणेकरून कोणालाही कोणता घटक अयशस्वी झाला हे कळू नये. क्लायंटच्या बॅनरऐवजी गेटवे किंवा RADIUS लॉग वाचा: कधीही न काढलेले आव्हान, OTP गुणधर्माशिवाय प्रवेश-नकार आणि धोरण-नकार स्क्रीनवर सारखेच दिसतात आणि वेगळ्या पुढील पायऱ्यांकडे नेतात.

हे संकुचित करणारा छोटा क्रम

सर्वात स्वस्त तपासणीपासून सुरुवात करा आणि जी पहिली पायरी जुळत नाही तिथे थांबा.

1. ताज्या कोडची वाट पाहा, तो एकदा पाठवा, आणि आव्हान पासवर्ड स्वीकारल्यापूर्वी येते की नंतर हे नोंदवा.
2. ऑथेंटिकेटरमधील लेबल सर्व्हर साठवत असलेल्या वापरकर्तानावाशी जुळवा.
3. प्रोफाइल आव्हानाला उत्तर देऊ शकतेच याची खात्री करा, वरच्या CRV1 प्रकरणाप्रमाणे.
4. उपकरणाचे घड्याळ ज्ञात वेळ-स्रोताशी तुलना करा; काही डझन सेकंदांपेक्षा जास्त विचलन TOTP स्वतःच तोडते.
5. टोकन TOTP आहे की HOTP, आणि कोणते अंक, कालावधी व हॅश नोंदवले गेले हे ऑपरेटरला विचारा.

दोन नियम हे अधिक बिघडू देत नाहीत. अनेक वेळा पुन्हा प्रयत्न करू नका: अनेक गेटवे खात्यागणिक अयशस्वीता मोजतात आणि एकतर खाते लॉक करतात किंवा उत्तरे उशिरा देऊ लागतात, त्यामुळे एक झोक छोटी कॉन्फिगरेशन चूक सपोर्ट तिकिटात बदलते. आणि निदान म्हणून टोकन पुन्हा नोंदवू नका, कारण त्याने जुने बीज अवैध होते; जर खरी अडचण क्लायंटने कधीही न पाठवलेले आव्हान होते, तर आता एकाऐवजी दोन बदल समजावून सांगावे लागतील.

बीज आणि पुनर्प्राप्ती कोड चक्राबाहेर ठेवा

सहा अंक आणि त्यामागील रहस्य अदलाबदल करण्यायोग्य नाहीत. प्रोव्हिजनिंग QR कोड किंवा Base32 बीज खात्याचा प्रत्येक भावी कोड तयार करते, त्यामुळे ते पासवर्डच्याच श्रेणीत येते: स्क्रीनशॉटमध्ये नाही, तिकिटाच्या टिप्पणीत नाही, आणि आधी तुमच्याशी संपर्क केलेल्या व्यक्तीशी चॅटमध्येही नाही. पुनर्प्राप्ती कोड वेगळी यंत्रणा आहे — एक-वेळ, बऱ्याचदा कोड-प्रॉम्प्ट पूर्णपणे वगळतात, आणि खाते तपासण्यासाठी एक खर्च केल्यास नंतर लागू शकेल असा पर्यायी मार्ग काढून टाकला जातो.

कोड लॉगिन पेजला विश्वासार्हही करत नाही: सारख्या दिसणाऱ्या डोमेनवरील OTP प्रॉम्प्ट वैध कोड गोळा करून तो त्याच कालावधीत पुन्हा वाजवतो, आणि तुम्ही कुठे लिहित आहात हे अजूनही प्रमाणपत्रच सांगते.

क्रम आव्हानाला उत्तर देऊ न शकणाऱ्या प्रोफाइलवर पोहोचला, तर प्रोफाइल दुरुस्त करा आणि एका ताज्या कोडने पुन्हा तपासा. तो न जुळणाऱ्या नोंदणी घटकांवर पोहोचला, तर कोणी काही स्कॅन करण्यापूर्वी ऑपरेटरला टोकन रेकॉर्ड वाचायला सांगा. तो लॉकआउटवर पोहोचला, तर क्लायंट बदलण्याऐवजी तो संपेपर्यंत थांबा — अडथळा खात्याची स्थिती आहे, अ‍ॅप नाही.