मैंने यहां "मुझे याद रखें" विकल्प के लिए कुकी का उपयोग करने के बारे में बहुत कुछ पढ़ा है, लेकिन जो मैं ढूंढ रहा हूं वह एक तरीका है दो-कारक प्रमाणीकरण की सफलता रिकॉर्ड करने के लिए एक कुकी तैयार करें। उदाहरण के लिए, Google ऐसा करता है: यदि दूसरा चरण सफल होता है (उदाहरण के लिए, आपने कोड के माध्यम से प्राप्त कोड दर्ज किया है), तो यह एक कुकी को समय के लिए अच्छा सेट करता है (उदाहरण के लिए, 30 दिन) जिसका अर्थ है कि दूसरा कदम बाईपास किया जा सकता है। इसे "सत्यापन कुकी" पर कॉल करें। मेरी समझ यह है कि अगर उस समय आप लॉगआउट करते हैं और फिर फिर से, यह दूसरा कदम नहीं करेगा, लेकिन केवल पहला कदम होगा। (मैंने इसका परीक्षण किया और यह मामला प्रतीत होता था।)दो-कारक प्रमाणीकरण सफलता (लगातार लॉगिन नहीं) को याद रखने के लिए कुकी की आवश्यकता है
मेरा सवाल यह है कि इस कुकी को कैसे डिजाइन किया जाए। एक विचार कुकी में उपयोगकर्ता आईडी और एक 128-बिट यादृच्छिक संख्या डालना है, और फिर उस आईडी को उपयोगकर्ता आईडी के साथ डेटाबेस में संग्रहीत करना है। चार्ल्स मिलर लगातार-लॉगिन कुकीज़ के लिए (http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/) की सिफारिश करता है।
हालांकि, यह काफी अच्छा नहीं है, मुझे लगता है। समस्या यह है कि, चूंकि उपयोगकर्ता दो-कारक प्राधिकरण का उपयोग कर रहा है, इसलिए जो भी कुकी का उपयोग यह रिकॉर्ड करने के लिए किया जाता है कि दूसरा चरण सफल था, एक कारक प्राधिकरण के मामले में सुरक्षित होना चाहिए।
जो मैं टालना चाहता हूं वह यह है: क्रैकर के पास डेटाबेस से शेड/नमकीन पासवर्ड हैं, और किसी भी तरह से पासवर्ड प्राप्त हुआ है। यदि उसके पास इतना है, तो मुझे लगता है कि सत्यापन कुकी में 128-बिट यादृच्छिक संख्या भी उपलब्ध है। (यदि क्रैकर को पासवर्ड किसी अन्य तरीके से प्राप्त हुआ है, और उसके पास डेटाबेस नहीं है, तो सत्यापन कुकी सुरक्षित है जब तक कि उसके पास कंप्यूटर तक भौतिक पहुंच न हो। मैं केवल समझौता डेटाबेस केस के बारे में चिंतित हूं।)
शायद एक विचार 128-बिट यादृच्छिक संख्या एन्क्रिप्ट करना है? (2-रास्ता होने की आवश्यकता है - हैश नहीं।) एन्क्रिप्शन कुंजी एप्लिकेशन के लिए सुलभ होगी, शायद संग्रहीत डेटाबेस प्रमाण-पत्र हैं।
क्या किसी ने भी एक सत्यापन कुकी ( एक सतत लॉगिन कुकी नहीं कहा है) लागू किया है और मुझे बता सकता है कि यह (हमें) यह कैसे किया गया था?
अद्यतन: इस बारे में सोच रही थी, मैं काफी सुरक्षित होगा यह हो क्या सोचते हैं: कुकी userID और 128 बिट यादृच्छिक संख्या के होते हैं - यह आर
डाटाबेस पासवर्ड और अनुसंधान में शामिल है कहते हैं, प्रत्येक धोया और नमकीन (उदाहरण के लिए, पीएचपीएएस का उपयोग)। तब आर को दूसरा पासवर्ड माना जाता है। लाभ: यहां तक कि यदि पहला पासवर्ड खराब है (उदाहरण के लिए, "पासवर्ड 1"), आर एक बहुत अच्छा पासवर्ड है। डेटाबेस वास्तव में क्रैक नहीं किया जा सकता है, इसलिए यह चिंता नहीं होनी चाहिए। (मैं इसके बारे में अनावश्यक रूप से चिंतित था, मुझे लगता है।)
मैं ब्राउज़र को कुकी को लॉक करने के लिए एक तरह से कहा: हैशिंग से पहले, मैं उपयोगकर्ता एजेंट + कुछ स्क्रीन गुणों (डीपीआई, चौड़ाई, ऊंचाई, आदि) के साथ आर को कॉल करता हूं। बेशक, कुकी में कोई भी समेकित गुण संग्रहीत नहीं होते हैं, केवल आर है। इसलिए, यदि क्रैकर आर प्राप्त करता है, तो उसे उसी गुण वाले कंप्यूटर पर ब्राउजर से भागना होगा। सही नहीं है, लेकिन कुकी के डेटा को इतना कठिन बनाता है जो बहुत कठिन है। मुझे लगता है कि आईपी के साथ हैश के साथ, मेरे दृष्टिकोण कितने लोगों की तुलना में बेहतर है। आईपी ब्राउज़र संस्करणों या कंप्यूटर मॉनीटर की तुलना में अधिक बार बदलते हैं। –