ਪਹਿਲਾਂ 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ਖਾਤਾ ਪ੍ਰਮਾਣਿਕਤਾ ਅਧਿਕਾਰ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰਦੀ। ਸਮੂਹ ਮੈਂਬਰੀ, ਜੰਤਰ ਦੀ ਸਥਿਤੀ ਅਤੇ ਨੈੱਟਵਰਕ ਇਜਾਜ਼ਤ ਨੂੰ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਲੋੜੀਂਦੀ ਪਛਾਣ ਸਾਬਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਸਪਸ਼ਟ ਮੈਪਿੰਗ ਚਾਹੀਦੀ ਹੈ। ਜੋ ਕਨੈਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਪਰ ਕੁਝ ਵੀ ਅਧਿਕ੍ਰਿਤ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਨੀਤੀ ਦਾ ਨਤੀਜਾ ਹੈ, ਢੰਗ ਦੀ ਖ਼ਰਾਬੀ ਨਹੀਂ।