ऑटो-लॉगिन को सुरक्षित रूप से कैसे लागू करें


15

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

सॉफ्टवेयर के कई टुकड़ों में यह सुविधा है, ब्राउज़र से लेकर ड्रॉपबॉक्स जैसे कार्यक्रमों तक।

मैंने हाल ही में एक पुराना लेख पढ़ा था कि ड्रॉपबॉक्स आपके कंप्यूटर पर एक आईडी कैसे जमा कर रहा था जिसे आप बस दूसरे कंप्यूटर में कॉपी / पेस्ट कर सकते हैं और ड्रॉपबॉक्स शुरू कर सकते हैं और उस डिवाइस के रूप में लॉग इन किया जा सकता है, जिस पर आपको आईडी मिली थी; ड्रॉपबॉक्स खाते में कोई लॉगिन, कोई कुछ नहीं, और पूर्ण पहुंच। यह वास्तव में बेवकूफ डिजाइन की तरह लगता है, लेकिन मैं इसे करने का कोई बेहतर तरीका नहीं सोच सकता।

मुझे यह भी पता नहीं है कि सादे-पाठ में कुकी जैसी चीज़ के भंडारण से कैसे बचा जाए। यदि आप इसे एन्क्रिप्ट करते हैं, तो आप इसे डिक्रिप्ट करने के लिए कुंजी कहाँ संग्रहीत करते हैं?

एकमात्र तरीका जो मैं सुरक्षा कमजोरियों का परिचय नहीं देता, वह है ऑटोलॉगिन फीचर को हटाना और उपयोगकर्ता को हर बार अपना पासवर्ड टाइप करना जिससे वे एक सेवा का उपयोग करना चाहते हैं, लेकिन यह एक प्रयोज्य संघर्ष है और उपयोगकर्ताओं को ऐसा न करने की उम्मीद करने के लिए खराब हो जाता है।

स्वचालित लॉगिन सुविधा को लागू करने के लिए मैं स्थानीय रूप से सुरक्षित क्रेडेंशियल्स के बारे में क्या पढ़ सकता हूं? यदि सिद्धांत पूरे लेख के लिए बहुत सरल हैं, तो वे क्या हैं? विचाराधीन सॉफ़्टवेयर को सभी प्लेटफार्मों पर मौजूद सुविधाओं पर निर्भर नहीं होना चाहिए (जैसे "कीचेन" कुछ लिनक्स वितरण में है)।


2
यह उस बारे में है जिस पर आप भरोसा करते हैं। अगर आपको मशीन की आईडी पर भरोसा नहीं है तो यह आपकी समस्या है। यदि आप किचेन पर भरोसा करते हैं तो वह है अधिकतम सुरक्षा जो आपको मिलेगी। बेशक आप कुछ कस्टम सुरक्षा जोड़ सकते हैं जैसे कि डिवाइस हार्डवेयर या किसी चीज़ का पता लगाना, लेकिन यह सब नकली-सक्षम है ताकि आप अंत में नहीं जान सकें। यह आपके नियंत्रण से बाहर है। बंद पाठ की तरह स्पष्ट बेवकूफ पासवर्ड को बचाने की तरह बेवकूफ बातें।
ल्यूक फ्रेंकेन

@ LucFranken आप मशीन पर कैसे भरोसा कर सकते हैं? कोई आपका शोषण कर सकता है जैसे उन्होंने ड्रॉपबॉक्स किया था। इसके अलावा, मैं किचेन पर भरोसा करूंगा लेकिन सभी कंप्यूटरों में एक नहीं है, और विंडोज कभी नहीं करता है (एएफएआईके)। और यदि आप पासवर्ड स्टोर कर रहे हैं, तो आप उन्हें स्पष्ट-पाठ में संग्रहीत करने से कैसे बचते हैं? यदि आप उन्हें एन्क्रिप्ट करते हैं, तो आप इसे डिक्रिप्ट करने के लिए कुंजी कहाँ संग्रहीत करते हैं?
जय साइमन

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

@LucFranken यह सिर्फ मुझे है या ऑटोलॉगिन एक सर्वव्यापी सुविधा की तरह प्रतीत होता है? यदि ऐसा है, तो लोगों ने यह नहीं लिखा है कि इसे सही कैसे किया जाए?
जे साइमन

यह एक बहुत ही सामान्य आवश्यकता है हालांकि कुछ और उद्यम सॉफ्टवेयर इसकी अनुमति नहीं देते हैं। उदाहरण के लिए SalesForce केवल उपयोगकर्ता नाम को बचाने की अनुमति देता है, न कि पासवर्ड को। स्पष्ट btw डालते हैं। कि आपको लॉगिन के लिए क्लाइंट पर पासवर्ड स्टोर करने की आवश्यकता नहीं है। आप एक यादृच्छिक हैश को स्टोर कर सकते हैं जो सर्वर पर हैश से मेल खाता है।
ल्यूक फ्रेंकेन

जवाबों:


12

एक तरीका है:

  • जब उपयोगकर्ता लॉग इन करता है, तो क्लाइंट के कंप्यूटर (उपयोगकर्ता नाम या पासवर्ड नहीं) पर एक कुकी में एक सत्र आईडी स्टोर करें ।
  • आईपी ​​पते के लिए सत्र टाई, इसलिए एक व्यक्तिगत सत्र आईडी केवल उस कंप्यूटर के साथ काम करती है जिस पर इसे शुरू किया गया था।

आपकी साइट को विकसित करने के लिए आप किस ढांचे का उपयोग कर रहे हैं, इसके आधार पर, यह व्यवहार एक अंतर्निहित सुविधा के रूप में उपलब्ध हो सकता है।

ध्यान दें कि, क्योंकि HTTP प्रोटोकॉल वैसे भी स्टेटलेस है, वास्तव में वेबसाइट का उपयोग करने के एकल सत्र के दौरान किसी को लॉग इन रखने और साइट का उपयोग करने के बाद अगली बार "ऑटो-लॉगिन" के बीच कोई कार्यात्मक अंतर नहीं है; यह पूरी तरह से एक बात है कि सत्र समाप्त होने से पहले आप कितना समय देते हैं।

अपडेट: इसके अलावा, बढ़ी हुई सुरक्षा के लिए HTTPS का उपयोग करें, जाहिर है।

अद्यतन 2: ध्यान दें कि इस दृष्टिकोण की सीमाएँ हैं, इसमें यह उन उपयोगकर्ताओं के लिए अच्छा काम नहीं करता है जो अपना आईपी पता बहुत बदल लेते हैं। हालाँकि, यह सुरक्षा का बढ़ा हुआ स्तर प्रदान करता है और कुछ स्थितियों में उपयोगी हो सकता है।


1
इसे IP पते पर बाँधने से बहुत मदद नहीं मिलती क्योंकि किसी के पास ऐसा कंप्यूटर हो सकता है जो उसी फ़ायरवॉल के पीछे हो जैसा कि आप हैं।
जे साइमन

2
@JaySimon, मैं यह नहीं कहूंगा कि "बहुत मदद नहीं करता है"। दुनिया में जितने भी कंप्यूटर हैं, उनकी तुलना में समान फ़ायरवॉल के पीछे कंप्यूटर की संख्या बहुत कम है। यह हमले के लिए आपके संभावित जोखिम को सीमित करने के बारे में है, और यह इसे बहुत सीमित करता है। यह एक मानक दृष्टिकोण है, और मुझे नहीं लगता कि इसके अलावा भी बहुत कुछ है। यदि किसी के पास उपयोगकर्ता के समान आईपी पता है और एक सत्र ID प्राप्त करने का प्रबंधन करता है, तो वह व्यक्ति सर्वर के दृष्टिकोण से उपयोगकर्ता से अप्रभेद्य होगा। यदि आपकी साइट पर किसी भी प्रकार का लॉग-इन है, तो आप इस तरह के हमले के संपर्क में हैं।

3
क्या आपको लगता है कि इस तरह के दृष्टिकोण से मोबाइल फोन पर उपयोगकर्ताओं को गुस्सा आएगा, जिनके आईपी पते में अक्सर बदलाव हो सकता है?
जे साइमन

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

IP को सत्र को प्रतिबंधित करना वास्तव में वास्तविक नहीं है। उपयोगकर्ता अक्सर स्थान बदलते हैं। मोबाइल फोन के साथ लेकिन लैपटॉप के साथ भी; उदाहरण के लिए फ्लेक्स काम करना। सबसे अच्छा आप कर सकते हैं कुछ जियोआईपी चेक उस दूरी की यात्रा करने के लिए समय के साथ जोड़ती है; जैसे जीमेल करता है।
लोड ’

5

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

तो हाँ, जो लोग आपके कंप्यूटर तक पहुँच प्राप्त करते हैं, वे आपके सत्र को रोक सकते हैं, लेकिन आपको अभी भी वही मिलता है जो वे ऑर्डर करते हैं! (इससे भी महत्वपूर्ण बात, एक सत्र को हाईजैक करने के लिए प्रोत्साहन बहुत अधिक नकारात्मक है।) लेकिन अगर किसी के पास मेरे कंप्यूटर तक पहुंच है, तो मुझे औसत साइट सत्रों को चोरी करने वाले लोगों की तुलना में बड़ी समस्याएं हैं।

यदि आपके पास अपने एप्लिकेशन के ऐसे हिस्से हैं, जिन्हें उच्च सुरक्षा की आवश्यकता नहीं है, तो आप एक हाइब्रिड मॉडल चुन सकते हैं, जहां आप सत्र आईडी (हैश या जो भी चाहें) को ऑटो लॉगिन उपयोगकर्ताओं को साइट के कम सुरक्षा भागों में संग्रहीत कर सकते हैं , लेकिन उन्हें पासवर्ड की आवश्यकता होती है जब उच्च सुरक्षा क्षेत्रों में प्रवेश करें और सत्र समाप्त होने पर उच्च सुरक्षा टोकन हटा दें।

बेशक अगर यह एक बैंकिंग स्तर की साइट है, तो ऑटो लॉगिन एक विकल्प नहीं है। फिर से, इस प्रकार की सुरक्षा का उपयोग करने वाली साइटें मानती हैं कि वे जिस डेटा की सुरक्षा कर रही हैं उसका मूल्य और उपयोगकर्ता को अतिरिक्त सुविधा के साथ अपहृत सत्र के संभावित जोखिम को तौलना है। अगर आपको लगता है कि आपके आवेदन के मामले में ऐसा नहीं है, तो ऑटो लॉगिन लागू न करें। आपको यह उपयोग करने की आवश्यकता है कि आपके उपयोग के मामले के लिए किस स्तर की सुरक्षा / उपयोगिता व्यापार नापसंद उचित है।


2

यह वास्तव में उतना कठिन नहीं है। पहले इस प्रारूप के साथ एक कुकी स्टोर करें:

userID.token

आप टोकन के लिए sha1 हैश का उपयोग कर सकते हैं। तब आपके याद में_मे_टोकेंस डेटाबेस टेबल स्टोर यूजरआईडी, टोकन का एक bcrypt हैश और टोकन उत्पन्न होने का समय।

फिर जब कोई आपकी साइट पर जाता है, तो यह देखने के लिए जांचें कि कुकी सेट है या नहीं। यदि कुकी सेट है, तो देखें कि पिछले 7 दिनों के भीतर डेटाबेस में इसके लिए कोई मान्य पंक्ति है या नहीं। यदि कुकी के लिए डेटाबेस में एक मान्य पंक्ति है, तो यह इंगित करने के लिए सत्र सेट करें कि उपयोगकर्ता लॉग इन है और साथ ही मिलान किए गए कुकी / डेटाबेस पंक्ति को हटा दें और एक नया कुकी / टोकन / डेटाबेस पंक्ति उत्पन्न करें।

अगर वे लॉग आउट करते हैं तो कुकी को हटा दें।

याद रखने के लिए एक क्रॉन जॉब चलाएं_मे_टोकेंस जो कि 7 दिनों से अधिक पुराना है।


किसी को इस कुंजी को कॉपी करने और उनकी मशीन पर चिपकाने और उपयोगकर्ता नाम या पासवर्ड के बिना खाते तक पहुंचने से क्या रोकता है?
जय साइमन

आप कैसे कुंजी प्राप्त करने जा रहे हैं? यह किसी के कंप्यूटर पर स्थानीय रूप से संग्रहीत है।
रयान

आप कंप्यूटर पर चलते हैं और उस फ़ाइल को खोलते हैं जहाँ यह संग्रहीत है :)
Jay Simon

2
@JaySimon यह तर्क किसी ऐसे व्यक्ति के लिए किया जा सकता है जो अपने कंप्यूटर को लॉक किए बिना लॉग इन करता है और 5 मिनट के लिए दूर चला जाता है, या मुझे याद रखें क्लिक करता है और कोई व्यक्ति अपने खाते के पासवर्ड पर कूदता है। यदि आप इस संभावित सुरक्षा स्थिति को स्वीकार कर सकते हैं, तो इसकी सुविधा अच्छी है, लेकिन यही कारण है कि आपको सीआईए एनओसी सूची में एक याद मुझे सुविधा नहीं दिखती है :) सर्वर को आपको कुछ प्रकार के टोकन देने होंगे जो क्लाइंट को स्टोर करना होगा फाइलसिस्टम पर। हालांकि यह सर्वर के नजरिए से आपके हाथों में नहीं है।
maple_shaft

@maple_shaft क्यों किसी को आश्चर्य हुआ कि आप ड्रॉपबॉक्स के लिए ऐसा कर सकते हैं? (मैंने इसे अपने प्रश्न में जोड़ा।)
जय साइमन

0

आप केवल तभी कर सकते हैं जब आप उस उपकरण पर भरोसा करते हैं जहां आप इसे संग्रहीत करते हैं। यह उपयोगकर्ता पर निर्भर है (यदि आप डिवाइस को प्रभावित नहीं कर सकते हैं) यह कितना सुरक्षित है। यह बस आपके हाथ से बाहर है।

जैसा कि टिप्पणियों में कहा गया है:

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.