ആദ്യം EAP രീതി: VPN ഏത് പാസ്‌വേഡ് ഹാഷ് ഉപയോഗിക്കാം
VPN രഹസ്യം പരിശോധിക്കുന്നു, വെബ് ഹാഷ് അല്ല. രീതി വായിക്കുക, എന്നിട്ട് അതേ പാസ്‌വേഡുകൾ തുടർന്നും പ്രവർത്തിക്കുമെന്ന് വാഗ്ദാനം ചെയ്യുന്നതിന് മുൻപ് സംഭരണത്തിൽ എന്തുണ്ടെന്ന് പരിശോധിക്കുക.
പല ടീമുകൾക്കും പ്രവർത്തിക്കുന്ന വെബ് ലോഗിൻ ഉണ്ടാകും, അതേ പട്ടികയിലെ ഓരോ പാസ്‌വേഡും നിരസിക്കുന്ന VPN ഉം ഉണ്ടാകും. വെബ് ആപ്ലിക്കേഷൻ സ്വയം കണക്കാക്കിയ ഹാഷ് താരതമ്യം ചെയ്യുന്നു, എന്നാൽ ടണൽ ക്ലയന്റിനോട് സർവർ പരിശോധിക്കാൻ കഴിയുന്ന രീതിയിൽ ഒരു രഹസ്യത്തിന്റെ ഉടമസ്ഥത തെളിയിക്കാൻ ആവശ്യപ്പെടുന്നു. സംഭരിച്ച വസ്തുവിനോടുള്ള വ്യത്യസ്ത ആവശ്യങ്ങളാണ് ഇവ. ഈ രണ്ടിനും ഇടയിലുള്ള വിടവിലാണ് ഇത്തരം പ്രോജക്ടുകളിൽ മിക്കതും നിൽക്കുന്നത്.
ആദ്യം രീതി, പിന്നെ സ്കീമ
ഏതെങ്കിലും സ്കീമ നോക്കുന്നതിന് മുൻപ് തിരഞ്ഞെടുത്ത രീതി ഏത് തെളിവാണ് ആവശ്യപ്പെടുന്നതെന്ന് എഴുതുക. വെല്ലുവിളി-പ്രതികരണ രീതിക്ക് സർവറിന് പ്രതീക്ഷിത പ്രതികരണം കണക്കാക്കാൻ കഴിയുന്ന വസ്തു വേണം, അതായത് പ്രായോഗികമായി പാസ്‌വേഡോ അനുയോജ്യമായ വ്യുൽപ്പന്ന രൂപമോ. സംരക്ഷിത ടണലിനുള്ളിൽ പാസ്‌വേഡ് കൊണ്ടുപോകുന്ന രീതിക്ക് പരിശോധകനടുത്ത് പാസ്‌വേഡ് തന്നെ വേണം. ക്ലയന്റ് കോൺഫിഗറേഷനുവേണ്ടിയല്ല, പരിശോധകന്റെ ആവശ്യത്തിനുവേണ്ടി രീതിയുടെ രേഖകൾ വായിക്കുക, കാരണം ക്ലയന്റ് ആവശ്യങ്ങൾ സാധാരണയായി എളുപ്പമുള്ള ഭാഗമാണ്.
ആധുനിക വെബ് ഫ്രെയിംവർക്ക് നിർമ്മിക്കുന്ന ഉപ്പിട്ട ഹാഷ് രണ്ടും നൽകുന്നില്ല. അത് ഒരു പ്രത്യേക താരതമ്യം മാത്രം പരിശോധിക്കുന്നു, വന്ന രഹസ്യത്തിലേക്ക് തിരികെ മാറ്റാൻ കഴിയില്ല.
വെല്ലുവിളി-പ്രതികരണത്തിന് ഉപ്പിട്ട ഹാഷ് ഉപയോഗിക്കാനാവില്ല
MSCHAPv2 ഒരു വെല്ലുവിളി-പ്രതികരണ കൈമാറ്റമാണ്, അതിനാൽ സർവറിന് പാസ്‌വേഡ് ഒരിക്കലും ലഭിക്കുന്നില്ല, സംഭരിച്ച സ്ട്രിംഗ് താരതമ്യം ചെയ്യാനും കഴിയില്ല. ഇതിനകം കൈവശമുള്ള വസ്തുവിൽ നിന്ന് പ്രതീക്ഷിത പ്രതികരണം കണ്ടെത്തണം, അതുകൊണ്ടാണ് അനുയോജ്യമായ സംഭരണ രൂപങ്ങൾ ഇത്ര ഇടുങ്ങിയത്. ഓരോ ഉപയോക്താവിനും ഉപ്പുള്ള bcrypt അല്ലെങ്കിൽ Argon2 മൂല്യം കൈമാറ്റം പൂർണ്ണമായി ഒഴിവാക്കുന്ന വിധത്തിൽ ഏകദിശയാണ്. താഴെയുള്ള പട്ടിക രീതിയുടെ പേരിൽ നിന്നല്ല, സംഭരണ രൂപത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്, കാരണം ഉത്തരം നിർണ്ണയിക്കുന്നത് സംഭരണ രൂപമാണ്.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL പ്ലഗിന്നിന്റെ രേഖകൾ strongSwan-നായി കോൺഫിഗറേഷനും ക്രെഡൻഷ്യലുകൾക്കും സ്വന്തം സ്കീമ നിർവചിക്കുന്നു, പ്രോജക്ട് ആ പ്ലഗിന്നിനെ ഇപ്പോഴും പരീക്ഷണാത്മകമെന്ന് അടയാളപ്പെടുത്തുന്നു. അതിൽ ഒന്നും ഒരു ആപ്ലിക്കേഷന്റെ ഉപയോക്തൃ പട്ടികയുമായി പൊരുത്തപ്പെടുന്നില്ല, ഏത് ഹാഷിംഗ് സ്കീമാണ് സംഭരിച്ച മൂല്യം നിർമ്മിച്ചതെന്ന് ഊഹിക്കുന്നുമില്ല. അതിനാൽ യാഥാർത്ഥ്യമായ ഓപ്ഷനുകൾ ഗേറ്റ്‌വേയ്ക്ക് ഉപയോഗിക്കാവുന്ന സംഭരണത്തിലേക്കുള്ള കുടിയേറ്റമോ, കൈമാറ്റം നിർവഹിക്കാൻ കഴിയുന്ന നിലവിലെ സംഭരണത്തിന് മുൻപിലുള്ള പ്രാമാണീകരണ സേവനമോ ആണ്. ബാക്കിയെല്ലാം ഉള്ളിൽ ഒളിഞ്ഞ ഊഹമുള്ള കണക്ടറാണ്.
RADIUS ജോലി നീക്കുന്നു, ആവശ്യം അല്ല
EAP ഒരു RADIUS സർവറിന് നൽകുന്നത് പരിശോധന എവിടെ നടക്കുന്നു എന്നത് മാറ്റുന്നു, സാധാരണയായി ഓഡിറ്റ് ട്രെയിൽ മെച്ചപ്പെടുത്തുന്നു. ഏകദിശ ഹാഷിൽ നിന്ന് പാസ്‌വേഡ് വീണ്ടെടുക്കുന്നില്ല, അതിനാൽ പ്രാമാണീകരണ സേവനത്തിന് അത് അവസാനിപ്പിക്കുന്ന രീതിയുമായി അനുയോജ്യമായ വസ്തു ഇപ്പോഴും വേണം. RADIUS പാത നിർമ്മിച്ച് മറുവശത്ത് അതേ ഭിത്തി കണ്ടതിന് ശേഷമാണ് ടീമുകൾ ഇത് അറിയുന്നത്.
RADIUS സർവറിന് അനുയോജ്യമായ ക്രെഡൻഷ്യൽ ഉള്ള ഡയറക്ടറി വായിക്കാൻ കഴിയുന്നിടത്ത് രൂപകൽപ്പന പ്രവർത്തിക്കുന്നു, VPN ഗേറ്റ്‌വേ ലളിതമായി തുടരുന്നു. കഴിയാത്തിടത്ത് സത്യസന്ധമായ ഉത്തരം മറ്റൊരു കണക്ടറല്ല, രജിസ്ട്രേഷൻ മാറ്റമാണ്. വിതരണവും റദ്ദാക്കലും ഐഡന്റിറ്റി ഉള്ളവന്റേതാണ്, അതിനാൽ പിന്തുണയുള്ള സമന്വയ പ്രക്രിയയില്ലാതെ പകർത്തിയ പട്ടിക ഒറ്റ സൈൻ-ഇൻ അല്ല, രണ്ടാമത്തെ ക്രെഡൻഷ്യൽ ജീവിതചക്രമാണ്. ആരെങ്കിലും ഒരിടത്ത് മാത്രം പാസ്‌വേഡ് പുനഃസജ്ജീകരിക്കുമ്പോൾ അത് ആദ്യമായി വ്യതിചലിക്കുന്നു, രണ്ട് സംവിധാനങ്ങളിലുമുള്ള അക്കൗണ്ട് ഓരോന്നിലും വ്യത്യസ്തമായി പെരുമാറുന്നതുവരെ ആ വ്യതിചലനം നിശ്ശബ്ദമാണ്.
ഡയറക്ടറി വായിക്കുന്ന അക്കൗണ്ടിനെ ആ വായനയിൽ മാത്രം പരിമിതപ്പെടുത്തുക, ഗേറ്റ്‌വേ സ്വന്തം കോൺഫിഗറേഷനുവേണ്ടി ഉപയോഗിക്കുന്ന അക്കൗണ്ടിൽ നിന്ന് വേർതിരിക്കുക. പങ്കിട്ട അഡ്മിനിസ്ട്രേറ്റീവ് അക്കൗണ്ട് വായന-മാത്ര രൂപകൽപ്പനയെ വളരെ വിശാലമായ സ്വാധീന പരിധിയാക്കി മാറ്റുന്നു.
അക്കൗണ്ട് എവിടെ ആയിരിക്കണം
വസ്തു സംബന്ധമായ ചോദ്യം തീർന്നാൽ രണ്ട് വാസ്തുവിദ്യകൾ അവശേഷിക്കുന്നു. ഗേറ്റ്‌വേ താൻ മാത്രം വായിക്കുന്ന ചെറിയ ക്രെഡൻഷ്യൽ സംഭരണം സ്വന്തമാക്കാം, അല്ലെങ്കിൽ കോർപ്പറേറ്റ് ഡയറക്ടറിക്ക് മുൻപിൽ നിൽക്കുന്ന പ്രാമാണീകരണ സേവനത്തിന് നൽകാം.
ആദ്യത്തേത് ചിന്തിക്കാൻ എളുപ്പവും ഉപയോക്താവിന് മോശവുമാണ്, കാരണം അയാൾക്ക് പരിപാലിക്കാൻ രണ്ടാമതൊരു പാസ്‌വേഡ് ശേഷിക്കുന്നു. രണ്ടാമത്തേത് ഒരു ഐഡന്റിറ്റി നിലനിർത്തുന്നു, ഇപ്പോൾ ആരെങ്കിലും ബന്ധിപ്പിക്കുന്നതിന് മുൻപ് പ്രവർത്തിക്കേണ്ട സേവനത്തിൽ ആശ്രിതത്വം ചേർക്കുന്നു. രണ്ടും തെറ്റല്ല, പക്ഷേ തിരഞ്ഞെടുപ്പ് ഗേറ്റ്‌വേ കോൺഫിഗറേഷന് അടുത്ത് രേഖപ്പെടുത്തണം, അല്ലാത്തപക്ഷം അടുത്ത എൻജിനീയർ മറ്റേത് തിരഞ്ഞെടുത്തുവെന്ന് അനുമാനിക്കും. നിങ്ങൾ എന്ത് തിരഞ്ഞെടുത്താലും, താഴെയുള്ള രണ്ട് കമാൻഡുകളാണ് മാറ്റുന്നതിന് മുൻപ് നിലവിലെ അവസ്ഥ കാണിക്കുന്നത്.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsഅക്കൗണ്ട് പ്രാമാണീകരണം അധികാരവും തീർക്കുന്നില്ല. ഗ്രൂപ്പ് അംഗത്വം, ഉപകരണ അവസ്ഥ, നെറ്റ്‌വർക്ക് അനുമതി എന്നിവ ഉപയോക്താവ് ആവശ്യമായ ഐഡന്റിറ്റി തെളിയിച്ചതിന് ശേഷവും വ്യക്തമായ മാപ്പിംഗ് ആവശ്യപ്പെടുന്നു. തികച്ചും പ്രാമാണീകരിക്കുകയും ഒന്നും അധികാരപ്പെടുത്തുകയും ചെയ്യാത്ത കണക്ഷൻ നയത്തിന്റെ ഫലമാണ്, രീതിയുടെ തകരാറല്ല.