మొదట 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ఖాతా ప్రామాణీకరణ అధికారాన్ని కూడా పరిష్కరించదు. సమూహ సభ్యత్వం, పరికర స్థితి మరియు నెట్‌వర్క్ అనుమతి వినియోగదారు అవసరమైన గుర్తింపును నిరూపించిన తర్వాత కూడా స్పష్టమైన మ్యాపింగ్ అవసరం. పూర్తిగా ప్రామాణీకరించి ఏమీ అధికారం ఇవ్వని కనెక్షన్ విధానం ఫలితం, పద్ధతిలో లోపం కాదు.