ನಾನು ಇತ್ತೀಚೆಗೆ ಈ ಕಾರ್ಯವನ್ನು ನಿರ್ಮಿಸುವಾಗ ಸುರಕ್ಷಿತ ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವ ವೈಶಿಷ್ಟ್ಯವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ಮತ್ತೊಮ್ಮೆ ಯೋಚಿಸಲು ಸಮಯ ಸಿಕ್ಕಿತು. , ಮತ್ತು ನಂತರ ಅವನು ಇನ್ನೊಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಇದೇ ರೀತಿಯ ಏನಾದರೂ ಮಾಡಲು ಸಹಾಯ ಮಾಡಿದಾಗ. ಎರಡನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಮರುಹೊಂದಿಸುವ ಕಾರ್ಯವನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಎಂಬುದರ ಎಲ್ಲಾ ವಿವರಗಳೊಂದಿಗೆ ಅಂಗೀಕೃತ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಲಿಂಕ್ ನೀಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಹೇಗಾದರೂ, ಸಮಸ್ಯೆಯೆಂದರೆ ಅಂತಹ ಸಂಪನ್ಮೂಲವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಕನಿಷ್ಠ ನನಗೆ ಮುಖ್ಯವೆಂದು ತೋರುವ ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುವುದಿಲ್ಲ. ಹಾಗಾಗಿ ನಾನೇ ಬರೆಯಲು ನಿರ್ಧರಿಸಿದೆ.
ನೀವು ನೋಡಿ, ಮರೆತುಹೋದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳ ಪ್ರಪಂಚವು ನಿಜವಾಗಿಯೂ ನಿಗೂಢವಾಗಿದೆ. ಹಲವಾರು ವಿಭಿನ್ನ, ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವೀಕಾರಾರ್ಹ ದೃಷ್ಟಿಕೋನಗಳು ಮತ್ತು ಸಾಕಷ್ಟು ಅಪಾಯಕಾರಿ ಅಂಶಗಳಿವೆ. ನೀವು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ಅಂತಿಮ ಬಳಕೆದಾರರಾಗಿ ಹಲವು ಬಾರಿ ಎದುರಿಸಿರುವ ಸಾಧ್ಯತೆಗಳಿವೆ; ಆದ್ದರಿಂದ ಯಾರು ಸರಿಯಾಗಿ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಯಾರು ಮಾಡುತ್ತಿಲ್ಲ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯಲು ನೀವು ಏನನ್ನು ಕೇಂದ್ರೀಕರಿಸಬೇಕು ಎಂಬುದನ್ನು ತೋರಿಸಲು ನಾನು ಈ ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ಪಾಸ್ವರ್ಡ್ ಸಂಗ್ರಹಣೆ: ಹ್ಯಾಶಿಂಗ್, ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮತ್ತು (ಗ್ಯಾಸ್ಪ್!) ಸರಳ ಪಠ್ಯ
ಮರೆತುಹೋದ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಚರ್ಚಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಏನು ಮಾಡಬೇಕೆಂದು ನಾವು ಚರ್ಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಮೂರು ಪ್ರಮುಖ ಪ್ರಕಾರಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ:
- ಸರಳ ಪಠ್ಯ. ಪಾಸ್ವರ್ಡ್ ಕಾಲಮ್ ಇದೆ, ಅದನ್ನು ಸರಳ ಪಠ್ಯ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
- ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗಿದೆ. ವಿಶಿಷ್ಟವಾಗಿ ಸಮ್ಮಿತೀಯ ಗೂಢಲಿಪೀಕರಣವನ್ನು ಬಳಸುವುದು (ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಮತ್ತು ಡೀಕ್ರಿಪ್ಶನ್ ಎರಡಕ್ಕೂ ಒಂದು ಕೀಲಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ), ಮತ್ತು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಅದೇ ಕಾಲಮ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
- ಹ್ಯಾಶ್ಡ್. ಏಕಮುಖ ಪ್ರಕ್ರಿಯೆ (ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಹ್ಯಾಶ್ ಮಾಡಬಹುದು, ಆದರೆ ಡಿಹಾಶ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ); ಗುಪ್ತಪದ, ನಾನು ಆಶಿಸಲು ಬಯಸುತ್ತೇನೆ, ನಂತರ ಉಪ್ಪು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಕಾಲಮ್ನಲ್ಲಿದೆ.
ಸರಳವಾದ ಪ್ರಶ್ನೆಗೆ ನೇರವಾಗಿ ಹೋಗೋಣ: ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಎಂದಿಗೂ ಸಂಗ್ರಹಿಸಬೇಡಿ! ಎಂದಿಗೂ. ಒಂದೇ ಒಂದು ದುರ್ಬಲತೆ , ಒಂದು ಅಸಡ್ಡೆ ಬ್ಯಾಕಪ್, ಅಥವಾ ಡಜನ್‌ಗಟ್ಟಲೆ ಇತರ ಸರಳ ತಪ್ಪುಗಳಲ್ಲಿ ಒಂದು - ಮತ್ತು ಅಷ್ಟೇ, ಗೇಮ್‌ಓವರ್, ನಿಮ್ಮ ಎಲ್ಲಾ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು - ಅಂದರೆ, ಕ್ಷಮಿಸಿ, ನಿಮ್ಮ ಎಲ್ಲಾ ಗ್ರಾಹಕರ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್ ಆಗುತ್ತದೆ. ಸಹಜವಾಗಿ, ಇದು ಒಂದು ದೊಡ್ಡ ಸಂಭವನೀಯತೆಯನ್ನು ಅರ್ಥೈಸುತ್ತದೆ ಇತರ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿನ ಅವರ ಎಲ್ಲಾ ಖಾತೆಗಳಿಂದ. ಮತ್ತು ಅದು ನಿಮ್ಮ ತಪ್ಪು.
ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಅದರ ದೌರ್ಬಲ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ಗೂಢಲಿಪೀಕರಣದ ಸಮಸ್ಯೆ ಡೀಕ್ರಿಪ್ಶನ್ ಆಗಿದೆ; ನಾವು ಈ ಅಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುವ ಸೈಫರ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಸರಳ ಪಠ್ಯಕ್ಕೆ ಪರಿವರ್ತಿಸಬಹುದು ಮತ್ತು ಅದು ಸಂಭವಿಸಿದಾಗ ನಾವು ಮಾನವ-ಓದಬಹುದಾದ ಪಾಸ್ವರ್ಡ್ ಪರಿಸ್ಥಿತಿಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ? ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಕೋಡ್‌ನಲ್ಲಿ ಒಂದು ಸಣ್ಣ ನ್ಯೂನತೆಯು ಸಿಗುತ್ತದೆ, ಅದು ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ - ಇದು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲಾದ ಯಂತ್ರಕ್ಕೆ ಹ್ಯಾಕರ್‌ಗಳು ಪ್ರವೇಶವನ್ನು ಪಡೆಯುತ್ತಾರೆ - ಇದು ಎರಡನೇ ವಿಧಾನವಾಗಿದೆ. ಮತ್ತೊಂದು ರೀತಿಯಲ್ಲಿ, ಮತ್ತೊಮ್ಮೆ, ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕಪ್ ಅನ್ನು ಕದಿಯುವುದು ಮತ್ತು ಯಾರಾದರೂ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕೀಲಿಯನ್ನು ಸಹ ಪಡೆಯುತ್ತಾರೆ, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ಇದು ನಮ್ಮನ್ನು ಹ್ಯಾಶಿಂಗ್‌ಗೆ ತರುತ್ತದೆ. ಹ್ಯಾಶಿಂಗ್ ಹಿಂದಿನ ಕಲ್ಪನೆಯೆಂದರೆ ಅದು ಏಕಮುಖವಾಗಿದೆ; ಬಳಕೆದಾರ-ನಮೂದಿಸಿದ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಅದರ ಹ್ಯಾಶ್ ಮಾಡಿದ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೋಲಿಸುವ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ಇನ್‌ಪುಟ್ ಅನ್ನು ಹ್ಯಾಶ್ ಮಾಡುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಹೋಲಿಸುವುದು. ಮಳೆಬಿಲ್ಲು ಕೋಷ್ಟಕಗಳಂತಹ ಸಾಧನಗಳಿಂದ ದಾಳಿಯನ್ನು ತಡೆಗಟ್ಟಲು, ನಾವು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಉಪ್ಪು ಹಾಕುತ್ತೇವೆ (ನನ್ನನ್ನು ಓದಿ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಂಗ್ರಹಣೆಯ ಬಗ್ಗೆ). ಅಂತಿಮವಾಗಿ, ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ಹ್ಯಾಶ್ ಮಾಡಿದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಎಂದಿಗೂ ಸರಳ ಪಠ್ಯವಾಗುವುದಿಲ್ಲ ಎಂದು ನಾವು ವಿಶ್ವಾಸ ಹೊಂದಬಹುದು (ನಾನು ಇನ್ನೊಂದು ಪೋಸ್ಟ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಹ್ಯಾಶಿಂಗ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಪ್ರಯೋಜನಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ).
ಹ್ಯಾಶಿಂಗ್ ವರ್ಸಸ್ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕುರಿತು ತ್ವರಿತ ವಾದ: ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಹ್ಯಾಶ್ ಮಾಡುವ ಬದಲು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಏಕೈಕ ಕಾರಣವೆಂದರೆ ನೀವು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಸರಳ ಪಠ್ಯದಲ್ಲಿ ನೋಡಬೇಕಾದಾಗ, ಮತ್ತು ನೀವು ಇದನ್ನು ಎಂದಿಗೂ ಬಯಸಬಾರದು, ಕನಿಷ್ಠ ಪ್ರಮಾಣಿತ ವೆಬ್‌ಸೈಟ್ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ. ನಿಮಗೆ ಇದು ಅಗತ್ಯವಿದ್ದರೆ, ಹೆಚ್ಚಾಗಿ ನೀವು ಏನಾದರೂ ತಪ್ಪು ಮಾಡುತ್ತಿದ್ದೀರಿ!
ಎಚ್ಚರಿಕೆ
ಪೋಸ್ಟ್‌ನ ಪಠ್ಯದಲ್ಲಿ ಕೆಳಗೆ ಅಶ್ಲೀಲ ವೆಬ್‌ಸೈಟ್ ಅಲೋಟ್‌ಪೋರ್ನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನ ಭಾಗವಿದೆ. ಇದನ್ನು ನೀಟಾಗಿ ಟ್ರಿಮ್ ಮಾಡಲಾಗಿದೆ ಆದ್ದರಿಂದ ನೀವು ಕಡಲತೀರದಲ್ಲಿ ಏನೂ ಕಾಣುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಇನ್ನೂ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುವ ಸಾಧ್ಯತೆಯಿದ್ದರೆ, ಕೆಳಗೆ ಸ್ಕ್ರಾಲ್ ಮಾಡಬೇಡಿ.
ಯಾವಾಗಲೂ ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಿ ಎಂದಿಗೂ ಅವನನ್ನು ನೆನಪಿಸಬೇಡ
ಕಾರ್ಯವನ್ನು ರಚಿಸಲು ನಿಮ್ಮನ್ನು ಎಂದಾದರೂ ಕೇಳಿದ್ದೀರಾ ಜ್ಞಾಪನೆಗಳು ಗುಪ್ತಪದ? ಒಂದು ಹೆಜ್ಜೆ ಹಿಂತಿರುಗಿ ಮತ್ತು ಈ ವಿನಂತಿಯನ್ನು ಹಿಮ್ಮುಖವಾಗಿ ಯೋಚಿಸಿ: ಈ "ಜ್ಞಾಪನೆ" ಏಕೆ ಅಗತ್ಯ? ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಪಾಸ್ವರ್ಡ್ ಮರೆತಿದ್ದಾರೆ. ನಾವು ನಿಜವಾಗಿಯೂ ಏನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ? ಅವನಿಗೆ ಮತ್ತೆ ಲಾಗಿನ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡಿ.
"ಜ್ಞಾಪನೆ" ಪದವನ್ನು ಆಡುಮಾತಿನ ಅರ್ಥದಲ್ಲಿ (ಸಾಮಾನ್ಯವಾಗಿ) ಬಳಸಲಾಗಿದೆ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ, ಆದರೆ ನಾವು ನಿಜವಾಗಿಯೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದು ಮತ್ತೆ ಆನ್‌ಲೈನ್‌ನಲ್ಲಿರಲು ಬಳಕೆದಾರರಿಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಸಹಾಯ ಮಾಡಿ. ನಮಗೆ ಭದ್ರತೆಯ ಅಗತ್ಯವಿರುವುದರಿಂದ, ಜ್ಞಾಪನೆ (ಅಂದರೆ ಬಳಕೆದಾರರಿಗೆ ಅವರ ಪಾಸ್ವರ್ಡ್ ಕಳುಹಿಸುವುದು) ಸೂಕ್ತವಲ್ಲ ಎಂಬುದಕ್ಕೆ ಎರಡು ಕಾರಣಗಳಿವೆ:
- ಇಮೇಲ್ ಅಸುರಕ್ಷಿತ ಚಾನಲ್ ಆಗಿದೆ. ನಾವು HTTP ಯ ಮೂಲಕ ಸೂಕ್ಷ್ಮವಾದ ಯಾವುದನ್ನೂ ಕಳುಹಿಸದಂತೆಯೇ (ನಾವು HTTPS ಅನ್ನು ಬಳಸುತ್ತೇವೆ), ಅದರ ಸಾರಿಗೆ ಪದರವು ಅಸುರಕ್ಷಿತವಾಗಿರುವ ಕಾರಣ ನಾವು ಇಮೇಲ್ ಮೂಲಕ ಸೂಕ್ಷ್ಮವಾದ ಯಾವುದನ್ನೂ ಕಳುಹಿಸಬಾರದು. ವಾಸ್ತವವಾಗಿ, ಇದು ಅಸುರಕ್ಷಿತ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿದೆ, ಏಕೆಂದರೆ ಮೇಲ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಶೇಖರಣಾ ಸಾಧನದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಗೆ ಪ್ರವೇಶಿಸಬಹುದು, ಫಾರ್ವರ್ಡ್ ಮತ್ತು ವಿತರಣೆ, ಮಾಲ್‌ವೇರ್‌ಗೆ ಪ್ರವೇಶಿಸಬಹುದು, ಇತ್ಯಾದಿ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದ ಇಮೇಲ್ ಅತ್ಯಂತ ಅಸುರಕ್ಷಿತ ಚಾನಲ್ ಆಗಿದೆ.
- ಹೇಗಾದರೂ ನೀವು ಪಾಸ್ವರ್ಡ್ಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರಬಾರದು. ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಹಿಂದಿನ ವಿಭಾಗವನ್ನು ಮರು-ಓದಿರಿ - ನೀವು ಪಾಸ್‌ವರ್ಡ್‌ನ ಹ್ಯಾಶ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು (ಉತ್ತಮ ಬಲವಾದ ಉಪ್ಪಿನೊಂದಿಗೆ), ಅಂದರೆ ನೀವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಹೊರತೆಗೆಯಲು ಮತ್ತು ಮೇಲ್ ಮೂಲಕ ಕಳುಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ನಾನು ಸಮಸ್ಯೆಯನ್ನು ಉದಾಹರಣೆಯೊಂದಿಗೆ ಪ್ರದರ್ಶಿಸುತ್ತೇನೆ : ಒಂದು ವಿಶಿಷ್ಟವಾದ ಲಾಗಿನ್ ಪುಟ ಇಲ್ಲಿದೆ:
ನಿಸ್ಸಂಶಯವಾಗಿ, ಮೊದಲ ಸಮಸ್ಯೆಯೆಂದರೆ ಲಾಗಿನ್ ಪುಟವು HTTPS ಮೂಲಕ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ, ಆದರೆ ಪಾಸ್ವರ್ಡ್ ಕಳುಹಿಸಲು ಸೈಟ್ ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತದೆ ("ಪಾಸ್ವರ್ಡ್ ಕಳುಹಿಸಿ"). ಇದು ಮೇಲೆ ತಿಳಿಸಿದ ಪದದ ಆಡುಮಾತಿನ ಬಳಕೆಯ ಉದಾಹರಣೆಯಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಒಂದು ಹೆಜ್ಜೆ ಮುಂದೆ ತೆಗೆದುಕೊಂಡು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
ದುರದೃಷ್ಟವಶಾತ್ ಇದು ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತಿಲ್ಲ; ಮತ್ತು ಇಮೇಲ್ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ:
ಇದು usoutdoor.com ನ ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ನಮಗೆ ಹೇಳುತ್ತದೆ:
- ಸೈಟ್ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡುವುದಿಲ್ಲ. ಅತ್ಯುತ್ತಮವಾಗಿ, ಅವುಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗಿದೆ, ಆದರೆ ಅವುಗಳನ್ನು ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ; ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ನಾವು ಯಾವುದೇ ಪುರಾವೆಗಳನ್ನು ಕಾಣುವುದಿಲ್ಲ.
- ಅಸುರಕ್ಷಿತ ಚಾನೆಲ್ ಮೂಲಕ ಸೈಟ್ ದೀರ್ಘಾವಧಿಯ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ (ನಾವು ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಬಳಸಬಹುದು).
ಇದು ಹೊರಗುಳಿಯುವುದರೊಂದಿಗೆ, ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುರಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಮಾಡಲಾಗಿದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ. ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಲು ವಿನಂತಿಸುವವರಿಗೆ ಹಕ್ಕಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಇದನ್ನು ಮಾಡಲು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಇದಕ್ಕೂ ಮೊದಲು ನಮಗೆ ಗುರುತಿನ ಪರಿಶೀಲನೆ ಅಗತ್ಯವಿದೆ; ವಿನಂತಿಸುವವರು ವಾಸ್ತವವಾಗಿ ಖಾತೆಯ ಮಾಲೀಕರೇ ಎಂಬುದನ್ನು ಮೊದಲು ಪರಿಶೀಲಿಸದೆಯೇ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ಬಳಕೆದಾರರ ಹೆಸರುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು ಮತ್ತು ಅನಾಮಧೇಯತೆಯ ಮೇಲೆ ಅದರ ಪ್ರಭಾವ
ಈ ಸಮಸ್ಯೆಯನ್ನು ದೃಷ್ಟಿಗೋಚರವಾಗಿ ಉತ್ತಮವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ಸಮಸ್ಯೆ:
ನೀವು ನೋಡುತ್ತೀರಾ? "ಈ ಇಮೇಲ್ ವಿಳಾಸದೊಂದಿಗೆ ಯಾವುದೇ ಬಳಕೆದಾರರು ನೋಂದಾಯಿಸಲ್ಪಟ್ಟಿಲ್ಲ" ಎಂಬ ಸಂದೇಶಕ್ಕೆ ಗಮನ ಕೊಡಿ. ಅಂತಹ ಸೈಟ್ ದೃಢೀಕರಿಸಿದರೆ ಸಮಸ್ಯೆ ನಿಸ್ಸಂಶಯವಾಗಿ ಉದ್ಭವಿಸುತ್ತದೆ ಲಭ್ಯತೆ ಅಂತಹ ಇಮೇಲ್ ವಿಳಾಸದೊಂದಿಗೆ ನೋಂದಾಯಿಸಲಾದ ಬಳಕೆದಾರರು. ಬಿಂಗೊ - ನೀವು ನಿಮ್ಮ ಪತಿ/ಬಾಸ್/ನೆರೆಯವರ ಅಶ್ಲೀಲ ಮಾಂತ್ರಿಕತೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೀರಿ!
ಸಹಜವಾಗಿ, ಅಶ್ಲೀಲತೆಯು ಗೌಪ್ಯತೆಯ ಪ್ರಾಮುಖ್ಯತೆಗೆ ಸಾಕಷ್ಟು ಸಾಂಪ್ರದಾಯಿಕ ಉದಾಹರಣೆಯಾಗಿದೆ, ಆದರೆ ನಿರ್ದಿಷ್ಟ ವೆಬ್‌ಸೈಟ್‌ನೊಂದಿಗೆ ವ್ಯಕ್ತಿಯನ್ನು ಸಂಯೋಜಿಸುವ ಅಪಾಯಗಳು ಮೇಲೆ ವಿವರಿಸಿದ ಸಂಭಾವ್ಯ ವಿಚಿತ್ರವಾದ ಪರಿಸ್ಥಿತಿಗಿಂತ ಹೆಚ್ಚು ವಿಸ್ತಾರವಾಗಿದೆ. ಒಂದು ಅಪಾಯವೆಂದರೆ ಸಾಮಾಜಿಕ ಎಂಜಿನಿಯರಿಂಗ್; ದಾಳಿಕೋರನು ಸೇವೆಯೊಂದಿಗೆ ವ್ಯಕ್ತಿಯನ್ನು ಹೊಂದಿಸಬಹುದಾದರೆ, ಅವನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಬಹುದಾದ ಮಾಹಿತಿಯನ್ನು ಅವನು ಹೊಂದಿರುತ್ತಾನೆ. ಉದಾಹರಣೆಗೆ, ಅವನು ವೆಬ್‌ಸೈಟ್‌ನ ಪ್ರತಿನಿಧಿಯಾಗಿ ನಟಿಸುವ ವ್ಯಕ್ತಿಯನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಬದ್ಧತೆಯ ಪ್ರಯತ್ನದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸಬಹುದು .
ಅಂತಹ ಅಭ್ಯಾಸಗಳು "ಬಳಕೆದಾರಹೆಸರು ಎಣಿಕೆ" ಯ ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ, ಆ ಮೂಲಕ ಕೇವಲ ಗುಂಪು ಪ್ರಶ್ನೆಗಳನ್ನು ನಡೆಸುವ ಮೂಲಕ ಮತ್ತು ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರ ಹೆಸರುಗಳು ಅಥವಾ ಇಮೇಲ್ ವಿಳಾಸಗಳ ಸಂಪೂರ್ಣ ಸಂಗ್ರಹಣೆಯ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ನೀವು ಎಲ್ಲಾ ಉದ್ಯೋಗಿಗಳ ಇಮೇಲ್ ವಿಳಾಸಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದೀರಾ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯಲು ಕೆಲವು ನಿಮಿಷಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ? ಹಾಗಾದರೆ ಏನು ಸಮಸ್ಯೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ!
ಪರ್ಯಾಯ ಏನು? ವಾಸ್ತವವಾಗಿ, ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಅದ್ಭುತವಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ :
ಇಲ್ಲಿ Entropay ತನ್ನ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇಮೇಲ್ ವಿಳಾಸದ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಏನನ್ನೂ ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ ಈ ವಿಳಾಸವನ್ನು ಹೊಂದಿರದ ಯಾರಿಗಾದರೂ... ನೀನೇನಾದರೂ ಸ್ವಂತ ಈ ವಿಳಾಸ ಮತ್ತು ಇದು ಸಿಸ್ಟಂನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ನಂತರ ನೀವು ಈ ರೀತಿಯ ಇಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ:
ಸಹಜವಾಗಿ, ಯಾರಾದರೂ ಇದರಲ್ಲಿ ಸ್ವೀಕಾರಾರ್ಹ ಸಂದರ್ಭಗಳು ಇರಬಹುದು ಯೋಚಿಸುತ್ತದೆನೀವು ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ನೋಂದಾಯಿಸಿದ್ದೀರಿ. ಆದರೆ ಇದು ಹಾಗಲ್ಲ, ಅಥವಾ ನಾನು ಅದನ್ನು ಬೇರೆ ಇಮೇಲ್ ವಿಳಾಸದಿಂದ ಮಾಡಿದ್ದೇನೆ. ಮೇಲೆ ತೋರಿಸಿರುವ ಉದಾಹರಣೆಯು ಎರಡೂ ಸಂದರ್ಭಗಳನ್ನು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ವಿಳಾಸವು ಹೊಂದಾಣಿಕೆಯಾದರೆ, ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು ಸುಲಭವಾಗುವಂತೆ ನೀವು ಇಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.
ಎಂಟ್ರೊಪೇ ಆಯ್ಕೆ ಮಾಡಿದ ಪರಿಹಾರದ ಸೂಕ್ಷ್ಮತೆಯು ಅದರ ಪ್ರಕಾರ ಗುರುತಿನ ಪರಿಶೀಲನೆಯನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ ಇ-ಮೇಲ್ ಯಾವುದೇ ಆನ್‌ಲೈನ್ ಪರಿಶೀಲನೆಯ ಮೊದಲು. ಕೆಲವು ಸೈಟ್‌ಗಳು ಭದ್ರತಾ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಕ್ಕಾಗಿ ಬಳಕೆದಾರರನ್ನು ಕೇಳುತ್ತವೆ (ಇದರಲ್ಲಿ ಇನ್ನಷ್ಟು) ಗೆ ಮರುಹೊಂದಿಕೆಯನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬಹುದು; ಆದಾಗ್ಯೂ, ಇದರೊಂದಿಗಿನ ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ಕೆಲವು ರೀತಿಯ ಗುರುತಿನ (ಇಮೇಲ್ ಅಥವಾ ಬಳಕೆದಾರಹೆಸರು) ಒದಗಿಸುವಾಗ ನೀವು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಬೇಕು, ಇದು ಅನಾಮಧೇಯ ಬಳಕೆದಾರರ ಖಾತೆಯ ಅಸ್ತಿತ್ವವನ್ನು ಬಹಿರಂಗಪಡಿಸದೆ ಅಂತರ್ಬೋಧೆಯಿಂದ ಉತ್ತರಿಸಲು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಈ ವಿಧಾನದೊಂದಿಗೆ ಇದೆ ಸಣ್ಣ ಕಡಿಮೆ ಉಪಯುಕ್ತತೆ ಏಕೆಂದರೆ ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಖಾತೆಯನ್ನು ಮರುಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆ ಇರುವುದಿಲ್ಲ. ಸಹಜವಾಗಿ, ಅದು ಇಮೇಲ್ ಕಳುಹಿಸುವ ಸಂಪೂರ್ಣ ಅಂಶವಾಗಿದೆ, ಆದರೆ ನಿಜವಾದ ಅಂತಿಮ ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅವರು ತಪ್ಪಾದ ವಿಳಾಸವನ್ನು ನಮೂದಿಸಿದರೆ, ಅವರು ಇಮೇಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮಾತ್ರ ಅವರು ಮೊದಲ ಬಾರಿಗೆ ತಿಳಿಯುತ್ತಾರೆ. ಇದು ಅವನ ಕಡೆಯಿಂದ ಸ್ವಲ್ಪ ಉದ್ವೇಗವನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಆದರೆ ಅಂತಹ ಅಪರೂಪದ ಪ್ರಕ್ರಿಯೆಗೆ ಪಾವತಿಸಲು ಇದು ಒಂದು ಸಣ್ಣ ಬೆಲೆಯಾಗಿದೆ.
ಮತ್ತೊಂದು ಟಿಪ್ಪಣಿ, ಸ್ವಲ್ಪ ವಿಷಯದಿಂದ ಹೊರಗಿದೆ: ಬಳಕೆದಾರಹೆಸರು ಅಥವಾ ಇಮೇಲ್ ವಿಳಾಸವು ಸರಿಯಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಲಾಗಿನ್ ಸಹಾಯ ಕಾರ್ಯಗಳು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿವೆ. ರುಜುವಾತುಗಳ ಅಸ್ತಿತ್ವವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದೃಢೀಕರಿಸುವ ಬದಲು "ನಿಮ್ಮ ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಸಂಯೋಜನೆಯು ಅಮಾನ್ಯವಾಗಿದೆ" ಎಂಬ ಸಂದೇಶದೊಂದಿಗೆ ಬಳಕೆದಾರರಿಗೆ ಯಾವಾಗಲೂ ಪ್ರತಿಕ್ರಿಯಿಸಿ (ಉದಾಹರಣೆಗೆ, "ಬಳಕೆದಾರಹೆಸರು ಸರಿಯಾಗಿದೆ, ಆದರೆ ಪಾಸ್ವರ್ಡ್ ತಪ್ಪಾಗಿದೆ").
ಮರುಹೊಂದಿಸುವ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ vs ಮರುಹೊಂದಿಸುವ URL ಅನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ
ನಾವು ಚರ್ಚಿಸಬೇಕಾದ ಮುಂದಿನ ಪರಿಕಲ್ಪನೆಯು ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದು ಹೇಗೆ. ಎರಡು ಜನಪ್ರಿಯ ಪರಿಹಾರಗಳಿವೆ:
- ಸರ್ವರ್‌ನಲ್ಲಿ ಹೊಸ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಇಮೇಲ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು
- ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು ಅನನ್ಯ URL ನೊಂದಿಗೆ ಇಮೇಲ್ ಕಳುಹಿಸಿ
ಹೊರತಾಗಿಯೂ , ಮೊದಲ ಪಾಯಿಂಟ್ ಅನ್ನು ಎಂದಿಗೂ ಬಳಸಬಾರದು. ಇದರ ಸಮಸ್ಯೆ ಎಂದರೆ ಇದೆ ಎಂದರ್ಥ ಸಂಗ್ರಹಿಸಿದ ಗುಪ್ತಪದ, ನೀವು ಯಾವ ಸಮಯದಲ್ಲಾದರೂ ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ಮತ್ತೆ ಬಳಸಬಹುದು; ಅದನ್ನು ಅಸುರಕ್ಷಿತ ಚಾನಲ್ ಮೂಲಕ ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಇನ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಉಳಿದಿದೆ. ಮೊಬೈಲ್ ಸಾಧನಗಳು ಮತ್ತು ಇಮೇಲ್ ಕ್ಲೈಂಟ್‌ನಾದ್ಯಂತ ಇನ್‌ಬಾಕ್ಸ್‌ಗಳನ್ನು ಸಿಂಕ್ ಮಾಡುವ ಸಾಧ್ಯತೆಗಳಿವೆ, ಜೊತೆಗೆ ಅವುಗಳನ್ನು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ವೆಬ್ ಇಮೇಲ್ ಸೇವೆಯಲ್ಲಿ ಬಹಳ ಸಮಯದವರೆಗೆ ಸಂಗ್ರಹಿಸಬಹುದು. ವಿಷಯವೇನೆಂದರೆ ಮೇಲ್ಬಾಕ್ಸ್ ಅನ್ನು ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆಯ ವಿಶ್ವಾಸಾರ್ಹ ಸಾಧನವೆಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.
ಆದರೆ ಇದರ ಹೊರತಾಗಿ, ಮೊದಲ ಅಂಶವು ಮತ್ತೊಂದು ಗಂಭೀರ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ - ಅದು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳಗೊಳಿಸುತ್ತದೆ ದುರುದ್ದೇಶಪೂರಿತ ಉದ್ದೇಶದಿಂದ ಖಾತೆಯನ್ನು ನಿರ್ಬಂಧಿಸುವುದು. ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಖಾತೆಯನ್ನು ಹೊಂದಿರುವವರ ಇಮೇಲ್ ವಿಳಾಸ ನನಗೆ ತಿಳಿದಿದ್ದರೆ, ಅವರ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವ ಮೂಲಕ ನಾನು ಅವರನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ನಿರ್ಬಂಧಿಸಬಹುದು; ಇದು ಬೆಳ್ಳಿಯ ತಟ್ಟೆಯಲ್ಲಿ ಸೇವೆ ಸಲ್ಲಿಸಿದ ಸೇವೆಯ ನಿರಾಕರಣೆಯಾಗಿದೆ! ಅದಕ್ಕಾಗಿಯೇ ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ವಿನಂತಿಸುವವರ ಹಕ್ಕುಗಳ ಯಶಸ್ವಿ ಪರಿಶೀಲನೆಯ ನಂತರ ಮಾತ್ರ ನಿರ್ವಹಿಸಬೇಕು.
ನಾವು ಮರುಹೊಂದಿಸುವ URL ಕುರಿತು ಮಾತನಾಡುವಾಗ, ನಾವು ವೆಬ್‌ಸೈಟ್‌ನ ವಿಳಾಸವನ್ನು ಅರ್ಥೈಸುತ್ತೇವೆ ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯ ಈ ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ ವಿಶಿಷ್ಟವಾಗಿದೆ. ಸಹಜವಾಗಿ, ಇದು ಯಾದೃಚ್ಛಿಕವಾಗಿರಬೇಕು, ಊಹಿಸಲು ಸುಲಭವಾಗಬಾರದು ಮತ್ತು ಮರುಹೊಂದಿಸಲು ಸುಲಭವಾಗಿಸುವ ಖಾತೆಗೆ ಯಾವುದೇ ಬಾಹ್ಯ ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರಬಾರದು. ಉದಾಹರಣೆಗೆ, ಮರುಹೊಂದಿಸುವ URL ಸರಳವಾಗಿ "Reset/?username=JohnSmith" ನಂತಹ ಮಾರ್ಗವಾಗಿರಬಾರದು.
ಮರುಹೊಂದಿಸುವ URL ನಂತೆ ಮೇಲ್ ಮಾಡಬಹುದಾದ ಅನನ್ಯ ಟೋಕನ್ ಅನ್ನು ನಾವು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಬಳಕೆದಾರರ ಖಾತೆಯ ಸರ್ವರ್ ರೆಕಾರ್ಡ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಈ ಮೂಲಕ ಖಾತೆಯ ಮಾಲೀಕರು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ವ್ಯಕ್ತಿಯೇ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಟೋಕನ್ "3ce7854015cd38c862cb9e14a1ae552b" ಆಗಿರಬಹುದು ಮತ್ತು ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಬಳಕೆದಾರರ ID ಮತ್ತು ಟೋಕನ್ ಅನ್ನು ರಚಿಸಲಾದ ಸಮಯದೊಂದಿಗೆ ಟೇಬಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ಇದರಲ್ಲಿ ಇನ್ನಷ್ಟು). ಇಮೇಲ್ ಕಳುಹಿಸಿದಾಗ, ಅದು “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” ನಂತಹ URL ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಅದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದಾಗ, ಪುಟವು ಟೋಕನ್‌ನ ಅಸ್ತಿತ್ವವನ್ನು ಕೇಳುತ್ತದೆ, ನಂತರ ಅದು ಬಳಕೆದಾರರ ಮಾಹಿತಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಗುಪ್ತಪದ.
ಸಹಜವಾಗಿ, ಮೇಲಿನ ಪ್ರಕ್ರಿಯೆಯು (ಆಶಾದಾಯಕವಾಗಿ) ಬಳಕೆದಾರರಿಗೆ ಹೊಸ ಪಾಸ್ವರ್ಡ್ ರಚಿಸಲು ಅನುಮತಿಸುವುದರಿಂದ, URL ಅನ್ನು HTTPS ಮೂಲಕ ಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಇಲ್ಲ, , ಈ ಟೋಕನ್ URL ಸಾರಿಗೆ ಲೇಯರ್ ಭದ್ರತೆಯನ್ನು ಬಳಸಬೇಕು ಆದ್ದರಿಂದ ಹೊಸ ಪಾಸ್ವರ್ಡ್ ಫಾರ್ಮ್ ಅನ್ನು ಆಕ್ರಮಣ ಮಾಡಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಬಳಕೆದಾರರು ರಚಿಸಿದ ಗುಪ್ತಪದವನ್ನು ಸುರಕ್ಷಿತ ಸಂಪರ್ಕದ ಮೂಲಕ ರವಾನಿಸಲಾಗಿದೆ.
ಮರುಹೊಂದಿಸುವ URL ಗಾಗಿ ನೀವು ಟೋಕನ್ ಸಮಯದ ಮಿತಿಯನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ ಇದರಿಂದ ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ನಿರ್ದಿಷ್ಟ ಮಧ್ಯಂತರದಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಒಂದು ಗಂಟೆಯೊಳಗೆ ಹೇಳಿ. ಮರುಹೊಂದಿಸುವ ಸಮಯದ ವಿಂಡೋವನ್ನು ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಲಾಗಿದೆ ಎಂದು ಇದು ಖಾತ್ರಿಪಡಿಸುತ್ತದೆ ಆದ್ದರಿಂದ ಮರುಹೊಂದಿಸುವ URL ಅನ್ನು ಸ್ವೀಕರಿಸುವವರು ಆ ಚಿಕ್ಕ ವಿಂಡೋದಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಸಹಜವಾಗಿ, ಆಕ್ರಮಣಕಾರರು ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಬಹುದು, ಆದರೆ ಅವರು ಮತ್ತೊಂದು ಅನನ್ಯ ಮರುಹೊಂದಿಸುವ URL ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
ಅಂತಿಮವಾಗಿ, ಈ ಪ್ರಕ್ರಿಯೆಯು ಬಿಸಾಡಬಹುದಾದದು ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಟೋಕನ್ ಅನ್ನು ತೆಗೆದುಹಾಕಬೇಕು ಆದ್ದರಿಂದ ಮರುಹೊಂದಿಸುವ URL ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಆಕ್ರಮಣಕಾರರು ರೀಸೆಟ್ URL ಅನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುವ ಸಮಯದಲ್ಲಿ ಆಕ್ರಮಣಕಾರರು ಬಹಳ ಚಿಕ್ಕ ವಿಂಡೋವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಹಿಂದಿನ ಅಂಶವು ಅವಶ್ಯಕವಾಗಿದೆ. ಜೊತೆಗೆ, ಸಹಜವಾಗಿ, ಮರುಹೊಂದಿಸುವಿಕೆಯು ಯಶಸ್ವಿಯಾದ ನಂತರ, ಟೋಕನ್ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲ.
ಈ ಕೆಲವು ಹಂತಗಳು ಅತಿಯಾದ ಅನಗತ್ಯವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅವುಗಳು ಉಪಯುಕ್ತತೆಗೆ ಅಡ್ಡಿಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಿ, ಆದರೆ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಪರೂಪ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. 99% ಪ್ರಕರಣಗಳಲ್ಲಿ, ಬಳಕೆದಾರರು ಬಹಳ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ಮರುಹೊಂದಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತಾರೆ ಮತ್ತು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದಿಲ್ಲ.
ಕ್ಯಾಪ್ಚಾ ಪಾತ್ರ
ಓಹ್, ಕ್ಯಾಪ್ಚಾ, ನಾವೆಲ್ಲರೂ ದ್ವೇಷಿಸಲು ಇಷ್ಟಪಡುವ ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯ! ವಾಸ್ತವವಾಗಿ, CAPTCHA ಒಂದು ಗುರುತಿನ ಸಾಧನವಾಗಿರುವುದರಿಂದ ರಕ್ಷಣೆಯ ಸಾಧನವಲ್ಲ - ನೀವು ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅಥವಾ ರೋಬೋಟ್ ಆಗಿರಲಿ (ಅಥವಾ ಸ್ವಯಂಚಾಲಿತ ಸ್ಕ್ರಿಪ್ಟ್). ಸ್ವಯಂಚಾಲಿತ ಫಾರ್ಮ್ ಸಲ್ಲಿಕೆಯನ್ನು ತಪ್ಪಿಸುವುದು ಇದರ ಉದ್ದೇಶವಾಗಿದೆ, ಇದು ಸಹಜವಾಗಿ, ಮಾಡಬಹುದು ಭದ್ರತೆಯನ್ನು ಮುರಿಯುವ ಪ್ರಯತ್ನವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವ ಸಂದರ್ಭದಲ್ಲಿ, CAPTCHA ಎಂದರೆ ಮರುಹೊಂದಿಸುವ ಕಾರ್ಯವು ಬಳಕೆದಾರರನ್ನು ಸ್ಪ್ಯಾಮ್ ಮಾಡಲು ಅಥವಾ ಖಾತೆಗಳ ಅಸ್ತಿತ್ವವನ್ನು ನಿರ್ಧರಿಸಲು ಪ್ರಯತ್ನಿಸಲು ವಿವೇಚನಾರಹಿತವಾಗಿ ಒತ್ತಾಯಿಸಲಾಗುವುದಿಲ್ಲ (ನೀವು ವಿಭಾಗದಲ್ಲಿನ ಸಲಹೆಯನ್ನು ಅನುಸರಿಸಿದರೆ ಅದು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಗುರುತುಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ).
ಸಹಜವಾಗಿ, CAPTCHA ಸ್ವತಃ ಪರಿಪೂರ್ಣವಲ್ಲ; ಅದರ ಸಾಫ್ಟ್‌ವೇರ್ "ಹ್ಯಾಕಿಂಗ್" ಮತ್ತು ಸಾಕಷ್ಟು ಯಶಸ್ಸಿನ ದರಗಳನ್ನು (60-70%) ಸಾಧಿಸಲು ಹಲವು ಪೂರ್ವನಿದರ್ಶನಗಳಿವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನನ್ನ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ತೋರಿಸಿರುವ ಪರಿಹಾರವಿದೆ , ಅಲ್ಲಿ ನೀವು ಪ್ರತಿ ಕ್ಯಾಪ್ಚಾವನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತು 94% ಯಶಸ್ಸಿನ ದರವನ್ನು ಸಾಧಿಸಲು ಜನರಿಗೆ ಶೇಕಡಾ ಭಾಗಗಳನ್ನು ಪಾವತಿಸಬಹುದು. ಅಂದರೆ, ಇದು ದುರ್ಬಲವಾಗಿರುತ್ತದೆ, ಆದರೆ ಇದು (ಸ್ವಲ್ಪ) ಪ್ರವೇಶಕ್ಕೆ ತಡೆಗೋಡೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
PayPal ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ:
ಈ ಸಂದರ್ಭದಲ್ಲಿ, CAPTCHA ಪರಿಹಾರವಾಗುವವರೆಗೆ ಮರುಹೊಂದಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸರಳವಾಗಿ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ ಸಿದ್ಧಾಂತದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು ಅಸಾಧ್ಯ. ಸಿದ್ಧಾಂತದಲ್ಲಿ.
ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ಮಿತಿಮೀರಿದ ಮತ್ತು ಖಂಡಿತವಾಗಿಯೂ ಸರಿಯಿದೆ ಉಪಯುಕ್ತತೆಯ ಇಳಿಕೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ - ಜನರು ಕ್ಯಾಪ್ಚಾವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ! ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಯಾಪ್ಚಾ ಎನ್ನುವುದು ಅಗತ್ಯವಿದ್ದರೆ ನೀವು ಸುಲಭವಾಗಿ ಹಿಂತಿರುಗಬಹುದು. ಸೇವೆಯು ಆಕ್ರಮಣಕ್ಕೆ ಒಳಗಾಗಲು ಪ್ರಾರಂಭಿಸಿದರೆ (ಇಲ್ಲಿಯೇ ಲಾಗಿಂಗ್ ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ, ಆದರೆ ಅದರ ನಂತರ ಹೆಚ್ಚಿನದು), ನಂತರ CAPTCHA ಅನ್ನು ಸೇರಿಸುವುದು ಸುಲಭವಲ್ಲ.
ರಹಸ್ಯ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಉತ್ತರಗಳು
ನಾವು ಪರಿಗಣಿಸಿದ ಎಲ್ಲಾ ವಿಧಾನಗಳೊಂದಿಗೆ, ಇಮೇಲ್ ಖಾತೆಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಮೂಲಕ ನಾವು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ನಾನು "ಕೇವಲ" ಎಂದು ಹೇಳುತ್ತೇನೆ, ಆದರೆ, ಬೇರೆಯವರ ಇಮೇಲ್ ಖಾತೆಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುವುದು ಕಾನೂನುಬಾಹಿರವಾಗಿದೆ. ಮಾಡಬೇಕಾದುದು ಒಂದು ಸಂಕೀರ್ಣ ಪ್ರಕ್ರಿಯೆ. ಆದಾಗ್ಯೂ .
ವಾಸ್ತವವಾಗಿ, ಸಾರಾ ಪಾಲಿನ್‌ರ Yahoo! ಹ್ಯಾಕಿಂಗ್ ಕುರಿತು ಮೇಲಿನ ಲಿಂಕ್! ಎರಡು ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ; ಮೊದಲನೆಯದಾಗಿ, (ಕೆಲವು) ಇಮೇಲ್ ಖಾತೆಗಳನ್ನು ಹ್ಯಾಕ್ ಮಾಡುವುದು ಎಷ್ಟು ಸುಲಭ ಎಂಬುದನ್ನು ಇದು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ದುರುದ್ದೇಶಪೂರಿತ ಉದ್ದೇಶದಿಂದ ಕೆಟ್ಟ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಇದು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ನಂತರ ಇದಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.
XNUMX% ಇಮೇಲ್ ಆಧಾರಿತ ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವ ಸಮಸ್ಯೆಯೆಂದರೆ ನೀವು ಮರುಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸೈಟ್‌ನ ಖಾತೆಯ ಸಮಗ್ರತೆಯು ಇಮೇಲ್ ಖಾತೆಯ ಸಮಗ್ರತೆಯ ಮೇಲೆ XNUMX% ಅವಲಂಬಿತವಾಗಿದೆ. ನಿಮ್ಮ ಇಮೇಲ್‌ಗೆ ಪ್ರವೇಶ ಹೊಂದಿರುವ ಯಾರಾದರೂ ಇಮೇಲ್ ಸ್ವೀಕರಿಸುವ ಮೂಲಕ ಮರುಹೊಂದಿಸಬಹುದಾದ ಯಾವುದೇ ಖಾತೆಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದೆ. ಅಂತಹ ಖಾತೆಗಳಿಗಾಗಿ, ಇಮೇಲ್ ನಿಮ್ಮ ಆನ್‌ಲೈನ್ ಜೀವನದ "ಎಲ್ಲಾ ಬಾಗಿಲುಗಳಿಗೆ ಕೀ" ಆಗಿದೆ.
ಈ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವೆಂದರೆ ಭದ್ರತಾ ಪ್ರಶ್ನೆ ಮತ್ತು ಉತ್ತರ ಮಾದರಿಯನ್ನು ಅಳವಡಿಸುವುದು. ನೀವು ಅವರನ್ನು ಈಗಾಗಲೇ ನೋಡಿದ್ದೀರಿ ಎಂಬುದರಲ್ಲಿ ಸಂದೇಹವಿಲ್ಲ: ನೀವು ಮಾತ್ರ ಉತ್ತರಿಸಬಹುದಾದ ಪ್ರಶ್ನೆಯನ್ನು ಆರಿಸಿ ಮಾಡಬೇಕಾದುದು ಉತ್ತರವನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ, ಮತ್ತು ನಂತರ ನೀವು ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಿದಾಗ ಅದನ್ನು ಕೇಳಲಾಗುತ್ತದೆ. ಮರುಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ವ್ಯಕ್ತಿಯು ನಿಜವಾಗಿಯೂ ಖಾತೆಯ ಮಾಲೀಕರೇ ಎಂಬ ವಿಶ್ವಾಸವನ್ನು ಇದು ಸೇರಿಸುತ್ತದೆ.
ಸಾರಾ ಪಾಲಿನ್‌ಗೆ ಹಿಂತಿರುಗಿ: ತಪ್ಪು ಅವರ ಭದ್ರತಾ ಪ್ರಶ್ನೆ/ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳನ್ನು ಸುಲಭವಾಗಿ ಕಂಡುಹಿಡಿಯಬಹುದು. ವಿಶೇಷವಾಗಿ ನೀವು ಅಂತಹ ಮಹತ್ವದ ಸಾರ್ವಜನಿಕ ವ್ಯಕ್ತಿಯಾಗಿರುವಾಗ, ನಿಮ್ಮ ತಾಯಿಯ ಮೊದಲ ಹೆಸರು, ಶೈಕ್ಷಣಿಕ ಇತಿಹಾಸ ಅಥವಾ ಹಿಂದೆ ಯಾರಾದರೂ ಎಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದರು ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯು ರಹಸ್ಯವಾಗಿರುವುದಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ, ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ಬಹುತೇಕ ಯಾರಾದರೂ ಕಾಣಬಹುದು. ಇದು ಸಾರಾಳೊಂದಿಗೆ ಸಂಭವಿಸಿದೆ:
ಹ್ಯಾಕರ್ ಡೇವಿಡ್ ಕರ್ನೆಲ್ ಪಾಲಿನ್ರವರ ಖಾತೆಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆದುಕೊಂಡರು, ಆಕೆಯ ವಿಶ್ವವಿದ್ಯಾಲಯ ಮತ್ತು ಜನ್ಮ ದಿನಾಂಕದಂತಹ ಆಕೆಯ ಹಿನ್ನೆಲೆಯ ಬಗ್ಗೆ ವಿವರಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೂಲಕ ಮತ್ತು ನಂತರ Yahoo! ನ ಮರೆತುಹೋದ ಪಾಸ್ವರ್ಡ್ ಮರುಪಡೆಯುವಿಕೆ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಿದರು.
ಮೊದಲನೆಯದಾಗಿ, ಇದು Yahoo! ನ ವಿನ್ಯಾಸ ದೋಷವಾಗಿದೆ! - ಅಂತಹ ಸರಳ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ, ಕಂಪನಿಯು ಮೂಲಭೂತವಾಗಿ ಭದ್ರತಾ ಪ್ರಶ್ನೆಯ ಮೌಲ್ಯವನ್ನು ಹಾಳುಮಾಡಿತು ಮತ್ತು ಆದ್ದರಿಂದ ಅದರ ವ್ಯವಸ್ಥೆಯ ರಕ್ಷಣೆ. ಸಹಜವಾಗಿ, ಇಮೇಲ್ ಖಾತೆಗಾಗಿ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು ಮರುಹೊಂದಿಸುವುದು ಯಾವಾಗಲೂ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ಮಾಲೀಕರಿಗೆ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಮೂಲಕ ಮಾಲೀಕತ್ವವನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ (ಎರಡನೇ ವಿಳಾಸವನ್ನು ಹೊಂದಿಲ್ಲ), ಆದರೆ ಅದೃಷ್ಟವಶಾತ್ ಇಂದು ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲು ಹೆಚ್ಚಿನ ಉಪಯೋಗಗಳಿಲ್ಲ.
ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ - ಬಳಕೆದಾರರು ತಮ್ಮದೇ ಆದ ಪ್ರಶ್ನೆಗಳನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುವ ಆಯ್ಕೆ ಇದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ ಇದು ಭಯಾನಕ ಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ:
ಆಕಾಶದ ಬಣ್ಣ ಯಾವುದು?
ಸುರಕ್ಷತಾ ಪ್ರಶ್ನೆಯನ್ನು ಗುರುತಿಸಲು ಬಳಸಿದಾಗ ಜನರು ಅನಾನುಕೂಲತೆಯನ್ನು ಉಂಟುಮಾಡುವ ಪ್ರಶ್ನೆಗಳು ವ್ಯಕ್ತಿ (ಉದಾಹರಣೆಗೆ, ಕರೆ ಕೇಂದ್ರದಲ್ಲಿ):
ಕ್ರಿಸ್ಮಸ್ನಲ್ಲಿ ನಾನು ಯಾರೊಂದಿಗೆ ಮಲಗಿದ್ದೆ?
ಅಥವಾ ಸ್ಪಷ್ಟವಾಗಿ ಮೂರ್ಖ ಪ್ರಶ್ನೆಗಳು:
ನೀವು "ಪಾಸ್ವರ್ಡ್" ಅನ್ನು ಹೇಗೆ ಉಚ್ಚರಿಸುತ್ತೀರಿ?
ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಬಂದಾಗ, ಬಳಕೆದಾರರು ತಮ್ಮಿಂದಲೇ ಉಳಿಸಿಕೊಳ್ಳಬೇಕು! ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಭದ್ರತಾ ಪ್ರಶ್ನೆಯನ್ನು ಸೈಟ್ ಸ್ವತಃ ನಿರ್ಧರಿಸಬೇಕು ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮವಾಗಿ ಕೇಳಬೇಕು ಸರಣಿ ಬಳಕೆದಾರರು ಆಯ್ಕೆ ಮಾಡಬಹುದಾದ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳು. ಮತ್ತು ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಸುಲಭವಲ್ಲ один; ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಬಳಕೆದಾರರು ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು ಖಾತೆ ನೋಂದಣಿ ಸಮಯದಲ್ಲಿ, ನಂತರ ಇದನ್ನು ಎರಡನೇ ಗುರುತಿನ ಚಾನಲ್ ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಬಹು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿರುವುದು ಪರಿಶೀಲನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ವಿಶ್ವಾಸವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಸೇರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ (ಯಾವಾಗಲೂ ಒಂದೇ ಪ್ರಶ್ನೆಯನ್ನು ತೋರಿಸುವುದಿಲ್ಲ), ಜೊತೆಗೆ ನಿಜವಾದ ಬಳಕೆದಾರರು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರೆತಿದ್ದರೆ ಸ್ವಲ್ಪ ಪುನರಾವರ್ತನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಉತ್ತಮ ಭದ್ರತಾ ಪ್ರಶ್ನೆ ಯಾವುದು? ಇದು ಹಲವಾರು ಅಂಶಗಳಿಂದ ಪ್ರಭಾವಿತವಾಗಿರುತ್ತದೆ:
- ಅವನು ಇರಬೇಕು ಸಂಕ್ಷಿಪ್ತ - ಪ್ರಶ್ನೆಯು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು ಮತ್ತು ನಿಸ್ಸಂದಿಗ್ಧವಾಗಿರಬೇಕು.
- ಉತ್ತರ ಇರಬೇಕು ನಿರ್ದಿಷ್ಟ - ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ವಿಭಿನ್ನವಾಗಿ ಉತ್ತರಿಸಬಹುದಾದ ಪ್ರಶ್ನೆ ನಮಗೆ ಅಗತ್ಯವಿಲ್ಲ
- ಸಂಭವನೀಯ ಉತ್ತರಗಳು ಇರಬೇಕು ವೈವಿಧ್ಯಮಯ - ಯಾರೊಬ್ಬರ ನೆಚ್ಚಿನ ಬಣ್ಣವನ್ನು ಕೇಳುವುದು ಸಂಭವನೀಯ ಉತ್ತರಗಳ ಒಂದು ಸಣ್ಣ ಉಪವಿಭಾಗವನ್ನು ನೀಡುತ್ತದೆ
- Поиск ಉತ್ತರವು ಸಂಕೀರ್ಣವಾಗಿರಬೇಕು - ಉತ್ತರವನ್ನು ಸುಲಭವಾಗಿ ಕಂಡುಹಿಡಿಯಬಹುದಾದರೆ ಯಾವುದೇ (ಉನ್ನತ ಸ್ಥಾನದಲ್ಲಿರುವ ಜನರನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಿ), ಆಗ ಅವನು ಕೆಟ್ಟವನು
- ಉತ್ತರ ಇರಬೇಕು ಶಾಶ್ವತ ಸಮಯಕ್ಕೆ - ನೀವು ಯಾರೊಬ್ಬರ ನೆಚ್ಚಿನ ಚಲನಚಿತ್ರವನ್ನು ಕೇಳಿದರೆ, ಒಂದು ವರ್ಷದ ನಂತರ ಉತ್ತರವು ವಿಭಿನ್ನವಾಗಿರಬಹುದು
ಇದು ಸಂಭವಿಸಿದಂತೆ, ಎಂಬ ಉತ್ತಮ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಮೀಸಲಾದ ವೆಬ್‌ಸೈಟ್ ಇದೆ . ಕೆಲವು ಪ್ರಶ್ನೆಗಳು ಸಾಕಷ್ಟು ಉತ್ತಮವೆಂದು ತೋರುತ್ತದೆ, ಇತರರು ಮೇಲೆ ವಿವರಿಸಿದ ಕೆಲವು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ "ಹುಡುಕಾಟದ ಸುಲಭ" ಪರೀಕ್ಷೆ.
PayPal ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ, ದೃಢೀಕರಣಕ್ಕಾಗಿ ಸೈಟ್ ಮಾಡುವ ಪ್ರಯತ್ನವನ್ನು ನಾನು ಪ್ರದರ್ಶಿಸುತ್ತೇನೆ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾವು ಪುಟವನ್ನು ನೋಡಿದ್ದೇವೆ (ಕ್ಯಾಪ್ಚಾದೊಂದಿಗೆ), ಮತ್ತು ನೀವು ನಿಮ್ಮ ಇಮೇಲ್ ವಿಳಾಸವನ್ನು ನಮೂದಿಸಿದ ನಂತರ ಮತ್ತು CAPTCHA ಅನ್ನು ಪರಿಹರಿಸಿದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಇಲ್ಲಿ ತೋರಿಸುತ್ತೇವೆ:
ಪರಿಣಾಮವಾಗಿ, ಬಳಕೆದಾರರು ಈ ಕೆಳಗಿನ ಪತ್ರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ:
ಇಲ್ಲಿಯವರೆಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಆದರೆ ಈ ಮರುಹೊಂದಿಸುವ URL ಹಿಂದೆ ಏನು ಮರೆಮಾಡಲಾಗಿದೆ:
ಆದ್ದರಿಂದ, ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತವೆ. ವಾಸ್ತವವಾಗಿ, ನಿಮ್ಮ ಕ್ರೆಡಿಟ್ ಕಾರ್ಡ್ ಸಂಖ್ಯೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು PayPal ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಸೈಟ್‌ಗಳು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರದ ಹೆಚ್ಚುವರಿ ಚಾನಲ್ ಇದೆ. ನಾನು ಉತ್ತರಿಸದೆ ನನ್ನ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎರಡೂ ಭದ್ರತಾ ಪ್ರಶ್ನೆ (ಅಥವಾ ಕಾರ್ಡ್ ಸಂಖ್ಯೆ ತಿಳಿದಿಲ್ಲ). ಯಾರಾದರೂ ನನ್ನ ಇಮೇಲ್ ಅನ್ನು ಹೈಜಾಕ್ ಮಾಡಿದರೂ ಸಹ, ನನ್ನ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ವೈಯಕ್ತಿಕ ಮಾಹಿತಿ ತಿಳಿಯದ ಹೊರತು ಅವರು ನನ್ನ PayPal ಖಾತೆಯ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಯಾವ ಮಾಹಿತಿ? PayPal ನೀಡುವ ಭದ್ರತಾ ಪ್ರಶ್ನೆ ಆಯ್ಕೆಗಳು ಇಲ್ಲಿವೆ:
ಹುಡುಕಾಟದ ಸುಲಭದ ವಿಷಯದಲ್ಲಿ ಶಾಲೆ ಮತ್ತು ಆಸ್ಪತ್ರೆಯ ಪ್ರಶ್ನೆಯು ಸ್ವಲ್ಪ ಇಫ್ಫೀ ಆಗಿರಬಹುದು, ಆದರೆ ಇತರವು ತುಂಬಾ ಕೆಟ್ಟದ್ದಲ್ಲ. ಆದಾಗ್ಯೂ, ಭದ್ರತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು, PayPal ಗೆ ಹೆಚ್ಚುವರಿ ಗುರುತಿನ ಅಗತ್ಯವಿದೆ ಬದಲಾವಣೆಗಳನ್ನು ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳು:
PayPal ಸುರಕ್ಷಿತ ಪಾಸ್ವರ್ಡ್ ರೀಸೆಟ್‌ಗಳ ಒಂದು ಸುಂದರವಾದ ಯುಟೋಪಿಯನ್ ಉದಾಹರಣೆಯಾಗಿದೆ: ಇದು ವಿವೇಚನಾರಹಿತ ದಾಳಿಯ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು CAPTCHA ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಎರಡು ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ನಂತರ ಉತ್ತರಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತೊಂದು ರೀತಿಯ ಸಂಪೂರ್ಣ ವಿಭಿನ್ನ ಗುರುತಿನ ಅಗತ್ಯವಿರುತ್ತದೆ - ಮತ್ತು ಇದು ಬಳಕೆದಾರರ ನಂತರ ಈಗಾಗಲೇ ಸೈನ್ ಇನ್ ಮಾಡಲಾಗಿದೆ. ಸಹಜವಾಗಿ, ಇದು ನಿಖರವಾಗಿ ನಾವು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ PayPal ನಿಂದ; ದೊಡ್ಡ ಮೊತ್ತದ ಹಣವನ್ನು ವ್ಯವಹರಿಸುವ ಹಣಕಾಸು ಸಂಸ್ಥೆಯಾಗಿದೆ. ಪ್ರತಿ ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಕೆಯು ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಬೇಕು ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ-ಬಹುತೇಕ ಸಮಯ ಅದು ಮಿತಿಮೀರಿದ-ಆದರೆ ಭದ್ರತೆಯು ಗಂಭೀರ ವ್ಯವಹಾರವಾಗಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ.
ಭದ್ರತಾ ಪ್ರಶ್ನೆ ವ್ಯವಸ್ಥೆಯ ಅನುಕೂಲವೆಂದರೆ ನೀವು ಅದನ್ನು ಈಗಿನಿಂದಲೇ ಕಾರ್ಯಗತಗೊಳಿಸದಿದ್ದರೆ, ಸಂಪನ್ಮೂಲ ರಕ್ಷಣೆಯ ಮಟ್ಟವು ಅಗತ್ಯವಿದ್ದರೆ ನೀವು ಅದನ್ನು ನಂತರ ಸೇರಿಸಬಹುದು. ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆಯೆಂದರೆ ಆಪಲ್, ಇದು ಇತ್ತೀಚೆಗೆ ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಜಾರಿಗೆ ತಂದಿದೆ [2012 ರಲ್ಲಿ ಬರೆದ ಲೇಖನ]. ಒಮ್ಮೆ ನಾನು ನನ್ನ ಐಪ್ಯಾಡ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ನಾನು ಈ ಕೆಳಗಿನ ವಿನಂತಿಯನ್ನು ನೋಡಿದೆ:
ನಂತರ ನಾನು ಹಲವಾರು ಜೋಡಿ ಸುರಕ್ಷತಾ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಆಯ್ಕೆಮಾಡಬಹುದಾದ ಪರದೆಯನ್ನು ನೋಡಿದೆ, ಹಾಗೆಯೇ ಪಾರುಗಾಣಿಕಾ ಇಮೇಲ್ ವಿಳಾಸ:
PayPal ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಪ್ರಶ್ನೆಗಳನ್ನು ಮೊದಲೇ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೆಲವು ನಿಜವಾಗಿಯೂ ಉತ್ತಮವಾಗಿವೆ:
ಪ್ರತಿಯೊಂದು ಮೂರು ಪ್ರಶ್ನೆ/ಉತ್ತರ ಜೋಡಿಗಳು ವಿಭಿನ್ನ ಸಂಭಾವ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಖಾತೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಕಷ್ಟು ಮಾರ್ಗಗಳಿವೆ.
ನಿಮ್ಮ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಕುರಿತು ಪರಿಗಣಿಸಬೇಕಾದ ಇನ್ನೊಂದು ಅಂಶವೆಂದರೆ ಸಂಗ್ರಹಣೆ. ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸರಳ ಪಠ್ಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಂದಿರುವುದು ಪಾಸ್‌ವರ್ಡ್‌ನಂತೆಯೇ ಒಂದೇ ರೀತಿಯ ಬೆದರಿಕೆಗಳನ್ನು ಒಡ್ಡುತ್ತದೆ, ಅಂದರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬಹಿರಂಗಪಡಿಸುವುದು ಮೌಲ್ಯವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಪಾಯವನ್ನುಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಅದೇ ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ (ಮತ್ತೆ ಇದೆ. ) ಒಂದು ಆಯ್ಕೆಯು ಸುರಕ್ಷಿತ ಹ್ಯಾಶಿಂಗ್ ಆಗಿದೆ (ಬಲವಾದ ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕವಾಗಿ ಯಾದೃಚ್ಛಿಕ ಉಪ್ಪು), ಆದರೆ ಹೆಚ್ಚಿನ ಪಾಸ್ವರ್ಡ್ ಶೇಖರಣಾ ಪ್ರಕರಣಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಪ್ರತಿಕ್ರಿಯೆಯು ಸರಳ ಪಠ್ಯದಂತೆ ಗೋಚರಿಸಲು ಉತ್ತಮ ಕಾರಣವಿರಬಹುದು. ಒಂದು ವಿಶಿಷ್ಟ ಸನ್ನಿವೇಶವೆಂದರೆ ಲೈವ್ ಟೆಲಿಫೋನ್ ಆಪರೇಟರ್‌ನಿಂದ ಗುರುತಿನ ಪರಿಶೀಲನೆ. ಸಹಜವಾಗಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹ್ಯಾಶಿಂಗ್ ಸಹ ಅನ್ವಯಿಸುತ್ತದೆ (ಆಯೋಜಕರು ಕ್ಲೈಂಟ್ ಹೆಸರಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸರಳವಾಗಿ ನಮೂದಿಸಬಹುದು), ಆದರೆ ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ರಹಸ್ಯ ಪ್ರತಿಕ್ರಿಯೆಯು ಕೇವಲ ಸಮ್ಮಿತೀಯ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಆಗಿದ್ದರೂ ಸಹ, ಕೆಲವು ಮಟ್ಟದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ನೆಲೆಗೊಂಡಿರಬೇಕು. . ಸಾರಾಂಶ: ರಹಸ್ಯಗಳನ್ನು ರಹಸ್ಯಗಳಂತೆ ಪರಿಗಣಿಸಿ!
ಭದ್ರತಾ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಉತ್ತರಗಳ ಒಂದು ಅಂತಿಮ ಅಂಶವೆಂದರೆ ಅವರು ಸಾಮಾಜಿಕ ಎಂಜಿನಿಯರಿಂಗ್‌ಗೆ ಹೆಚ್ಚು ದುರ್ಬಲರಾಗಿದ್ದಾರೆ. ಬೇರೊಬ್ಬರ ಖಾತೆಗೆ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ನೇರವಾಗಿ ಹೊರತೆಗೆಯಲು ಪ್ರಯತ್ನಿಸುವುದು ಒಂದು ವಿಷಯ, ಆದರೆ ಅದರ ರಚನೆಯ ಬಗ್ಗೆ ಸಂಭಾಷಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು (ಜನಪ್ರಿಯ ಭದ್ರತಾ ಪ್ರಶ್ನೆ) ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ನೀವು ಯಾರೊಂದಿಗಾದರೂ ಅವರ ಜೀವನದ ಹಲವು ಅಂಶಗಳ ಬಗ್ಗೆ ಚೆನ್ನಾಗಿ ಸಂವಹನ ಮಾಡಬಹುದು, ಅದು ಅನುಮಾನವನ್ನು ಉಂಟುಮಾಡದೆ ರಹಸ್ಯ ಪ್ರಶ್ನೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಸಹಜವಾಗಿ, ಭದ್ರತಾ ಪ್ರಶ್ನೆಯ ಮುಖ್ಯ ಅಂಶವೆಂದರೆ ಅದು ಯಾರೊಬ್ಬರ ಜೀವನ ಅನುಭವಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಆದ್ದರಿಂದ ಇದು ಸ್ಮರಣೀಯವಾಗಿದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಇರುವುದು ಅಲ್ಲಿಯೇ - ಜನರು ತಮ್ಮ ಜೀವನದ ಅನುಭವಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಇಷ್ಟಪಡುತ್ತಾರೆ! ಅಂತಹ ಭದ್ರತಾ ಪ್ರಶ್ನೆಯ ಆಯ್ಕೆಗಳನ್ನು ನೀವು ಆರಿಸಿದರೆ ಮಾತ್ರ ನೀವು ಇದರ ಬಗ್ಗೆ ಸ್ವಲ್ಪವೇ ಮಾಡಬಹುದು ಕಡಿಮೆ ಬಹುಶಃ ಸಾಮಾಜಿಕ ಇಂಜಿನಿಯರಿಂಗ್ ಮೂಲಕ ಹೊರತೆಗೆಯಬಹುದು.
[ಮುಂದುವರಿಯುವುದು.]ಜಾಹೀರಾತು ಹಕ್ಕುಗಳ ಮೇಲೆ
VDSina ವಿಶ್ವಾಸಾರ್ಹ ನೀಡುತ್ತದೆ , ಪ್ರತಿ ಸರ್ವರ್ ಅನ್ನು 500 ಮೆಗಾಬಿಟ್‌ಗಳ ಇಂಟರ್ನೆಟ್ ಚಾನಲ್‌ಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಮತ್ತು ಉಚಿತವಾಗಿ DDoS ದಾಳಿಯಿಂದ ರಕ್ಷಿಸಲಾಗಿದೆ!
ಮೂಲ: www.habr.com