സാധുവായ ഒറ്റത്തവണ കോഡ് 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 പ്രോംപ്റ്റ് സാധുവായ കോഡ് ശേഖരിച്ച് വിൻഡോയ്ക്കുള്ളിൽ വീണ്ടും പ്ലേ ചെയ്യുന്നു, നിങ്ങൾ എവിടെ ടൈപ്പ് ചെയ്യുന്നുവെന്ന് ഇപ്പോഴും സർട്ടിഫിക്കറ്റാണ് പറയുന്നത്.

ക്രമം വെല്ലുവിളിക്ക് ഉത്തരം നൽകാൻ കഴിയാത്ത പ്രൊഫൈലിൽ അവസാനിച്ചാൽ, പ്രൊഫൈൽ ശരിയാക്കി ഒരു പുതിയ കോഡ് ഉപയോഗിച്ച് വീണ്ടും പരിശോധിക്കുക. പൊരുത്തപ്പെടാത്ത രജിസ്ട്രേഷൻ പാരാമീറ്ററുകളിൽ അവസാനിച്ചാൽ, ആരെങ്കിലും എന്തെങ്കിലും സ്കാൻ ചെയ്യുന്നതിന് മുമ്പ് ഓപ്പറേറ്ററോട് ടോക്കൺ റെക്കോർഡ് വായിക്കാൻ ആവശ്യപ്പെടുക. ലോക്കൗട്ടിൽ അവസാനിച്ചാൽ, ക്ലയന്റുകൾ മാറ്റുന്നതിന് പകരം അത് തീരുന്നതുവരെ കാത്തിരിക്കുക — തടസ്സം അക്കൗണ്ടിന്റെ അവസ്ഥയാണ്, ആപ്പല്ല.