क्यों "अपना खुद का" प्रमाणीकरण एक टाइम बम है
\n\nहर दूसरा PHP डेवलपर कम से कम एक बार अपना स्वयं का लॉगिन सिस्टम लिखता है। यह सरल लगता है: फॉर्म, लॉगिन जांच, सत्र। लेकिन यहीं, इस "सरल" चरण पर, लाखों साइटें नष्ट हो जाती हैं। SQL इंजेक्शन, सत्र चोरी, पासवर्ड अनुमान — ऐसे हमले जो आपके प्रोजेक्ट को व्यक्तिगत डेटा वितरण में बदल देते हैं।
\n\nइस लेख में हम शुरू से PHP में सुरक्षित प्रमाणीकरण पर चर्चा करेंगे। कोई जादू नहीं — केवल सिद्ध अभ्यास जो Facebook, GitHub और आपके पसंदीदा फ्रेमवर्क में उपयोग होते हैं। आप सीखेंगे कि पासवर्ड को सही तरीके से कैसे हैश करें, सत्रों को इंटरसेप्ट होने से कैसे बचाएं और JWT जैसी आधुनिक तंत्रों को कैसे लागू करें।
\n\nतैयार हैं? चलिए शुरू करते हैं।
\n\n1. पासवर्ड हैशिंग: क्यों md5() एक मौत की सजा है
\n\nसुरक्षा का पहला नियम: कभी भी पासवर्ड को सादे टेक्स्ट में न रखें। दूसरा नियम: MD5 या SHA1 जैसे पुराने एल्गोरिदम का उपयोग न करें। वे माइक्रोसेकंड में गणना कर लेते हैं, और लैपटॉप वाला कोई भी छात्र एक घंटे में आपका पासवर्ड ढूंढ लेगा।
\n\nPHP में एक अंतर्निहित समाधान है — फंक्शन password_hash() और password_verify()। वे bcrypt (या Argon2, यदि PHP ≥ 7.2) का उपयोग करते हैं और स्वचालित रूप से "सॉल्ट" जोड़ते हैं — एक यादृच्छिक स्ट्रिंग जो प्रत्येक हैश को अद्वितीय बनाती है।
सही हैशिंग का उदाहरण
\n// उपयोगकर्ता पंजीकरण\n$password = $_POST['password'];\n$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);\n\n// $hash को डेटाबेस में सहेजें\n// मैन्युअल रूप से कोई सॉल्ट नहीं! PHP सब कुछ स्वयं करेगा।\n\n\nलॉगिन पर पासवर्ड सत्यापन
\n// उपयोगकर्ता लॉगिन\n$inputPassword = $_POST['password'];\n$storedHash = 'डेटाबेस से';\n\nif (password_verify($inputPassword, $storedHash)) {\n // पासवर्ड सही है — प्रवेश दें\n} else {\n // पासवर्ड गलत है\n}\n\n\nपैरामीटर cost पर ध्यान दें। यह हैश गणना की "लागत" निर्धारित करता है। संख्या जितनी अधिक होगी, हमलावर को पासवर्ड अनुमान लगाने में उतना ही अधिक समय लगेगा। 2024 के लिए cost = 12 सुरक्षा और गति के बीच एक सुनहरा मध्य है।
2. सत्र: घर की चाबियाँ कैसे न दें
\n\nसफल लॉगिन के बाद हम आमतौर पर एक सत्र शुरू करते हैं। लेकिन मानक PHP सत्रों में कमजोरियाँ हैं: अनुमानित ID, URL के माध्यम से लीक, सत्र निर्धारण (session fixation)।
\n\nसुरक्षित सत्र कॉन्फ़िगरेशन
\n// स्क्रिप्ट की शुरुआत में, किसी भी HTML आउटपुट से पहले\nini_set('session.use_only_cookies', 1);\nini_set('session.use_strict_mode', 1);\nini_set('session.cookie_httponly', 1);\nini_set('session.cookie_secure', 1); // केवल HTTPS के लिए\nini_set('session.cookie_samesite', 'Lax');\n\nsession_start();\n\n// लॉगिन के बाद सत्र ID को पुनर्जीवित करें\nif ($login_success) {\n session_regenerate_id(true);\n $_SESSION['user_id'] = $user['id'];\n}\n\n\nहमने क्या किया:
\n- \n
- use_only_cookies — URL के माध्यम से सत्र ID के प्रसारण को प्रतिबंधित करें (ताकि इसे लिंक से चुराया न जा सके) \n
- use_strict_mode — अप्रारंभित सत्रों को ब्लॉक करें \n
- httponly — सत्र कुकी तक JavaScript की पहुंच को प्रतिबंधित करें (XSS से सुरक्षा) \n
- secure — कुकी केवल HTTPS पर प्रेषित होती है \n
- samesite — क्रॉस-साइट अनुरोध जालसाजी (CSRF) हमलों से सुरक्षा \n
और सबसे महत्वपूर्ण: लॉगिन के बाद हमेशा सत्र ID को पुनर्जीवित करें। अन्यथा, हमलावर पहले से उपयोगकर्ता को अपना session ID दे सकता है और खाते को इंटरसेप्ट कर सकता है।
\n\n3. CSRF से सुरक्षा: जाँच करें कि अनुरोध आपके द्वारा भेजा गया है
\n\nCSRF (Cross-Site Request Forgery) — एक हमला जहाँ उपयोगकर्ता /delete-account?id=1 जैसे लिंक पर क्लिक करता है और अनजाने में कोई कार्रवाई करता है। इससे बचने के लिए, टोकन का उपयोग करें।
CSRF टोकन का निर्माण और सत्यापन
\n// टोकन निर्माण (सत्र की शुरुआत में या फॉर्म लोड करते समय)\nif (empty(