पासवर्ड के उपयोग के खिलाफ "सुरक्षा" के रूप में प्रस्तुत करने से पहले क्लाइंट में लगभग कोई भी वेबपेजेस हैश पासवर्ड (और उन्हें फिर से हैशिंग) नहीं करता है?

Question

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

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

Comments

स्पष्ट में भेजा गया हैशेड पासवर्ड, सर्वर में सिर्फ हैश की तुलना करते हुए स्पष्ट रूप से भेजे गए पासवर्ड से बेहतर नहीं है, मध्य हमलों में आदमी इस तरह की "सुरक्षा" से प्यार करता है

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

— डीन हार्डिंग

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

— स्टीव ३४

@ स्टीव ३१४ मेरी बात कुछ भी है क्लाइंट पर डिफ़ॉल्ट रूप से समझौता किया जाता है। आप हैश और हैश और हैश कर सकते हैं, अगर यह क्लाइंट पर किया जा रहा है और सर्वर में आगे-पीछे किया जा रहा है, तो यह clearउस बिंदु पर सिर्फ गणितीय हस्तमैथुन है। मुझे एक ऐसी प्रणाली ठीक करनी थी जो मुझे विरासत में मिली थी, जिसे आपके और ओपी के वर्णन के सही तरीके से तैयार किया गया था, इसे लगातार वायरस्चर्स के साथ किशोरों द्वारा हैक किया जा रहा था। हमने इसे केवल तभी लॉक किया जब हमने REALएन्क्रिप्शन में रखा और एन्क्रिप्ट किया और सर्वर से और सभी पेलोड पर हस्ताक्षर किए, खाता हेरफेर बंद हो गया और उसके बाद फिर कभी नहीं हुआ।

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

— PC1oad1etter

Answer 1

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

Comments

यह अब तक का सबसे अच्छा जवाब है।

यह ब्लू-रे और डीवीडी एन्क्रिप्शन की तरह है। इसे अनलॉक करने के लिए कुंजी की भी आवश्यकता नहीं होती है। केवल "सुरक्षा" यह प्रदान किया गया था कि जब डीवीडी पहली बार बाहर आया था तो इसे कॉपी करने के लिए एक डिस्क खरीदने के लिए मूवी की पूरी कॉपी खरीदने की तुलना में अधिक लागत आई थी। बेशक अब आप एक डॉलर के लिए एक डीवीडी खरीद सकते हैं और इससे भी अधिक तथ्य यह है कि चाबियाँ अब सार्वजनिक ज्ञान हैं। वही ब्लू-रे के साथ हो रहा है

— माइकल ब्राउन

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

— एंडोमर

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

— LOAS

MITM हमलों को रोकने का सही तरीका एंड-टू-एंड एन्क्रिप्शन है। TLS (https) मौजूद है: इसका उपयोग करें। अपनी खुद की क्रिप्टो योजनाओं का आविष्कार न करें।

— रीन हेनरिच्स

Answer 2

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

यह वास्तव में आपकी रक्षा कैसे करता है? ऐसा लगता है कि आप जो करना चाहते हैं वह हैश पासवर्ड हैश की तरह है जो व्यर्थ है। क्योंकि हैशेड पासवर्ड तब पासवर्ड बन जाएगा।

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

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

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

Comments

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

— टेसेरेक्स

यदि यह ग्राहक के साथ समझौता किया जाता है, तो ग्राहक पर कोई भी नमक सादे दृश्य में है, यह एक अतार्किक प्रश्न है। यदि आप @ रामहाउंड के उत्तर को नहीं समझते हैं, तो आपको ऐसा कोड नहीं लिखना चाहिए जो सुरक्षित होना चाहिए, और शुरू से ही सुरक्षा और क्रिप्टोग्राफी पर पढ़ना शुरू करें।

जब आप मूल पोस्टर को उद्धृत कर रहे हों, तो कृपया पाठ को इस तरह से प्रारूपित करें (पाठ का चयन करें और संपादक के ठीक ऊपर उद्धरण चिह्न का उपयोग करें)

— मार्जन वेनमा

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

— x4u

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

Answer 3

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

सुरक्षित एसएसएल प्रमाणपत्रों के साथ-साथ प्रमाणीकरण के कुछ प्रकार से आता है। मैं चाहता हूं कि मेरे उपयोगकर्ता पासवर्ड की आपूर्ति करें ताकि मैं इससे हैश की गणना कर सकूं।

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

Comments

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

— PC1oad1etter

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

— लेविज

Answer 4

इससे समाधान सरल है। ग्राहक प्रमाणपत्र। मैं अपनी मशीन पर ग्राहक प्रमाणपत्र बनाता हूं। जब मैं एक वेबसाइट के साथ पंजीकरण करता हूं, तो हम अपने क्लाइंट प्रमाणपत्र और सर्वर के प्रमाण पत्र का उपयोग करके एक हैंडशेक करते हैं।

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

क्लाइंट प्रमाणपत्र को स्मार्ट कार्ड पर संग्रहीत किया जा सकता है (और एक मास्टर पासवर्ड का उपयोग करके एक सुरक्षित ऑनलाइन वॉल्ट में अपलोड किया जाता है)।

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

माइक्रोसॉफ्ट ने कार्डस्पेस के साथ विंडोज में ऐसा कुछ प्रदान करने की कोशिश की और बाद में इसे एक खुले मानक के रूप में प्रस्तुत किया। OAuth कुछ समान है, लेकिन यह एक मध्यवर्ती "जारी करने वाली पार्टी" पर निर्भर करता है। दूसरी ओर InfoCards स्वयं जारी किया जा सकता है। यह पासवर्ड की समस्या का वास्तविक समाधान है ... पासवर्ड को पूरी तरह से हटा देना।

OAuth हालांकि सही दिशा में एक कदम है।

Comments

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

— x4u

Answer 5

यहां अधिकांश उत्तर क्लाइंट-साइड पासवर्ड हैशिंग के बिंदु को पूरी तरह से याद करते हैं।

बिंदु उस सर्वर तक पहुँच सुरक्षित नहीं है जिसे आप लॉग इन कर रहे हैं, क्योंकि हैश को इंटरसेप्ट करना सादे टेक्स्ट पासवर्ड को इंटरसेप्ट करने से ज्यादा सुरक्षित नहीं है।

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

mitl हमलों से बचाने के लिए ssl बहुत अच्छा है, लेकिन यदि सर्वर पर लॉगिन एप्लिकेशन से छेड़छाड़ की जाती है, तो ssl आपके उपयोगकर्ताओं की सुरक्षा नहीं करेगा। यदि किसी ने दुर्भावनापूर्ण रूप से वेब सर्वर तक पहुंच प्राप्त की है, तो वे संभवतः सादे पाठ में पासवर्ड को इंटरसेप्ट करने में सक्षम होंगे क्योंकि ज्यादातर मामलों में पासवर्ड केवल सर्वर पर एक स्क्रिप्ट द्वारा हैश किए जाते हैं। फिर हमलावर समान उपयोगकर्ता नाम का उपयोग करके उन पासवर्ड को अन्य (आमतौर पर अधिक मूल्यवान) साइटों पर आज़मा सकता है।

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

Comments

स्वीकृत उत्तर आपकी बात को अच्छी तरह से साझा करता है। हालांकि "अधिकांश जवाब" नहीं देते हैं और क्योंकि आपका जवाब वास्तव में बहुत मूल्य नहीं जोड़ता है, इस प्रश्न को फिर से जीवित करने का कोई मतलब नहीं है।

— फ्रैंक

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

— crutchy

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

— जूल्स

@ जूल्स: इसीलिए संपादन मौजूद है।

— रॉबर्ट हार्वे

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

— zypA13510

Answer 6

यह निश्चित रूप से संभव है, और वास्तव में आपको वेबसाइट के लिए प्रतीक्षा करने की आवश्यकता नहीं है।

सुपरजेनपास पर एक नजर । यह एक बुकमार्कलेट है।

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

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

यह अत्यंत सुरक्षित नहीं है (बेस 64-एमडी 5), लेकिन यदि आप चाहें तो आप पूरी तरह से श -2 आधारित कार्यान्वयन वितरित करते हैं।

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

Comments

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

— आरोन्यूज़

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

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

— मैथ्यू एम।

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

— मैथ्यू एम।

@Jarrod: यह साइट के लिए एक सुरक्षा उपाय नहीं है , यह उपयोगकर्ता के लिए एक सुरक्षा उपाय है । यदि हर कोई इस तरह की योजना का उपयोग करता है, तो पासवर्ड का पुन: उपयोग एक गैर-मुद्दा होगा। MITM योजना क्लाइंट-हैशेड पासवर्ड का उपयोग करके उस साइट तक पहुँच प्राप्त कर सकती है , लेकिन केवल उस साइट पर। यहीं सुधार निहित है। आमतौर पर आप केवल एक पासवर्ड को क्रैक करके बहुत से खातों तक पहुंच प्राप्त करने में सक्षम होने की उम्मीद करेंगे , क्योंकि उस पासवर्ड का पुन: उपयोग होने की संभावना है; इस मामले में, फटा पासवर्ड व्यावहारिक रूप से केवल उस साइट या डेटाबेस के लिए मान्य होने की गारंटी है, जिसमें यह पाया गया था।

— हारून ने

Answer 7

मुझे X4u का उत्तर पसंद है, लेकिन मेरी राय में इसे ब्राउज़र / HTML विनिर्देश में एकीकृत किया जाना चाहिए - जैसे कि यह केवल आधा उत्तर है।

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

अधिकांश उपयोगकर्ता पासवर्ड का पुन: उपयोग करते हैं। गैर तकनीकी लोग क्योंकि वे किसी भी बेहतर नहीं जानते हैं। तकनीकी लोग क्योंकि एक बार जब आप 15 वें पासवर्ड को प्राप्त करते हैं या तो ज्यादातर लोग उन्हें याद करने का मौका नहीं देते हैं जब तक कि वे उन्हें लिख न दें (जिसे हम सभी जानते हैं कि यह भी एक बुरा विचार है)।

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

उपयोगकर्ता को यह जानना होगा कि उनका पासवर्ड सर्वर पर भेजे जाने के लिए भी उपलब्ध नहीं है - केवल हैश। वर्तमान में भी X4U के समाधान का उपयोग करते हुए उनके पास यह जानने का कोई तरीका नहीं है कि यह मामला है क्योंकि आप नहीं जानते कि क्या प्रौद्योगिकी उपयोग में है।

Comments

यह ब्राउज़र में डाइजेस्ट ऑथेंटिकेशन को एकीकृत करता है और आप अतिरिक्त जानकारी के साथ पासवर्ड हैशेड पाने के लिए http में उठाए गए और पीछे के कदमों को देखेंगे और सर्वर पर सत्यापित करेंगे।

— gbjbaanb

Answer 8

मुझे लगता है कि फ्रेमवर्क, सीएमएस, फ़ोरम सॉफ़्टवेयर, इत्यादि जैसी किसी चीज़ का निर्माण करते समय इसका उपयोग करना एक अच्छा तरीका है, जहाँ आप उन सर्वरों को नियंत्रित नहीं करते हैं जिन्हें यह स्थापित किया जा सकता है। यही है, हाँ, आपको लॉगइन और लॉग-इन गतिविधि के लिए हमेशा एसएसएल के उपयोग की सिफारिश करनी चाहिए, लेकिन आपके ढांचे / सेमी का उपयोग करने वाली कुछ साइटों में यह नहीं होगा, इसलिए वे अभी भी इससे लाभ उठा सकते हैं।

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

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

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

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