OpenVPN ಸೇವೆಯು ಖಾಸಗಿ ಕೀ ಪಾಸ್‌ವರ್ಡ್ ಕೇಳುವಾಗ ನಿಂತುಕೊಳ್ಳುತ್ತದೆ: ಹೇಗೆ ಸರಿಪಡಿಸುವುದು
ಸೇವೆಗೆ ಟರ್ಮಿನಲ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಕೀಗೆ askpass ಮತ್ತು ಓದಬಹುದಾದ ಫೈಲ್ ಬೇಕು. ಕೀಯ ಪಾಸ್‌ಫ್ರೇಜ್ ಅನ್ನು ಸರ್ವರ್ ಲಾಗಿನ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ ಮತ್ತು unit ಪರಿಶೀಲಿಸಿ.
OpenVPN ಸ್ಥಳೀಯ ಯಂತ್ರದಲ್ಲಿ ಖಾಸಗಿ ಕೀಯ ಪಾಸ್‌ಫ್ರೇಜ್ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಲಾಗಿನ್ ಫೈಲ್ ಅದಕ್ಕೆ ಎಂದಿಗೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಸೇವೆಯಲ್ಲಿ ಟೈಪ್ ಮಾಡಲು ಟರ್ಮಿನಲ್ ಇಲ್ಲ, ಮತ್ತು ಆರಂಭವು ಒಂದೋ ನೇತಾಡುತ್ತದೆ ಅಥವಾ ಕಾರಣವಲ್ಲದೆ ಇನ್‌ಪುಟ್ ಅನ್ನು ಹೆಸರಿಸುವ ಜರ್ನಲ್ ನಮೂದಿನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಎರಡು ರಹಸ್ಯಗಳಿವೆ, ಮತ್ತು unit ಮರುಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಓದಬಹುದಾದ ಮೂಲ ಬೇಕು. ಕೆಳಗಿನ ಹಂತಗಳು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ, ನಂತರ ಪ್ರತಿ ಫೈಲ್ ಅನ್ನು ನಿಜವಾಗಿ ತೆರೆಯುವ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ.
ಎರಡು ವಿನಂತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ
ಕೀಯ ಪಾಸ್‌ಫ್ರೇಜ್ ಸ್ಥಳೀಯ ಖಾಸಗಿ ಕೀಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ; ಖಾತೆಯ ರುಜುವಾತುಗಳು ಸರ್ವರ್‌ಗೆ ಸೆಷನ್ ಅನ್ನು ದೃಢೀಕರಿಸುತ್ತವೆ. ಅವು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಿಂದ ಬರುತ್ತವೆ, ಬೇರೆ ಬೇರೆ ಕ್ಷಣಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಬೇರೆ ಸಂದೇಶಗಳನ್ನು ನೀಡುತ್ತವೆ. ಅವುಗಳನ್ನು ಗೊಂದಲಿಸುವುದು ಜನರನ್ನು ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದರೆ ಖಾತೆಯೇ ಒಳಗೊಂಡಿರಲಿಲ್ಲ. ಯಾವುದೇ ಆಯ್ಕೆ ಬದಲಿಸುವ ಮೊದಲು ವಿನಂತಿಯ ಪಠ್ಯವನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಯಾವ ರಹಸ್ಯ ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಪದಗಳೇ ಏಕೈಕ ನಂಬಲರ್ಹ ಸುಳಿವು.
Community OpenVPN 2.x ನಲ್ಲಿ askpass ಮೊದಲ ಸಾಲಿನಲ್ಲಿ ಕೀಯ ಪಾಸ್‌ಫ್ರೇಜ್ ಇರುವ ಫೈಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು auth-user-pass ಒಂದು ಸಾಲಿನಲ್ಲಿ ಬಳಕೆದಾರ ಹೆಸರು, ಮುಂದಿನ ಸಾಲಿನಲ್ಲಿ ಪಾಸ್‌ವರ್ಡ್ ಇರುವ ಫೈಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಎರಡೂ ಫೈಲ್‌ಗಳಲ್ಲಿ ಯಾವುದೂ ಇನ್ನೊಂದು ಆಯ್ಕೆಯನ್ನು ಪೂರೈಸಲಾರದು. ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ NetworkManager ಪ್ರೊಫೈಲ್ ಎರಡನ್ನೂ ತನ್ನದೇ ರಹಸ್ಯ ಸಂಗ್ರಹದಲ್ಲಿ ಇಡಬಹುದು, ಅದನ್ನು ಕಮಾಂಡ್-ಲೈನ್ ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ಓದುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಮಾರ್ಗ ಬರೆಯುವ ಮೊದಲು ನೀವು ಯಾವ ಕ್ಲೈಂಟ್ ಸಂರಚಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
ಎರಡೂ ಆಯ್ಕೆಗಳನ್ನು ಓದಬಹುದಾದ ಫೈಲ್‌ಗಳಿಗೆ ತೋರಿಸಿ
ಎರಡೂ ಇನ್‌ಪುಟ್‌ಗಳು ಬೇಕಾದ ಪ್ರೊಫೈಲ್ ಕೊನೆಗೆ ಮೂರು ಫೈಲ್ ಉಲ್ಲೇಖಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ: ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಕೀ, ಅದನ್ನು ತೆರೆಯುವ ಪಾಸ್‌ಫ್ರೇಜ್ ಮತ್ತು ಲಾಗಿನ್ ಜೋಡಿ. CA ಮತ್ತು ಗುರುತು ಪರಿಶೀಲನೆಗಳನ್ನು ಮುಟ್ಟದೆ ಅವುಗಳನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಅವು ಸರ್ವರ್ ಯಾರು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ ಮತ್ತು ಈ ಸಮಸ್ಯೆಯ ಭಾಗವಲ್ಲ. ನಿಯೋಜನೆ ಖಾತೆ ರುಜುವಾತುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸದಿದ್ದರೆ, auth-user-pass ಸೇರಿಸುವುದು ಯಾರೂ ಒದಗಿಸಲಾಗದ ಇನ್‌ಪುಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authವಾದವಿಲ್ಲದ ಆಯ್ಕೆಗಳು ಮಾರ್ಗವಿರುವ ಆಯ್ಕೆಗಳಿಗಿಂತ ಬೇರೆಯಾಗಿ ವರ್ತಿಸುತ್ತವೆ, ಮತ್ತು ಸೇವೆಯಲ್ಲಿ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ. ವಾದವಿಲ್ಲದ askpass ಇನ್ನೂ ಕನ್ಸೋಲ್ ಓದುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರ ಹೆಸರು ಮಾತ್ರ ಇರುವ auth-user-pass ಫೈಲ್ ಇನ್ನೂ ಪಾಸ್‌ವರ್ಡ್ ವಿನಂತಿಯನ್ನು ಕಾಯುತ್ತಿರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಡೀಮನ್ ಆದ ಮೇಲೆ ಅದು ಟರ್ಮಿನಲ್‌ನಿಂದ ಇನ್‌ಪುಟ್ ಕೇಳಲೇ ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ರೀತಿ ಸಂರಚಿಸಿದ ಸೇವೆ ಏಳುವುದಿಲ್ಲ.
ಸಂಪೂರ್ಣ ಮಾರ್ಗಗಳು ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ ಪ್ರಶ್ನೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತವೆ ಆದರೆ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ. ನಂತರ ಮಾಲೀಕತ್ವ, ಮೋಡ್ ಮತ್ತು ಹಾದುಹೋಗುವಿಕೆ ಬರುತ್ತವೆ, ಮತ್ತು ಮೂರನ್ನೂ ಪ್ರಕ್ರಿಯೆ ಯಾವ ಖಾತೆಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆಯೋ ಅದರ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.
ಪ್ರೊಫೈಲ್‌ಗಿಂತ ಮೊದಲು unit ಸಂರಚನೆಯನ್ನು ಓದಿ
ಇನ್‌ಸ್ಟಾನ್ಸ್ ಯಾವ ಸಂರಚನೆಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು unit ನಿರ್ಧರಿಸುತ್ತದೆ, ನೀವು ಸಂಪಾದಿಸುತ್ತಿದ್ದ ಫೈಲ್ ಅಲ್ಲ. ಅದರ ಕಮಾಂಡ್ ಲೈನ್ ಮತ್ತು ಎಲ್ಲಾ drop-in ಅನ್ನು ಓದಿ, ನಂತರ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿಯಿಂದ ನಿಜವಾಗಿ ಬಳಸುತ್ತಿರುವ ಪ್ರೊಫೈಲ್‌ವರೆಗೆ ಹೋಗಿ. ಬೇರೆ .ovpn ಫೈಲ್‌ಗೆ ಸೇರಿಸಿದ ಪಾಸ್‌ಫ್ರೇಜ್ ಉಲ್ಲೇಖವು ಈ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.
ಮೂರು ಓದಲು-ಮಾತ್ರ ಆದೇಶಗಳು ಅದರ ಹೆಚ್ಚಿನದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತವೆ. ಮೊದಲನೆಯದು unit ಮತ್ತು ಎಲ್ಲಾ drop-in ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬಂಧಿಸುವ ಗುರುತು ಮತ್ತು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು, ಮತ್ತು ಮೂರನೆಯದು ಕೊನೆಯ ಪ್ರಾರಂಭವು ನಿಜವಾಗಿ ಯಾವುದರ ಬಗ್ಗೆ ದೂರಿತ್ತು ಎಂಬುದನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಇರುವ ಇನ್‌ಸ್ಟಾನ್ಸ್ ಹೆಸರನ್ನು ಬಳಸಿ:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome ಮತ್ತು ಪ್ರೊಫೈಲ್‌ನ ಸ್ವಂತ user, group ಮತ್ತು chroot ಆಯ್ಕೆಗಳಿಗೆ ಗಮನ ಕೊಡಿ. ಮನೆ ಡೈರೆಕ್ಟರಿ ಅಡಿಯಲ್ಲಿರುವ ಫೈಲ್ ನಿಮ್ಮ ಶೆಲ್‌ನಲ್ಲಿ ಓದಬಹುದಾದದ್ದಾಗಿರಬಹುದು ಮತ್ತು ಮನೆ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಮರೆಮಾಡಿದಾಗ ಸೇವೆಯ ಒಳಗೆ ಅಗೋಚರವಾಗಬಹುದು. systemd ಪ್ರಾರಂಭಿಸುವ ಖಾತೆ ಯಾವಾಗಲೂ ಕೀಯನ್ನು ಕೊನೆಗೆ ತೆರೆಯುವ ಖಾತೆ ಅಲ್ಲ.
ರನ್‌ಟೈಮ್ ಗುರುತು ಎರಡೂ ಫೈಲ್‌ಗಳನ್ನು ತೆರೆಯಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸಿ
ಮೋಡ್ ಓದುವುದು ಸಾಕಲ್ಲ, ಏಕೆಂದರೆ ಮಾರ್ಗದಲ್ಲಿನ ಪ್ರತಿ ಡೈರೆಕ್ಟರಿಯೂ ಅದೇ ಗುರುತಿಗೆ ಹಾದುಹೋಗಬಹುದಾದದ್ದಾಗಿರಬೇಕು. ಮಾರ್ಗವನ್ನು ಘಟಕದಿಂದ ಘಟಕಕ್ಕೆ ನಡೆಯಿರಿ, ನಂತರ ಪ್ರಕ್ರಿಯೆ ಬಳಸುವ ಖಾತೆಯಾಗಿ ತೆರೆಯುವುದನ್ನು ಪರೀಕ್ಷಿಸಿ. root ಮಾಲೀಕತ್ವದ ಮತ್ತು 600 ಮೋಡ್‌ನ ಫೈಲ್ ಪ್ರಕ್ರಿಯೆ ಇನ್ನೂ root ಆಗಿರುವವರೆಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅನೇಕ ಪ್ರೊಫೈಲ್‌ಗಳು ಮಾಡುವ ಸವಲತ್ತು ಕಡಿತದ ನಂತರ ಅದು ನಿಜವಲ್ಲ. ಎರಡು ಆದೇಶಗಳು ಹಾದುಹೋಗುವಿಕೆ ಮತ್ತು ತೆರೆಯುವಿಕೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableಮೊದಲ ಆದೇಶ ಪ್ರತಿ ಘಟಕದ ಮೋಡ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ ಮತ್ತು ಖಾತೆ ಹಾದುಹೋಗಲಾಗದ ಸ್ಥಳದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ; ಎರಡನೆಯದು ಏಕೈಕ ಮುಖ್ಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಅಂದರೆ ರನ್‌ಟೈಮ್ ಗುರುತು ಫೈಲ್ ಅನ್ನು ಓದಲು ತೆರೆಯಬಹುದೇ. ಎರಡೂ ಫೈಲ್‌ನ ವಿಷಯವನ್ನು ಮುದ್ರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಫೈಲ್‌ನಲ್ಲಿ ಪಾಸ್‌ಫ್ರೇಜ್ ಇರುವಾಗ ಇದೇ ಮುಖ್ಯ ಅಂಶ. ಲಾಗಿನ್ ಫೈಲ್‌ಗೂ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ಹೆಚ್ಚಾಗಿ ಬೇರೆ ಮಾಲೀಕತ್ವದಲ್ಲಿ ಸಂಗ್ರಹವಾಗುತ್ತವೆ.
ಪ್ರಕ್ರಿಯೆ chroot ಅಥವಾ ಸೀಮಿತ namespace ಬಳಸಿದರೆ, ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ಆ ದೃಶ್ಯದ ಒಳಗಿನಿಂದ ನಡೆಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರ ತಪ್ಪು ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ಮರೆಮಾಡಿದ ಮನೆ ಡೈರೆಕ್ಟರಿ ಅಡಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ಪಾಸ್‌ಫ್ರೇಜ್ unit ಹೊರಗೆ ಉತ್ತೀರ್ಣವಾಗಿ ಒಳಗೆ ವಿಫಲವಾಗುವ ಪರೀಕ್ಷೆಯ ಸಾಮಾನ್ಯ ಉದಾಹರಣೆ.
ಮೊದಲ ಪ್ರಾರಂಭವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಮರುಸಂಪರ್ಕ
ಇನ್‌ಸ್ಟಾನ್ಸ್ ಅನ್ನು ಒಮ್ಮೆ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಕೊನೆಯದಲ್ಲ, ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಓದಿ. ಕಾಣೆಯಾದ ಇನ್‌ಪುಟ್ ಫೈಲ್, ವಿಫಲವಾದ ಕೀ ಡೀಕ್ರಿಪ್ಶನ್ ಮತ್ತು ಸರ್ವರ್‌ನಿಂದ AUTH_FAILED ಮೂರು ಬೇರೆ ಘಟನೆಗಳು, ಮೂರು ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆಗಳೊಂದಿಗೆ. ಅನುಮತಿ ಎಚ್ಚರಿಕೆಯನ್ನು ಸರಿಪಡಿಸುವುದು ಕೀ ತೆರೆಯಿತೇ ಎಂಬುದನ್ನು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಜರ್ನಲ್ ಸಾಲು ಮೂರರಲ್ಲಿ ಯಾವುದು ಎಂದು ಹೇಳುತ್ತದೆ. ಸರಿಪಡಿಸುವಿಕೆ ಯಾವ ಇನ್‌ಪುಟ್ ವಿಫಲವಾಯಿತು ಎಂಬುದರಿಂದ ಬರುತ್ತದೆ:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
ನಂತರ ನಿಮಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಜೀವನಚಕ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ: ಬೂಟ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭ ಮತ್ತು ಯಾವುದೇ ಬೆಂಬಲಿತ ಮರುಸಂಪರ್ಕ, ನಿಮ್ಮ ಶೆಲ್‌ನಿಂದ ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸುವುದು ಮಾತ್ರವಲ್ಲ. auth-nocache ಇದ್ದಾಗ ಇನ್‌ಪುಟ್‌ಗಳು ಮೊದಲ ಬಳಕೆಯ ನಂತರ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ನಂತರದ ಮರುಸಂಪರ್ಕಕ್ಕೆ ಇನ್ನೂ ಓದಬಹುದಾದ ಮೂಲ ಬೇಕು. ಡೆಸ್ಕ್‌ಟಾಪ್ ಲಾಗಿನ್‌ನಲ್ಲಿ ತೆರೆಯುವ ಕೀರಿಂಗ್ ಯಾರೂ ಲಾಗಿನ್ ಮಾಡುವ ಮೊದಲು ಪ್ರಾರಂಭವಾದ ಸೇವೆಗೆ ಲಭ್ಯವಿಲ್ಲ, ಮತ್ತು ಕೈಯ ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗಿ ರೀಬೂಟ್ ವಿಫಲವಾಗುವುದಕ್ಕೆ ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ. ಮೊದಲ ಪ್ರಾರಂಭ ಯಶಸ್ವಿಯಾಗಿ ನಂತರದ ಮರುಸಂಪರ್ಕ ವಿಫಲವಾದರೆ, ಅನುಮತಿಗಳನ್ನು ಮತ್ತೆ ಬದಲಿಸುವ ಮೊದಲು ಮರುಸಂಪರ್ಕ ಘಟನೆಗಾಗಿ ಜರ್ನಲ್ ಓದಿ.
ಕೀಯ ಪಕ್ಕದಲ್ಲಿ ಪಾಸ್‌ಫ್ರೇಜ್ ಇಡುವುದು ಎನ್‌ಕ್ರಿಪ್ಶನ್ ನಿಮಗೆ ನೀಡುವುದನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಫೈಲ್ ಮತ್ತು ಅದರ ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಿ. ಕೀಯ ಪಾಸ್‌ಫ್ರೇಜ್ ತೆಗೆಯುವುದನ್ನು ಕಾಣೆಯಾದ ಇನ್‌ಪುಟ್‌ನ ಸರಿಪಡಿಸುವಿಕೆ ಎಂದಲ್ಲ, ಪ್ರತ್ಯೇಕ ರುಜುವಾತು ನಿರ್ಧಾರ ಎಂದು ಪರಿಗಣಿಸಿ. ಮಾನವ ಅನುಮೋದನೆ ಅಥವಾ ಸಂವಾದಾತ್ಮಕ MFA ಅನ್ನು ಅವಲಂಬಿಸಿರುವ ನಿಯೋಜನೆಗೆ ಅದರ ಬೆಂಬಲಿತ ಏಜೆಂಟ್ ಅಥವಾ ನಿರ್ವಹಣಾ ಸಂಯೋಜನೆ ಬೇಕು; ಶಾಶ್ವತವಾಗಿ ಸಂಗ್ರಹಿಸಿದ ಒಂದು-ಬಾರಿಯ ಕೋಡ್ ಸಮಾನ ಪರ್ಯಾಯವಲ್ಲ.