2013-01-02 31 views
11

मैं कोडिंग एक 'me' सुसज्जित लॉगिन फार्म, और अब तक ट्यूटोरियल मैं पढ़ा है याद के बीच में हूँ सब एक में एन्क्रिप्टेड पासवर्ड स्टोर करने के लिए कहते हैं (आंशिक रूप से यह सही यकीन है कि मैं कर रहा हूँ करने के लिए) उपयोगकर्ता नाम के साथ कुकी। फिर, प्रत्येक बार PHP जांचता है कि वर्तमान उपयोगकर्ता लॉग इन नहीं है, तो अपनी कुकीज़ जांचें और उन मानों को देखें। उपयोगकर्ता नाम पासवर्ड से मेल खाता है, तो आप कर रहे हैं।PHP "मुझे याद रखें" सुरक्षा दोष?

मेरे लिए

, यह एक भारी सुरक्षा छेद है। अगर कोई डेटाबेस को हैक करना था या किसी भी तरह से एन्क्रिप्टेड पासवर्ड तक पहुंच प्राप्त करना था, तो उन्हें उन्हें क्रैक करने की भी आवश्यकता नहीं होगी। बस अपनी खुद की कुकीज़ सेट करें और जाओ। क्या मैं सही हूँ, या सिर्फ पागल हो रहा हूँ?

मेरा प्रवेश प्रणाली वर्तमान उपयोगकर्ता आईडी का ट्रैक रखने के सत्र का उपयोग करता है, और एक त्वरित/में लॉग इन के लिए एक 1/0 जांच लॉग आउट। उपयोगकर्ता AFAIK सत्र संपादित नहीं कर सकता है, इसलिए यह सुरक्षित है (यदि यह नहीं है, तो कृपया मुझे बताएं)। मैं सिर्फ एक कुकी में सत्र आईडी संग्रहीत करने के बारे में सोच रहा था, बाद में इसे फिर से शुरू करने के लिए, लेकिन यह भी सुरक्षित नहीं है।

मैं अपने उपयोगकर्ताओं की सुरक्षा की बहुत परवाह करते, मैं कैसे ठीक से, जबकि अभी भी कार्यशील वेबसाइट को बनाए रखने उनकी जानकारी की सुरक्षा कर सकते हैं?

+0

मैं एन्क्रिप्टेड पासवर्ड स्टोर नहीं करता, केवल एक कुकी में user_ID जो एक्स दिनों में समाप्त हो जाता है। "संवेदनशील" क्षेत्रों (उदाहरण के लिए खाता/प्रोफाइल प्रबंधन) के लिए, यदि आप वैध $ _SESSION (जो आपको लॉगिन करते समय सेट करना चाहिए) के लिए लॉगिन करने की आवश्यकता हो सकती है। – JennyDanger

+1

यदि आप कुकी में संग्रहीत करते हैं तो आप वर्तमान में सत्र आईडी कैसे संग्रहीत कर रहे हैं "सुरक्षित नहीं है?" –

+0

@georgefox वर्तमान में, मैं किसी भी चीज़ में सत्र आईडी संग्रहीत नहीं कर रहा हूं, मैं बस इतना कह रहा था कि यह मुझे याद रखने की संभावना है। – Scott

उत्तर

11

आमतौर पर जब सर्वर करने का अनुरोध किया है उपयोगकर्ता याद रखें, यह सामान्य सत्र कुकी के बगल में एक अतिरिक्त कुकी जारी करता है, और इस नए स्ट्रिंग उपयोगकर्ता नाम और यादृच्छिक वर्ण जो यह unguessable बनाने का एक उचित मात्रा में होता है। यह स्पष्ट रूप से डेटाबेस में सहेजा गया है (सुरक्षा कारणों से आप इसे पासवर्ड की तरह व्यवहार करना चाहते हैं और इस प्रकार नमक और हैश इसे), और अगली बार जब उपयोगकर्ता एक ही ब्राउज़र से कनेक्ट होता है (पुराना सत्र समाप्त हो जाता है) तो एप्लिकेशन को प्राप्त होता है यादृच्छिक स्ट्रिंग, डेटाबेस की जांच करता है, और यदि कोई मिलान है तो उपयोगकर्ता प्रमाणीकृत है।

एक वैकल्पिक कुछ राशि से आगे सत्र समाप्ति समय बढ़ रहा है।

यहां सुरक्षा छेद क्या हैं? बशर्ते आप एक अच्छा यादृच्छिक जनरेटर का उपयोग करें, केवल एक चीज जो हो सकती है वह यह है कि उपयोगकर्ता किसी साझा ब्राउज़र से एप्लिकेशन तक पहुंचता है और जब यह समाप्त होता है तो मैन्युअल रूप से लॉग आउट नहीं होता है।

सामान्य नियम हमेशा लागू जब से तुम एक असुरक्षित चैनल पर हैं: HTTPS का उपयोग करें, अन्यथा जो कोई भी अपने कंप्यूटर और सर्वर कुकीज़ चोरी कर सकते हैं के बीच में बैठता है (या तो सत्र एक या याद मुझे एक) और ऐसा लगता है जैसे यह आप थे।

Bonus, this must-read by Jeff Atwood

+0

यह जाने के लिए एक अच्छा तरीका लगता है, धन्यवाद! इसके अलावा, उस राक्षस लॉगिन पोस्ट को अभी पढ़ना! – Scott

-3

मुझे अपनी वेबसाइट पर काम करते समय भी यही समस्या आई है, मुझे हल करने के लिए सबसे अच्छा तरीका यह है कि केवल पासवर्ड याद नहीं रखना, केवल उपयोगकर्ता नाम, एक तेज़ लॉगजिन प्रदान करना, लेकिन कम सुरक्षित नहीं। तथ्य यह है कि पासवर्ड को सुरक्षित रखने के लिए कोई निश्चित रास्ता नहीं है। नए ब्राउज़र के अलावा, उपयोगकर्ता को अपने ब्राउज़र को याद रखना पड़ सकता है।

लेकिन अगर आप सहेजा गया पासवर्ड होना आवश्यक है, इस प्रयास करें:

कई कुकीज़ है, 2 सबसे आसान होगा, और एक एन्क्रिप्टेड पासवर्ड के लिए एक का उपयोग करें, अन्य एक एन्क्रिप्शन कुंजी आयोजित करता है। डेटाबेस में पासवर्ड आपके संग्रहित एन्क्रिप्शन कुंजी का उपयोग करके प्राप्त एक और एन्क्रिप्टेड पासवर्ड रखेगा। जब आप पासवर्ड जांचने के लिए तैयार होते हैं, तो मान निकालें और पासवर्ड एन्क्रिप्ट करें।

आशा है कि यह सहायक होगा। सौभाग्य!

संपादित करें: मैं इस गलत समझा हो सकता है, यदि उपयोगकर्ता अभी भी में लॉग ऑन है, यह एक सत्र चर स्टोर करने के लिए अच्छा अभ्यास है।

+1

किसी भी तरह से पासवर्ड को कभी भी सुरक्षित न करें (एन्क्रिप्टेड पासवर्ड जिसे लॉगिन करने के लिए इस्तेमाल किया जा सकता है अभी भी एक पासवर्ड है) क्लाइंट पर। केवल सर्वर पर संग्रहीत कुंजी को सहेजें। इन चाबियों को बाद में रद्द कर दिया जा सकता है लेकिन एन्क्रिप्टेड पासवर्ड बदले जाने तक मान्य होगा। –

+0

यह जरूरी नहीं है क्योंकि कोई समाप्ति तिथि निर्धारित करेगा; हालांकि, मैं अपनी दूसरी विधि का उपयोग नहीं करना चाहूंगा। – Zero

0

आप इसे सुरक्षित करना चाहते हैं, अपने उपयोगकर्ताओं को आपके में लॉग इन रखने की अनुमति देते न तो।

जब सत्र की स्थापना,, सत्र आईडी के लिए IPADDRESS बाध्य करने के लिए इतना है कि अगर किसी को उठाता है सुनिश्चित करें बाद में एक सत्र में, यह केवल एक ही आईपी पते से किया जा सकता है। यो डेटाबेस (हैश) सत्र आईडी + हैडहेड्रेस के साथ डेटाबेस रखकर ऐसा कर सकता है। मैं सत्र हैंडलर और आईपैड्रेस के साथ मिलान सत्र सेट करने के लिए phps function http://php.net/manual/en/class.sessionhandler.php का उपयोग करता हूं।

+1

आईपी पते का उपयोग सुरक्षा के लिए नहीं किया जाना है और आप आईपी पते पर भरोसा नहीं कर सकते हैं। आईपी ​​चेक, जैसा कि आप इंगित करते हैं, फिर भी बुरे लोगों के लिए जीवन कठिन बना देता है। –

2

किसी भी तरह से पासवर्ड को कभी भी सहेज न दें (एन्क्रिप्टेड पासवर्ड जिसे लॉगिन करने के लिए इस्तेमाल किया जा सकता है अभी भी एक पासवर्ड है) क्लाइंट पर।

सर्वर पर सुरक्षित रूप से संग्रहीत यादृच्छिक रूप से जेनरेट की गई कुंजी का उपयोग करें। इन चाबियों को बाद में एन्क्रिप्टेड पासवर्ड के विपरीत निरस्त किया जा सकता है जो बदले जाने तक वैध होंगे।

PHP का उपयोग करके आप इस md5(uniqid(mt_rand(), true)) की तरह यादृच्छिक कुंजी उत्पन्न कर सकते हैं। बेहतर सुरक्षा स्टोर के लिए इसे नमकीन और डीबी में धोया गया।

उदाहरण तालिका:

login_keys (
    user_id int, 
    key char(40), # sha1 
    salt char(15) 
) 

यह भी ध्यान रखें कि आप HTTP केवल कुकी विकल्प को सक्षम होना चाहिए।