પહેલાં 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ખાતાનું પ્રમાણીકરણ અધિકૃતિ પણ નક્કી કરતું નથી. વપરાશકર્તાએ જરૂરી ઓળખ પુરવાર કર્યા પછી પણ જૂથ સભ્યપદ, ઉપકરણની સ્થિતિ અને નેટવર્ક પરવાનગીને સ્પષ્ટ મેપિંગની જરૂર રહે છે. જે જોડાણ સંપૂર્ણ રીતે પ્રમાણિત થાય પણ કંઈ અધિકૃત કરતું નથી તે નીતિનું પરિણામ છે, પદ્ધતિની ખામી નહીં.