ಮೊದಲು 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ಖಾತೆ ದೃಢೀಕರಣ ಅಧಿಕಾರವನ್ನೂ ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಗುಂಪು ಸದಸ್ಯತ್ವ, ಸಾಧನದ ಸ್ಥಿತಿ ಮತ್ತು ಜಾಲಬಂಧ ಅನುಮತಿಗೆ ಬಳಕೆದಾರ ಅಗತ್ಯ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸಿದ ನಂತರವೂ ಸ್ಪಷ್ಟ ಮ್ಯಾಪಿಂಗ್ ಬೇಕು. ಸಂಪೂರ್ಣವಾಗಿ ದೃಢೀಕರಿಸಿ ಏನನ್ನೂ ಅಧಿಕಾರಿಸದ ಸಂಪರ್ಕ ನೀತಿಯ ಫಲಿತಾಂಶ, ವಿಧಾನದ ದೋಷವಲ್ಲ.