security बाद में सादे पाठ पुनर्प्राप्ति के लिए मैं नैतिक रूप से उपयोगकर्ता पासवर्ड संग्रहण कैसे पहुंचूं?




password-encryption password-storage (21)

कल्पना कीजिए कि किसी ने निर्माण के लिए एक बड़ी इमारत शुरू की है - एक बार, मान लें - और निम्नलिखित बातचीत होती है:

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

क्या आर्किटेक्ट तब पूछता है कि बिना किसी आग के बाहर इस भवन को नैतिक रूप से कैसे बनाया जाए?

इमारत और इंजीनियरिंग उद्योग में, वार्तालाप इस तरह खत्म होने की संभावना है:

वास्तुकार: यह इमारत अग्नि निकास के बिना नहीं बनाई जा सकती है। आप किसी भी अन्य लाइसेंस प्राप्त पेशेवर के पास जा सकते हैं और वह आपको वही बात बताएगा। मैं अब जा रहा हूँ; जब आप सहयोग करने के लिए तैयार हों तो मुझे वापस कॉल करें।

कंप्यूटर प्रोग्रामिंग एक लाइसेंस प्राप्त पेशा नहीं हो सकता है, लेकिन लोग अक्सर आश्चर्य करते हैं कि हमारे पेशे को सिविल या मैकेनिकल इंजीनियर के समान सम्मान क्यों नहीं मिलता है - ठीक है, आगे नहीं देखो। उन व्यवसायों, जब कचरा (या सीधे खतरनाक) आवश्यकताओं को सौंप दिया, बस मना कर दिया जाएगा। वे जानते हैं कि यह कहना बहाना नहीं है, "ठीक है, मैंने अपनी पूरी कोशिश की, लेकिन उसने जोर दिया, और मुझे वह करना होगा जो वह कहता है।" वे उस बहाने के लिए अपना लाइसेंस खो सकते हैं।

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

पुनर्प्राप्ति योग्य रूप में पासवर्ड स्टोर करने के लिए कोई नैतिक या जिम्मेदार तरीका नहीं है। अवधि।

जैसे-जैसे मैं अधिक से अधिक वेबसाइटों और वेब अनुप्रयोगों को बनाना जारी रखता हूं, मुझे अक्सर उपयोगकर्ता के पासवर्ड को इस तरह से स्टोर करने के लिए कहा जाता है कि उपयोगकर्ता को कोई समस्या होने पर उन्हें पुनर्प्राप्त किया जा सकता है (या तो भूल गए पासवर्ड लिंक को ईमेल करने के लिए, उन्हें फोन, इत्यादि) जब मैं इस अभ्यास के खिलाफ कड़वाहट से लड़ सकता हूं और मैं अपने वास्तविक पासवर्ड को संग्रहीत किए बिना पासवर्ड रीसेट और प्रशासनिक सहायता संभव बनाने के लिए बहुत से 'अतिरिक्त' प्रोग्रामिंग करता हूं।

जब मैं इसे लड़ नहीं सकता (या जीत नहीं सकता) तो मैं हमेशा पासवर्ड को एन्कोड करता हूं ताकि कम से कम, डेटाबेस में सादे टेक्स्ट के रूप में संग्रहीत न हो - हालांकि मुझे पता है कि अगर मेरा डीबी हैक हो जाता है अपराधी के लिए पासवर्ड को क्रैक करने में ज्यादा कुछ नहीं लगेगा, जिससे मुझे असहज हो जाता है।

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

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

बाउंटी के लिए अतिरिक्त जानकारी

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

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

इस तरह के सिस्टम में इन जनसांख्यिकीय से दुर्घटना दर एप्लिकेशन को घुमा सकती है अगर उपयोगकर्ताओं को इस स्तर की पहुंच सहायता नहीं दी गई थी, तो कृपया इस तरह के एक सेटअप के साथ जवाब दें।

सभी को धन्यवाद

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

हमेशा के रूप में लगभग 5 उत्तरों थे कि मैं अलग-अलग कारणों से सही के रूप में चिह्नित करना चाहता हूं, लेकिन मुझे सबसे अच्छा चुनना पड़ा - बाकी सभी को +1 मिला। सबको धन्यवाद!

इसके अलावा, स्टैक समुदाय में हर किसी के लिए धन्यवाद जिन्होंने इस प्रश्न के लिए मतदान किया और / या इसे पसंदीदा के रूप में चिह्नित किया। मैं तारीफ के रूप में 100 वोट वोट मारता हूं और उम्मीद करता हूं कि इस चर्चा ने किसी और की चिंता के साथ किसी और की मदद की है।


बाद में सादा पाठ पुनर्प्राप्ति के लिए आप नैतिक रूप से पासवर्ड संग्रहीत नहीं कर सकते हैं। यह इतना सरल है। यहां तक ​​कि जॉन स्कीट बाद में सादा पाठ पुनर्प्राप्ति के लिए पासवर्ड को नैतिक रूप से संग्रहीत नहीं कर सकता है। यदि आपके उपयोगकर्ता किसी भी तरह या अन्य सादे पाठ में पासवर्ड पुनर्प्राप्त कर सकते हैं, तो संभावित रूप से भी एक हैकर जो आपके कोड में सुरक्षा भेद्यता पाता है। और यह सिर्फ एक उपयोगकर्ता का पासवर्ड समझौता नहीं किया जा रहा है, लेकिन उनमें से सभी।

यदि आपके ग्राहकों के साथ कोई समस्या है, तो उन्हें बताएं कि पासवर्ड को पुनर्प्राप्त करना कानून के खिलाफ है। यहां ब्रिटेन में किसी भी दर पर, डेटा प्रोटेक्शन एक्ट 1998 (विशेष रूप से, अनुसूची 1, भाग II, अनुच्छेद 9) के लिए डेटा नियंत्रकों को व्यक्तिगत डेटा को सुरक्षित रखने, अन्य चीजों के साथ, ध्यान में रखने के लिए उचित तकनीकी उपायों का उपयोग करने की आवश्यकता होती है, हानि जो डेटा के साथ समझौता किया गया हो सकता है - जो उपयोगकर्ताओं के बीच पासवर्ड साझा करने वाले उपयोगकर्ताओं के लिए काफी हो सकता है। अगर उन्हें अभी भी इस तथ्य को परेशान करने में परेशानी है कि यह एक समस्या है, तो उन्हें कुछ वास्तविक दुनिया के उदाहरणों के बारे में बताएं, जैसे कि यह एक

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

इस विषय पर मैंने लिखा कुछ ब्लॉग पोस्ट यहां दिए गए हैं:

अपडेट करें: अब हम उन कंपनियों के खिलाफ मुकदमे और मुकदमेबाजी शुरू कर रहे हैं जो अपने उपयोगकर्ताओं के पासवर्ड को सही तरीके से सुरक्षित करने में विफल रहते हैं। उदाहरण: लिंक्डइन $ 5 मिलियन क्लास एक्शन मुकदमा के साथ थप्पड़ मारा ; सोनी ने प्लेस्टेशन डेटा हैक पर £ 250,000 जुर्माना लगाया । अगर मुझे सही ढंग से याद किया जाता है, तो लिंक्डइन वास्तव में अपने उपयोगकर्ताओं के पासवर्ड एन्क्रिप्ट कर रहा था, लेकिन जिस एन्क्रिप्शन का उपयोग कर रहा था वह प्रभावी होने के लिए बहुत कमजोर था।


उपयोगकर्ता के सुरक्षा प्रश्न का उत्तर एन्क्रिप्शन कुंजी का एक हिस्सा बनाएं, और सुरक्षा प्रश्न के उत्तर को सादा पाठ के रूप में संग्रहीत न करें (इसके बजाय हैश)


बस इस रोचक और गर्म चर्चा में आया। हालांकि मुझे सबसे आश्चर्य हुआ कि, निम्नलिखित बुनियादी प्रश्नों पर कितना कम ध्यान दिया गया था:

  • Q1। सादे पाठ संग्रहीत पासवर्ड तक पहुंचने पर उपयोगकर्ता ने वास्तविक कारण क्या हैं? इतना मूल्य क्यों है?

जानकारी जो उपयोगकर्ता बड़े या युवा हैं, वास्तव में उस प्रश्न का उत्तर नहीं देते हैं। लेकिन ग्राहक की चिंता को उचित समझने के बिना व्यापार निर्णय कैसे बनाया जा सकता है?

अब यह क्यों मायने रखता है? क्योंकि यदि ग्राहकों के अनुरोध का वास्तविक कारण वह प्रणाली है जो उपयोग करने में दर्दनाक है, तो शायद सही कारण को संबोधित करने से वास्तविक समस्या हल हो जाएगी?

चूंकि मेरे पास यह जानकारी नहीं है और उन ग्राहकों से बात नहीं कर सकती, मैं केवल अनुमान लगा सकता हूं: यह उपयोगिता के बारे में है, ऊपर देखें।

मैंने देखा एक और सवाल पूछा:

  • Q2। यदि उपयोगकर्ता को पहले स्थान पर पासवर्ड याद नहीं है, तो पुराना पासवर्ड क्यों मायने रखता है?

और यहां संभव जवाब है। अगर आपके पास "मियामुआयू" नामक बिल्ली है और उसका नाम पासवर्ड के रूप में इस्तेमाल किया गया है लेकिन आप भूल गए हैं, तो क्या आप याद रखना पसंद करेंगे कि यह क्या था या "# zy * RW (ew") जैसे कुछ भेजा जा रहा था?

एक अन्य संभावित कारण यह है कि उपयोगकर्ता इसे नए पासवर्ड के साथ आने के लिए कड़ी मेहनत मानता है! तो पुराने पासवर्ड को वापस भेजकर उसे उस दर्दनाक काम से फिर से बचाने का भ्रम मिलता है।

मैं सिर्फ कारण समझने की कोशिश कर रहा हूं। लेकिन जो भी कारण है, यही वजह है कि जिस कारण को संबोधित किया जाना है।

उपयोगकर्ता के रूप में, मैं चीजों को सरल बनाना चाहता हूं! मैं कड़ी मेहनत नहीं करना चाहता!

अगर मैं समाचार पत्र पढ़ने के लिए एक समाचार साइट में लॉग इन करता हूं, तो मैं 1111 को पासवर्ड के रूप में टाइप करना चाहता हूं और !!!

मुझे पता है कि यह असुरक्षित है लेकिन मुझे अपने "खाते" तक पहुंचने के बारे में क्या ख्याल है? हाँ, वह भी खबर पढ़ सकता है!

क्या साइट मेरी "निजी" जानकारी संग्रहीत करती है? समाचार आज मैंने पढ़ा? तो यह साइट की समस्या है, मेरा नहीं! क्या साइट प्रमाणीकृत उपयोगकर्ता को निजी जानकारी दिखाती है? फिर इसे पहले स्थान पर न दिखाएं!

यह सिर्फ समस्या के लिए उपयोगकर्ता के दृष्टिकोण का प्रदर्शन करने के लिए है।

तो संक्षेप में, मुझे नहीं लगता कि यह सादा पाठ पासवर्ड (जिसे हम जानते हैं असंभव है) को "सुरक्षित रूप से" कैसे सुरक्षित करना है, बल्कि ग्राहकों को वास्तविक चिंता का समाधान करने की समस्या है।


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

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

जैसा कि आपने टिप्पणियों में उल्लेख किया है, अगर ईमेल से समझौता किया गया है तो यह काम नहीं करेगा, लेकिन यह पासवर्ड को रीसेट करने के बारे में @joachim की टिप्पणी को संबोधित नहीं करता है। आखिरकार, उन्हें पासवर्ड रीसेट का उपयोग करना होगा, लेकिन वे इसे एक सुविधाजनक समय पर, या एक प्रशासक या मित्र की सहायता से, आवश्यकतानुसार कर सकते हैं।

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


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


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


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


क्षमा करें, लेकिन जब तक आपके पास अपना पासवर्ड डीकोड करने का कोई तरीका है, तब तक यह सुरक्षित होने वाला कोई तरीका नहीं है। इसे कड़वाहट से लड़ो, और यदि आप हार जाते हैं, सीवाईए।


खोए गए / भूल गए पासवर्ड हैंडलिंग:

कभी भी पासवर्ड पुनर्प्राप्त करने में सक्षम नहीं होना चाहिए।

यदि उपयोगकर्ता अपने पासवर्ड भूल गए हैं, तो उन्हें कम से कम अपने उपयोगकर्ता नाम या ईमेल पते पता होना चाहिए। अनुरोध पर, उपयोगकर्ता तालिका में एक GUID उत्पन्न करें और उपयोगकर्ता के ईमेल पते पर पैरामीटर के रूप में ग्रिड युक्त एक लिंक वाला एक ईमेल भेजा गया है।

लिंक के पीछे वाला पृष्ठ सत्यापित करता है कि पैरामीटर guid वास्तव में मौजूद है (शायद कुछ टाइमआउट तर्क के साथ), और उपयोगकर्ता को एक नया पासवर्ड मांगता है।

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


सामान्य रूप से उपयोगकर्ता का पासवर्ड नमक-हैश हैश। उपयोगकर्ता को लॉग इन करते समय, उपयोगकर्ता के पासवर्ड (सैलिंग / हैशिंग के बाद) दोनों को अनुमति दें, लेकिन यह भी अनुमति दें कि उपयोगकर्ता ने सचमुच मिलान करने के लिए भी प्रवेश किया है।

यह उपयोगकर्ता को अपना गुप्त पासवर्ड दर्ज करने की अनुमति देता है, लेकिन उन्हें अपने पासवर्ड के नमकीन / शेड संस्करण में प्रवेश करने की अनुमति देता है, जो कि डेटाबेस से पढ़ता है।

असल में, नमकीन / हैश पासवर्ड भी एक "सादा पाठ" पासवर्ड बनाते हैं।


मुझे लगता है कि असली सवाल आपको खुद से पूछना चाहिए: 'मैं लोगों को विश्वास दिलाने में कैसे बेहतर हो सकता हूं?'


प्रश्न पर मैंने टिप्पणी की टिप्पणी के अनुसार:
लगभग हर किसी के द्वारा एक महत्वपूर्ण बिंदु बहुत चमक गया है ... मेरी प्रारंभिक प्रतिक्रिया @ माइकल ब्रूक्स के समान ही थी, जब तक मुझे एहसास नहीं हुआ, जैसे कि @stefanw, कि यहां मुद्दा तोड़ दिया गया है, लेकिन ये वे हैं जो वे हैं।
लेकिन फिर, यह मेरे लिए हुआ कि शायद यह मामला भी न हो! यहां लापता बिंदु, एप्लिकेशन की संपत्ति का अस्पष्ट मूल्य है। बस, एक कम मूल्य प्रणाली के लिए, एक पूरी तरह से सुरक्षित प्रमाणीकरण तंत्र, शामिल सभी प्रक्रियाओं के साथ, अधिक सुरक्षा होगी, और गलत सुरक्षा विकल्प।
जाहिर है, एक बैंक के लिए, "सर्वोत्तम प्रथाओं" जरूरी हैं, और नैतिक रूप से सीडब्ल्यूई -257 का उल्लंघन करने का कोई तरीका नहीं है। लेकिन कम मूल्य प्रणालियों के बारे में सोचना आसान है जहां यह सिर्फ इसके लायक नहीं है (लेकिन एक सरल पासवर्ड अभी भी आवश्यक है)।

यह याद रखना महत्वपूर्ण है कि सच्ची सुरक्षा विशेषज्ञता उचित ट्रेडऑफ ढूंढने में है, न कि "सर्वोत्तम व्यवहार" को कुचलने में, जो कोई भी ऑनलाइन पढ़ सकता है।

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

चूंकि एक जीवंत चर्चा चल रही है, वास्तव में अलग-अलग पोस्ट और पृथक टिप्पणी धागे में अलग-अलग जीवंत चर्चाएं, मैं कुछ स्पष्टीकरण जोड़ूंगा, और यहां कहीं और उठाए गए कुछ अच्छे बिंदुओं का जवाब दूंगा।

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

हालांकि, प्रश्न का क्रूक्स सिद्धांत के चारों ओर है , क्या ऐसी कोई स्थिति है जहां इसे रोकने के लिए आवश्यक नहीं हो सकता है , और यदि हां, तो स्थिति के लिए उचित तरीके से सही तरीके से ऐसा कैसे करें।

अब, जैसा कि @ थॉमस, @ ससुसेनेगर और कुछ अन्य लोगों ने बताया है, उस प्रश्न का उत्तर देने का एकमात्र उचित तरीका है, किसी भी दिए गए (या अनुमानित) स्थिति का पूर्ण जोखिम विश्लेषण करना, यह समझने के लिए कि हिस्सेदारी क्या है, कितना सुरक्षित है , और उस सुरक्षा को बर्दाश्त करने के लिए अन्य क्या कमीएं चल रही हैं।
नहीं, यह एक गूढ़ शब्द नहीं है, यह वास्तविक-वास्तविक सुरक्षा पेशेवर के लिए बुनियादी, सबसे महत्वपूर्ण टूल में से एक है। सर्वोत्तम बिंदु एक बिंदु तक (आमतौर पर अनुभवहीन और हैक्स के लिए दिशानिर्देश के रूप में) होते हैं, उस बिंदु के बाद विचारशील जोखिम विश्लेषण खत्म हो जाता है।

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

दरअसल, इस तरह हम हवाईअड्डा सुरक्षा की हास्यास्पदता प्राप्त करते हैं।

लेकिन इससे पहले कि हम इस स्थिति में उचित ट्रेडऑफ बनाने के बारे में बात करें, आइए हम स्पष्ट जोखिमों को देखें (स्पष्ट, क्योंकि हमारे पास इस स्थिति पर सभी पृष्ठभूमि की जानकारी नहीं है, हम सभी परिकल्पना कर रहे हैं - क्योंकि सवाल यह है कि क्या अनुमान है स्थिति हो सकती है ...)
आइए एक कम-VALUE प्रणाली मान लें, फिर भी यह इतना छोटा नहीं है कि यह सार्वजनिक पहुंच है - सिस्टम स्वामी आकस्मिक प्रतिरूपण को रोकना चाहता है, फिर भी "उच्च" सुरक्षा उपयोग की आसानी के रूप में सर्वोपरि नहीं है। (हां, यह जोखिम को स्वीकार करने का एक वैध व्यापार है कि किसी भी कुशल स्क्रिप्ट-किड्डी साइट को हैक कर सकता है ... रुको, एपीटी अब प्रचलित नहीं है ...?)
उदाहरण के लिए, मान लीजिए कि मैं एक बड़े परिवार की सभा के लिए एक साधारण साइट की व्यवस्था कर रहा हूं, जिससे हर किसी को इस बात पर ध्यान दिया जा सके कि हम इस वर्ष हमारी कैम्पिंग यात्रा पर जाना चाहते हैं। मैं कुछ अज्ञात हैकर, या यहां तक ​​कि चचेरे भाई फ्रेड निचोड़ने के बारे में चिंतित हूं, वेटनमानबाइकिलिकी झील पर वापस जाने के लिए बार-बार सुझावों में निचोड़ रहा हूं, क्योंकि मैं चाची एर्मा के बारे में सोचने में सक्षम नहीं हूं। अब, परमाणु भौतिक विज्ञानी होने वाली चाची एर्मा, पासवर्ड याद रखने में बहुत अच्छी नहीं है, या यहां तक ​​कि कंप्यूटर का उपयोग करने के साथ भी ... इसलिए मैं उसके लिए सभी घर्षण संभवतः हटाना चाहता हूं। दोबारा, मैं हैक के बारे में चिंतित नहीं हूं, मैं सिर्फ गलत लॉगिन की मूर्खतापूर्ण गलतियों को नहीं चाहता - मैं जानना चाहता हूं कि कौन आ रहा है, और वे क्या चाहते हैं।

वैसे भी।
तो यहां हमारे मुख्य जोखिम क्या हैं, अगर हम एक-तरफा हैश का उपयोग करने के बजाय पासवर्ड को एन्क्रिप्ट करते हैं?

  • उपयोगकर्ताओं का प्रतिरूपण करना? नहीं, मैंने पहले से ही उस जोखिम को स्वीकार कर लिया है, रोचक नहीं।
  • बुराई प्रशासक? खैर, हो सकता है ... लेकिन फिर, मुझे कोई परवाह नहीं है कि कोई अन्य उपयोगकर्ता, आंतरिक या नहीं का प्रतिरूपण कर सकता है ... और फिर भी एक दुर्भावनापूर्ण व्यवस्थापक आपका पासवर्ड प्राप्त करने वाला है चाहे कोई फर्क नहीं पड़ता - यदि आपका व्यवस्थापक खराब हो गया है, तो इसका खेल वैसे भी है।
  • एक और मुद्दा उठाया गया है, पहचान वास्तव में कई प्रणालियों के बीच साझा की जाती है। आह! यह एक बहुत ही रोचक जोखिम है, जिसके लिए एक नजदीक दिखने की आवश्यकता है।
    मुझे यह कहते हुए शुरू करना है कि यह वास्तविक पहचान नहीं है, बल्कि सबूत , या प्रमाणीकरण प्रमाण पत्र है। ठीक है, चूंकि एक साझा पासवर्ड प्रभावी रूप से मुझे किसी अन्य सिस्टम (कहने, मेरा बैंक खाता, या जीमेल) में प्रवेश करने की इजाजत देता है, यह प्रभावी रूप से एक ही पहचान है, इसलिए यह केवल अर्थशास्त्र है ... सिवाय इसके कि यह नहीं है । इस परिदृश्य में, प्रत्येक प्रणाली द्वारा पहचान को अलग-अलग प्रबंधित किया जाता है (हालांकि ओएथ जैसे तृतीय पक्ष आईडी सिस्टम हो सकते हैं - फिर भी, इस प्रणाली में पहचान से अलग है - इस पर और अधिक)।
    इस प्रकार, यहां जोखिम का मूल बिंदु यह है कि उपयोगकर्ता स्वेच्छा से अपने (समान) पासवर्ड को कई अलग-अलग प्रणालियों में इनपुट करेगा - और अब, मैं (व्यवस्थापक) या मेरी साइट के किसी भी अन्य हैकर के पास चाची एर्मा के पासवर्ड तक पहुंच होगी परमाणु मिसाइल साइट।

हममम।

क्या यहां कुछ भी आपको लगता है?

यह होना चाहिए।

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

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

एक और तरीका रखो, आपके पास अपने पासवर्ड नहीं हैं , इसलिए आप की तरह कार्य करने की कोशिश करना बंद करो।

तो, मेरे प्यारे सुरक्षा विशेषज्ञ, एक बूढ़े औरत के रूप में वेंडी के लिए पूछते थे, "जोखिम कहाँ है?"

ऊपर उठाए गए कुछ मुद्दों के जवाब में कुछ और मुद्दे:

  • सीडब्ल्यूई एक कानून, या विनियमन, या यहां तक ​​कि एक मानक नहीं है। यह सामान्य कमजोरियों का संग्रह है, यानि "सर्वोत्तम व्यवहार" के विपरीत।
  • साझा पहचान का मुद्दा एक वास्तविक समस्या है, लेकिन यहां नायसेर्स द्वारा गलत समझा गया (या गलत तरीके से प्रस्तुत किया गया)। यह पहचान को साझा करने का मुद्दा है (!), कम मूल्य वाले सिस्टम पर पासवर्ड क्रैक करने के बारे में नहीं। यदि आप कम मूल्य और उच्च-मूल्य प्रणाली के बीच पासवर्ड साझा कर रहे हैं, तो समस्या पहले से मौजूद है!
  • द्वारा, पिछला बिंदु वास्तव में OAuth का उपयोग करके और इन निम्न-मूल्य प्रणालियों और उच्च-मूल्य वाली बैंकिंग सिस्टम दोनों के लिए समान रूप से इंगित करेगा।
  • मुझे पता है कि यह सिर्फ एक उदाहरण था, लेकिन (दुख की बात है) एफबीआई सिस्टम वास्तव में सबसे सुरक्षित नहीं हैं। आपकी बिल्ली के ब्लॉग के सर्वर की तरह नहीं, लेकिन न ही वे कुछ अधिक सुरक्षित बैंकों को पार करते हैं।
  • एन्क्रिप्शन कुंजी का विभाजन ज्ञान, या दोहरी नियंत्रण, सेना में नहीं होता है, वास्तव में पीसीआई-डीएसएस को मूल रूप से सभी व्यापारियों से इसकी आवश्यकता होती है , इसलिए यह वास्तव में अब तक बहुत दूर नहीं है (यदि मूल्य इसे उचित ठहराता है)।
  • उन सभी को जो शिकायत कर रहे हैं कि इस तरह के प्रश्न डेवलपर पेशे को इतना बुरा लगते हैं: यह उन लोगों के उत्तर है, जो सुरक्षा पेशे को और भी खराब दिखते हैं। फिर, व्यवसाय केंद्रित जोखिम विश्लेषण आवश्यक है, अन्यथा आप स्वयं को बेकार बनाते हैं। गलत होने के अलावा।
  • मुझे लगता है कि यही कारण है कि एक नियमित डेवलपर लेने और उसके बारे में अधिक सुरक्षा जिम्मेदारियों को छोड़ने, प्रशिक्षण के बिना अलग-अलग सोचने के लिए और सही व्यापार की तलाश करने का अच्छा विचार नहीं है। आप में से कोई भी अपराध नहीं, मैं इसके लिए सब कुछ कर रहा हूं - लेकिन अधिक प्रशिक्षण क्रम में है।

वाह। कितनी लंबी पोस्ट ...
लेकिन अपने मूल प्रश्न का उत्तर देने के लिए, @ शेन:

  • ग्राहकों को चीजों को करने का उचित तरीका बताएं।
  • अगर वह अभी भी जोर देता है, तो कुछ और बताएं, जोर देकर बहस करें। यदि आवश्यक हो तो एक टैंट्रम फेंको।
  • उसे व्यापार जोखिम की व्याख्या करें। विवरण अच्छे हैं, आंकड़े बेहतर हैं, एक लाइव डेमो आमतौर पर सबसे अच्छा होता है।
  • अगर वह अभी भी जोर देकर कहते हैं, और वैध व्यावसायिक कारण प्रस्तुत करता है - यह आपके लिए एक निर्णय कॉल करने का समय है:
    क्या यह साइट कम-से-कम मूल्य है? क्या यह वास्तव में एक वैध व्यापार मामला है? क्या यह आपके लिए पर्याप्त है? क्या कोई अन्य जोखिम नहीं है जिसे आप विचार कर सकते हैं, जो वैध व्यावसायिक कारणों से अधिक होगा? (और निश्चित रूप से, ग्राहक एक दुर्भावनापूर्ण साइट नहीं है, लेकिन वह duh है)।
    यदि ऐसा है, तो बस आगे बढ़ें। आवश्यक प्रक्रिया को रखने के लिए प्रयास, घर्षण, और खोए गए उपयोग (इस अनुमानित स्थिति में) के लायक नहीं है। कोई अन्य निर्णय (फिर से, इस स्थिति में) एक बुरा व्यापार है।

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


इस भाग को पढ़ने के बाद:

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

इस तरह के सिस्टम में इन जनसांख्यिकीय से दुर्घटना दर एप्लिकेशन को घुमा सकती है अगर उपयोगकर्ताओं को इस स्तर की पहुंच सहायता नहीं दी गई थी, तो कृपया इस तरह के एक सेटअप के साथ जवाब दें।

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

फिर सिस्टम को यह पता लगाने के लिए स्थापित किया जाता है कि पासवर्ड रीसेट कब हुआ है और "क्या आप नया पासवर्ड रखना चाहते हैं या एक नया विकल्प चुनना चाहते हैं" प्रदर्शित करें।

अपने पुराने पासवर्ड को बताया जाने से कम पीसी-साक्षर के लिए यह कैसे बदतर है? और जब ग्राहक सेवा व्यक्ति शरारत तक पहुंच सकता है, तो उल्लंघन होने पर डेटाबेस स्वयं ही अधिक सुरक्षित होता है।

टिप्पणी करें कि मेरे सुझाव पर क्या बुरा है और मैं एक समाधान का सुझाव दूंगा जो वास्तव में वही करता है जो आप शुरू में चाहते थे।


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

मुझे लगता है कि यह वास्तव में विंडोज रिकवरी एजेंट के काम के समान ही है।

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

आधे रास्ते के बारे में कैसे?

पासवर्ड को एक मजबूत एन्क्रिप्शन के साथ स्टोर करें, और रीसेट सक्षम न करें।

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

आप इसे पासवर्ड रीसेट करने के लिए एक सुरक्षित तंत्र के रूप में "बेचना" कर सकते हैं।


माइकल ब्रूक्स सीडब्ल्यूई -257 के बारे में बल्कि मुखर हैं - तथ्य यह है कि आप जिस भी विधि का उपयोग करते हैं, आप (प्रशासक) अभी भी पासवर्ड पुनर्प्राप्त कर सकते हैं। तो इन विकल्पों के बारे में कैसे:

  1. किसी अन्य की सार्वजनिक कुंजी के साथ पासवर्ड एन्क्रिप्ट करें - कुछ बाहरी प्राधिकरण। इस तरह आप इसे व्यक्तिगत रूप से पुनर्निर्माण नहीं कर सकते हैं, और उपयोगकर्ता को उस बाहरी प्राधिकारी के पास जाना होगा और अपना पासवर्ड पुनर्प्राप्त करने के लिए कहेंगे।
  2. दूसरे पासफ्रेज़ से उत्पन्न कुंजी का उपयोग करके पासवर्ड एन्क्रिप्ट करें। इस एन्क्रिप्शन क्लाइंट-साइड को करें और कभी भी सर्वर को स्पष्ट रूप से प्रेषित न करें। फिर, पुनर्प्राप्त करने के लिए, अपने इनपुट से कुंजी को पुन: उत्पन्न करके फिर से डिक्रिप्शन क्लाइंट-साइड करें। माना जाता है कि, यह दृष्टिकोण मूल रूप से दूसरा पासवर्ड उपयोग कर रहा है, लेकिन आप उन्हें हमेशा लिखने के लिए कह सकते हैं, या पुराने सुरक्षा-प्रश्न दृष्टिकोण का उपयोग कर सकते हैं।

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


एक स्टैंडअलोन सर्वर पर एक डीबी खोलें और प्रत्येक वेब सर्वर के लिए एक एन्क्रिप्टेड रिमोट कनेक्शन दें जिसके लिए इस सुविधा की आवश्यकता है।
यह एक रिलेशनल डीबी होना आवश्यक नहीं है, यह टेबल और पंक्तियों के बजाय फ़ोल्डर और फ़ाइलों का उपयोग करके एफ़टीपी एक्सेस के साथ एक फाइल सिस्टम हो सकता है।
यदि आप कर सकते हैं तो वेब सर्वर केवल-लिखने की अनुमति दें।

साइट के डीबी में पासवर्ड के गैर-पुनर्प्राप्ति योग्य एन्क्रिप्शन को स्टोर करें (चलिए इसे "पास-ए" कहते हैं) सामान्य लोगों की तरह :)
प्रत्येक नए उपयोगकर्ता (या पासवर्ड परिवर्तन) पर रिमोट डीबी में पासवर्ड की एक सादा प्रति स्टोर करें। इस पासवर्ड के लिए एक समग्र कुंजी के रूप में सर्वर की आईडी, उपयोगकर्ता की आईडी और "पास-ए" का उपयोग करें। आप रात में बेहतर सोने के लिए पासवर्ड पर एक द्वि-दिशात्मक एन्क्रिप्शन का भी उपयोग कर सकते हैं।

अब किसी को पासवर्ड और इसके संदर्भ (साइट आईडी + उपयोगकर्ता आईडी + "पास-ए") प्राप्त करने के लिए, उसे यह करना है:

  1. एक ("पास-ए", उपयोगकर्ता आईडी) जोड़ी या जोड़े प्राप्त करने के लिए वेबसाइट के डीबी को हैक करें।
  2. कुछ कॉन्फ़िगरेशन फ़ाइल से वेबसाइट की आईडी प्राप्त करें
  3. रिमोट पासवर्ड डीबी में ढूंढें और हैक करें।

आप पासवर्ड पुनर्प्राप्ति सेवा की पहुंच को नियंत्रित कर सकते हैं (केवल एक सुरक्षित वेब सेवा के रूप में इसे बेनकाब करें, प्रति दिन केवल कुछ निश्चित पासवर्ड पुनर्प्राप्ति की अनुमति दें, इसे मैन्युअल रूप से करें, आदि), और यहां तक ​​कि इस "विशेष सुरक्षा व्यवस्था" के लिए अतिरिक्त शुल्क भी लें।
पासवर्ड पुनर्प्राप्ति डीबी सर्वर बहुत छिपा हुआ है क्योंकि यह कई कार्यों की सेवा नहीं करता है और बेहतर सुरक्षित हो सकता है (आप अनुमतियों, प्रक्रियाओं और सेवाओं को कसकर तैयार कर सकते हैं)।

सब कुछ, आप हैकर के लिए कड़ी मेहनत करते हैं। किसी भी सर्वर पर सुरक्षा उल्लंघन का मौका अभी भी वही है, लेकिन सार्थक डेटा (खाता और पासवर्ड का एक मैच) इकट्ठा करना मुश्किल होगा।


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

  • क्या उपयोगकर्ता को अपना पासवर्ड ईमेल करने से लाभ होता है? नहीं। उन्हें एक बार उपयोग पासवर्ड रीसेट लिंक से अधिक लाभ मिलता है, जो उम्मीद करता है कि वे उन्हें याद रखने वाले पासवर्ड का चयन करने की अनुमति देंगे
  • क्या उपयोगकर्ता को स्क्रीन पर अपना पासवर्ड प्रदर्शित करने से फायदा होता है? नहीं, ऊपर के समान कारण के लिए; उन्हें एक नया पासवर्ड चुनना चाहिए।
  • क्या उपयोगकर्ता को समर्थन व्यक्ति होने से लाभ होता है उपयोगकर्ता को पासवर्ड बोलते हैं? नहीं; दोबारा, यदि समर्थन व्यक्ति उपयोगकर्ता के अनुरोध को सही तरीके से प्रमाणित करने के लिए उपयोगकर्ता के अनुरोध को मानता है, तो यह एक नया पासवर्ड और इसे बदलने का अवसर देने के लिए उपयोगकर्ता के लाभ के लिए अधिक है। इसके अलावा, स्वचालित पासवर्ड रीसेट से फोन समर्थन अधिक महंगा है, इसलिए कंपनी को भी लाभ नहीं होता है।

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

इन प्रकार के अनुरोधों की लाइनों के बीच पढ़ना, आप देखेंगे कि आपके क्लाइंट शायद समझ में नहीं आते हैं या वास्तव में यह भी ध्यान रखते हैं कि पासवर्ड कैसे प्रबंधित किए जाते हैं। वे वास्तव में क्या चाहते हैं एक प्रमाणीकरण प्रणाली है जो उनके उपयोगकर्ताओं के लिए इतना कठिन नहीं है। तो उन्हें यह बताने के अलावा कि वे वास्तव में पुनर्प्राप्ति योग्य पासवर्ड क्यों नहीं चाहते हैं, आपको उन्हें प्रमाणीकरण प्रक्रिया को कम दर्दनाक बनाने के तरीकों की पेशकश करनी चाहिए, विशेष रूप से यदि आपको भारी सुरक्षा स्तर की आवश्यकता नहीं है, तो एक बैंक:

  • उपयोगकर्ता को उनके उपयोगकर्ता नाम के लिए अपने ईमेल पते का उपयोग करने दें। मैंने अनगिनत मामलों को देखा है जहां उपयोगकर्ता अपना उपयोगकर्ता नाम भूल जाता है, लेकिन कुछ अपने ईमेल पते को भूल जाते हैं।
  • ओपनआईडी ऑफ़र करें और उपयोगकर्ता भूलने की लागत के लिए तीसरे पक्ष का भुगतान करें।
  • पासवर्ड प्रतिबंधों पर आसानी से बंद करें। मुझे यकीन है कि हम सभी अविश्वसनीय रूप से नाराज हैं जब कुछ वेबसाइट आपकी पसंदीदा पासवर्ड की अनुमति नहीं देती है क्योंकि "आप विशेष पात्रों का उपयोग नहीं कर सकते" या "आपका पासवर्ड बहुत लंबा है" या "आपका पासवर्ड शुरू होना चाहिए" एक पत्र के साथ। " इसके अलावा, अगर उपयोग की आसानी पासवर्ड की ताकत से बड़ी चिंता है, तो आप छोटी पासवर्ड को अनुमति देकर या चरित्र वर्गों के मिश्रण की आवश्यकता नहीं होने से भी गैर-बेवकूफ आवश्यकताओं को ढीला कर सकते हैं। कमजोर प्रतिबंधों के साथ, उपयोगकर्ताओं को एक पासवर्ड का उपयोग करने की अधिक संभावना होगी जो वे नहीं भूलेंगे।
  • पासवर्ड समाप्त नहीं करें।
  • उपयोगकर्ता को पुराने पासवर्ड का पुन: उपयोग करने दें।
  • उपयोगकर्ता को अपना पासवर्ड रीसेट प्रश्न चुनने दें।

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

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

उपयोगकर्ता को अपना मूल पासवर्ड पुनर्प्राप्त करने की अनुमति देने का एकमात्र तरीका है, इसे उपयोगकर्ता की अपनी सार्वजनिक कुंजी से एन्क्रिप्ट करना है। केवल वह उपयोगकर्ता ही अपना पासवर्ड डिक्रिप्ट कर सकता है।

तो कदम होंगे:

  1. पासवर्ड को सेट किए बिना उपयोगकर्ता आपकी साइट पर (निश्चित रूप से एसएसएल पर) पंजीकरण करता है। उन्हें स्वचालित रूप से लॉग इन करें या अस्थायी पासवर्ड प्रदान करें।
  2. आप भावी पासवर्ड पुनर्प्राप्ति के लिए अपनी सार्वजनिक पीजीपी कुंजी स्टोर करने की पेशकश करते हैं।
  3. वे अपनी सार्वजनिक पीजीपी कुंजी अपलोड करते हैं।
  4. आप उन्हें एक नया पासवर्ड सेट करने के लिए कहते हैं।
  5. वे अपना पासवर्ड जमा करते हैं।
  6. आपके पास सबसे अच्छा पासवर्ड हैशिंग एल्गोरिदम उपलब्ध है (उदाहरण के लिए bcrypt) का उपयोग कर पासवर्ड हैश। अगली लॉग-इन को सत्यापित करते समय इसका उपयोग करें।
  7. आप पासवर्ड को सार्वजनिक कुंजी से एन्क्रिप्ट करते हैं, और अलग से स्टोर करते हैं।

यदि उपयोगकर्ता अपने पासवर्ड के लिए पूछता है, तो आप एन्क्रिप्टेड (धोया नहीं गया) पासवर्ड के साथ प्रतिक्रिया देते हैं। यदि उपयोगकर्ता भविष्य में अपना पासवर्ड पुनर्प्राप्त करने में सक्षम नहीं होना चाहता है (वे केवल इसे सेवा-जेनरेट किए गए एक को रीसेट करने में सक्षम होंगे), चरण 3 और 7 छोड़े जा सकते हैं।


यदि आप पुनर्प्राप्ति योग्य पासवर्ड स्टोर करने की आवश्यकता को अस्वीकार नहीं कर सकते हैं, तो इसके बारे में आपके प्रतिवाद के रूप में कैसे।

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

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





password-storage