માન્ય એકવાર-વપરાતો કોડ પણ 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 પ્રોમ્પ્ટ માન્ય કોડ એકઠો કરી સમયગાળાની અંદર ફરી વગાડે છે, અને તમે ક્યાં લખો છો તે હજી પણ પ્રમાણપત્ર જ કહે છે.

જો ક્રમ એવી પ્રોફાઇલ પર પહોંચે જે પડકારનો જવાબ આપી શકતી નથી, તો પ્રોફાઇલ સુધારો અને એક તાજા કોડ સાથે ફરી ચકાસો. જો તે મેળ ન ખાતા નોંધણી પરિમાણો પર પહોંચે, તો કોઈ કંઈ સ્કેન કરે તે પહેલાં ઓપરેટરને ટોકન રેકોર્ડ વાંચવા કહો. જો તે લૉકઆઉટ પર પહોંચે, તો ક્લાઇન્ટ બદલવાને બદલે તે પૂરો થવા દો — અવરોધ ખાતાની સ્થિતિ છે, એપ નહીં.