क्या सर्वर साइड में भेजने से पहले मेरे पास पासवर्ड होना चाहिए?

Question

मैंने देखा कि अधिकांश साइटें HTTPS के सादा पाठ के रूप में पासवर्ड सर्वर पर भेजती हैं। क्या कोई फायदा है अगर इसके बजाय मैंने सर्वर को पासवर्ड का हैश भेजा है? क्या यह अधिक सुरक्षित होगा?

Comments

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

— मेरलिन मॉर्गन-ग्राहम

@ मर्लिन "हैश टकराव" अच्छा बिंदु!

— जादर डायस

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

— जेजे

@JJ "मिक्सिंग एल्गोरिदम बिल्कुल टकराव की संभावना नहीं बढ़ाता है।" मैं वास्तव में उस कथन का प्रमाण देखना चाहूंगा। मुझे आपको रोकना चाहिए: यह गलत है , सामान्य तौर पर यह टकराव को बढ़ाता है। मैं आसानी से एक हैशिंग फ़ंक्शन का निर्माण कर सकता हूं जैसे कि एच (एक्स) स्थिर नहीं है, लेकिन सभी एक्स के लिए एच (एच (एक्स)) = 0 है। तो आपको हैशिंग एल्गोरिदम के सटीक सेट का उल्लेख करना होगा और आप उन्हें कैसे मिलाएँगे। फिर आपको अपना कथन सिद्ध करना होगा। AFAIK भी कई SHA के लिए (नमक के साथ) यह एक खुली समस्या है। और मूल रूप से हम मानते हैं कि यह सच है। क्रिप्टोग्राफी कठिन है।

— अजीब

Answer 1

यह एक पुराना प्रश्न है, लेकिन मुझे इस महत्वपूर्ण मामले पर अपनी राय देने की आवश्यकता महसूस हुई। यहाँ बहुत गलत जानकारी है

ओपी ने कभी भी एचटीटीपीएस पर स्पष्ट रूप से पासवर्ड भेजने का उल्लेख नहीं किया - केवल एचटीटीपीएस, कई लोग किसी कारण से एचटीटीपी पर पासवर्ड भेजने के सवाल का जवाब दे रहे हैं। ने कहा कि:

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

यहां जवाब देने वाले लोग सोचते हैं कि HTTPS एक चांदी की गोली है, जो यह नहीं है। यह निश्चित रूप से हालांकि बहुत मदद करता है, और किसी भी प्रमाणित सत्र में उपयोग किया जाना चाहिए।

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

इसलिए हमारे पास एक कुंजी है। अब हमें क्लाइंट डिवाइस पर पासवर्ड के किसी भी निशान को साफ करने की आवश्यकता है।

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

इसके आस-पास जाने के लिए, हमारे पास एक बार नॉन-ऑफ के साथ कुंजी हैश है। अपने सिस्टम की कुंजी प्रस्तुत करने के लिए यह नॉनस अद्वितीय है - यहां तक ​​कि एक ही सत्र के दौरान एक ही क्रेडेंशियल के लिए यदि आपको कई बार भेजने की आवश्यकता है। प्रमाणीकरण कुंजी को पुनर्प्राप्त करने और अनुरोध को प्रमाणित करने के लिए अपने स्वयं के सिस्टम में आने के बाद आप इस नॉन को रिवर्स कर सकते हैं।

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

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

टी एल; डॉ:

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

Comments

मैंने सिर्फ gmail और facebook की जाँच की - क्रोम डेवलपर टूल ने मुझे दोनों POST एक urlencoded संदेश के साथ बताए जिसमें मेरा उपयोगकर्ता नाम और पासवर्ड सादा (अनसाल्टेड) ​​पाठ में था। कैसे / क्यों बड़े खिलाड़ी क्लाइंट पर नॉन साल्टिंग का इस्तेमाल नहीं कर रहे हैं?

— ग्रीमवेल

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

— रजत

यदि आप HTTPS पर भरोसा नहीं करते हैं तो हर एक प्रयास व्यर्थ है! आपका कोड खुद को तार के माध्यम से भेज दिया गया है और एक हमलावर पारगमन में पासवर्ड सुरक्षित करने के आपके सभी प्रयासों को संशोधित / बदल सकता है

— साजिद कल्ला

एक मिटम जो एक सर्टिफिकेट को दोबारा लिख ​​सकता है वह नॉन को फिर से लिख सकता है। या फिर साजिद ने क्या कहा।

— लेवेज

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

— क्रश करें

Answer 2

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

Comments

यह एक समस्या नहीं होनी चाहिए। यदि क्लाइंट प्रॉक्सी का उपयोग कर रहा है, तो सभी प्रॉक्सी देखेंगे HTTPS एन्क्रिप्टेड डेटा। यदि आप एक आदमी के मध्य हमले के बारे में बात कर रहे हैं, तो ठीक से कॉन्फ़िगर किया गया प्रमाण पत्र इसे रोकना चाहिए।

— कीर्स्टन अर्नाल्ड

@ जेडर: डेटा के साथ फ़िडलिंग की कोई भी राशि MITM हमले को नहीं रोक सकती, क्योंकि यह जो भी आता है उसे बस रिले कर सकती है। इससे कोई फर्क नहीं पड़ता कि आप पासवर्ड या हैश ट्रांसमिट कर रहे हैं या नहीं। वह बिल्कुल अलग मामला है।

— डेविड थॉर्नले

SSL (HTTPS = HTTP ओवर एसएसएल) का उद्देश्य MITM को विफल करना है।

— yfeldblum

@ कर्नल - MINTM - http पर पुनर्निर्देशन के बारे में क्या? क्या ज्यादातर लोग नोटिस करेंगे? sslstrip - securityfocus.com/brief/910

— नैट ग

@ जैदर डायस एक समस्या को रोकने की कोशिश कर रहा है जो मौजूद नहीं है। HTTPS इस समस्या को रोकता है, क्लाइंट साइड हैश में सुरक्षा की कोई राशि नहीं है। क्लाइंट पर कभी भरोसा नहीं किया जा सकता।

— किश्ती

Answer 3

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

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

Https का उपयोग नहीं करना OWASP Top 10 का उल्लंघन है: A9- अपर्याप्त परिवहन परत संरक्षण

संपादित करें: यदि आपके कार्यान्वयन में आप गणना करते हैं sha256(client_salt+plain_text_password)और फिर सर्वर की तरफ एक और हैश की गणना करते हैं sha256(server_salt+client_hash)तो यह एक गंभीर भेद्यता नहीं है। हालांकि, यह अभी भी उत्सुकता से अनुरोध को दोहरा रहा है और फिर से दोहरा रहा है। इस प्रकार यह अभी भी WASP A9 का स्पष्ट उल्लंघन है। हालाँकि, यह अभी भी एक संदेश को सुरक्षा परत के रूप में पचा रहा है।

निकटतम चीज़ जो मैंने https के लिए क्लाइंट-साइड रिप्लेसमेंट में देखी है , जावास्क्रिप्ट में प्रमुख एक्सचेंज में एक डिफी-हेलमैन है । हालांकि, यह सक्रिय MITM हमलों को रोकता है और इस प्रकार तकनीकीता OWASP A9 का उल्लंघन है। कोड के लेखक सहमत हैं कि यह HTTPS के लिए एक पूर्ण प्रतिस्थापन नहीं है, हालांकि यह क्लाइंट-साइड हैशिंग सिस्टम की तुलना में बेहतर और कुछ भी नहीं है।

Comments

वास्तव में मैं इसे फिर से सर्वर में रखूँगा, इसलिए कृपया इस परिदृश्य पर विचार करते हुए अपने उत्तर को संपादित करें।

— Jader Dias

@Rook diffi-hellman कुंजी विनिमय का उपयोग कर रहा है साथ में https "बेकार" समाधान है? (मेरा मतलब है कि हम केवल https का उपयोग कर सकते हैं और हेल्मान को अलग नहीं कर सकते हैं सुरक्षा इमो को बढ़ाएं नहीं)

— मिशेल

@Michel Kogan एक डीएच प्रमुख एक्सचेंज अन्य उपकरणों के साथ HTTPs में इस्तेमाल किया जा सकता है।

— किश्ती

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

— लेवेंटे PANczél

Answer 4

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

Comments

यह कुल बकवास लगता है ... एक हैश पासवर्ड से कम सुरक्षित कैसे है?

— लेवेंटे PANczél

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

— हैलो वर्ल्ड

अपडेट: डाइजेस्ट एक्सेस प्रमाणीकरण और भी अधिक परिष्कृत है: en.wikipedia.org/wiki/Digest_access_authentication

— हैलो वर्ल्ड

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

— पॉल केस्टर

पॉल ने जो कहा, उसे जोड़ने के लिए: इस तरह के हमले को "रीप्ले अटैक" कहा जाता है, अगर कोई इसे कहीं और पढ़ना चाहता है।

Answer 5

प्लेनटेक्स्ट में पासवर्ड कभी नहीं (एचटीटीपीएस का उपयोग करते समय भी नहीं) ग्राहक को छोड़ देता है। क्लाइंट को छोड़ने से पहले इसे अपरिवर्तनीय रूप से प्रसारित किया जाना चाहिए क्योंकि वास्तविक पासवर्ड जानने के लिए सर्वर की कोई आवश्यकता नहीं है।

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

इस मुद्दे को हल करने के लिए आप बेशक हैश को सर्वर प्राप्त कर सकते हैं और इसे एक दिन कॉल कर सकते हैं।

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

Answer 6

HTTP डाइजेस्ट का प्रयोग करें - यह HTTP पर भी पासवर्ड सुरक्षित रखता है (लेकिन सबसे अच्छा उपयोग http पर होगा http: // पर पचता है)

विकिपीडिया:

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

लिंक: http://en.wikipedia.org/wiki/Digest_access_authentication

यदि आप "वास्तविक जीवन" का उपयोग देखना चाहते हैं, तो आप phpMyID को देख सकते हैं - php ओपनिड प्रदाता जो http: // प्रमाणीकरण पर आधारित है http://siege.org/phpmyid.php

.. या आप http://pp.net/manual/en/features.http-auth.php पर php के सामान्य नमूनों से शुरुआत कर सकते हैं

Http डाइजेस्ट rfc: http://www.faqs.org/rfcs/rfc2617

मेरे परीक्षणों से सभी आधुनिक ब्राउज़र इसका समर्थन करते हैं ...

Comments

HTTP डाइजेस्ट इस प्रश्न में मेरा क्या अर्थ है, लेकिन अगर हम HTTPS डाइजेस्ट (एसएसएल + एचटीटीपी डाइजेस्ट) का उपयोग करते हैं तो हमें कोई फायदा नहीं होगा?

— जदर डायस

एक मुख्य अंतर यह होगा कि सब कुछ भेजा / प्राप्त एन्क्रिप्टेड है - http हेडर भेजते हैं और प्राप्त करते हैं और HTML उत्तर। किसी व्यक्ति के बीच-बीच-हमले में ssl को बेतरतीब ढंग से "हैक" करने की कोशिश करने के लिए, HTTP डाइजेस्ट उसे एक और आसान लक्ष्य खोजने के लिए एक अतिरिक्त मकसद होगा, या यदि वह सभी कैप्चर किए गए ट्रैफ़िक को लॉग कर रहा है तो आपके पासवर्ड अभी भी सुरक्षित हैं। मुझे यह सवाल गलत लगा, अंग्रेजी मेरी पहली भाषा नहीं है।

— वल्द b।

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

— vlad b। 20

Answer 7

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

हालाँकि, HTTPS पर भेजे गए एक बुनियादी क्लाइंट-साइड पासवर्ड ऑबफसिकेशन (हैश नहीं) का कुछ मूल्य है। यदि मैं गलत नहीं हूँ तो यह तकनीक वास्तव में कुछ बैंकों द्वारा उपयोग की जाती है। इस तकनीक का उद्देश्य पासवर्ड को तार पर सूँघने से बचाना नहीं है। इसके बजाय, यह पासवर्ड जासूसी करने से रोकने के लिए जासूसी करने वाले औज़ारों और ब्राउज़र प्लग-इन के लिए उपयोग करने योग्य है जो कि हर HTTPS GET / POST अनुरोध को हड़प लेता है। मैंने एक दुर्भावनापूर्ण वेबसाइट से कैप्चर की गई एक लॉग फ़ाइल देखी है जो उपयोगकर्ता सत्रों से कैप्चर किए गए यादृच्छिक GET / POST लेनदेन की 400MB थी। आप कल्पना कर सकते हैं कि सिर्फ एचटीटीपीएस का इस्तेमाल करने वाली वेबसाइटें लॉग-इन में क्लियर-टेक्स्ट पासवर्ड के साथ दिखेंगी, लेकिन बहुत बेसिक ऑब्सफिकेशन (ROT13) वाली वेबसाइट्स ऐसे पासवर्ड के साथ दिखेंगी, जो तुरंत इस्तेमाल नहीं होते।

Comments

"लेकिन बहुत ही बेसिक ऑब्सफेकेशन (ROT13) वाली वेबसाइटें पासवर्ड के साथ दिखेंगी जो तुरंत इस्तेमाल नहीं होती हैं" - यह मूल कथन का खंडन करता है। कुंजी यह है कि वे उपयोग की IMMEDIATELY नहीं हैं, लेकिन यह वास्तव में व्यर्थ है। पासवर्ड और इसके ROT13 बराबर हैं। लेकिन अगर आप पासवर्ड को SHA2 करते हैं, तो यह लॉग्स में मौजूद नहीं होगा (इसलिए आपके प्रवेशकों को उपयोगकर्ताओं को अन्य प्रणालियों के संभावित पासवर्ड के बारे में नहीं पता होगा), और आप लगभग हर गोपनीयता अधिनियम के उल्लंघन में NO LONGER हैं।

— लेवेंटे PANczél

Answer 8

यदि आप किसी https सर्वर से जुड़े हैं, तो सर्वर और ब्राउज़र के बीच डेटा स्ट्रीम एन्क्रिप्ट किया जाना चाहिए। डेटा भेजे जाने से पहले और प्राप्त होने के बाद केवल सादा पाठ है। विकिपीडिया लेख

Comments

क्या प्रॉक्सी इस डेटा को बाधित नहीं करते हैं?

— जादेर डायस

जैसा कि मैं समझता हूं कि वे ऐसा करते हैं, लेकिन प्रॉक्सी एन्क्रिप्शन / डिक्रिप्शन के लिए ज़िम्मेदार नहीं है और जब तक कि यह एक भद्दा प्रॉक्सी नहीं है, केवल डेटा को पास करता है। एन्क्रिप्शन प्रकार और शक्ति इस बात पर निर्भर करती है कि सर्वर और क्लाइंट दोनों क्या समर्थन कर सकते हैं।

— याकूब

यहां तक ​​कि अगर प्रॉक्सी अस्पष्ट है, तो यह डेटा को डिक्रिप्ट नहीं कर सकता है क्योंकि यह सर्वर की सार्वजनिक कुंजी का उपयोग करके एन्क्रिप्ट किया गया है। एक प्रॉक्सी जिस तरह से डेटा को डिक्रिप्ट कर सकता है वह है सर्वर के सर्टिफिकेट को एक अलग कुंजी से

— खराब करना

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

— पतरस ने

Answer 9

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

दोनों करो

दोनों करें क्योंकि:

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

2. यदि कोई व्यक्ति, किसी तरह डेटाबेस से पासवर्ड पढ़ने में सक्षम था (ऐसा होता है, तो SQL इंजेक्शन लगता है), वे अभी भी मेरे एपीआई के माध्यम से उपयोगकर्ताओं को प्रतिरूपित विशेषाधिकार प्राप्त कार्यों को निष्पादित करने में सक्षम नहीं होंगे। यह हैश विषमता के कारण है; यहां तक ​​कि अगर वे आपके DB में संग्रहीत हैश को जानते हैं, तो वे इसे बनाने के लिए उपयोग की जाने वाली मूल कुंजी को नहीं जान पाएंगे और यह वही है जो आपके सामान्य मिडलवेयर को प्रमाणित करने के लिए उपयोग करता है। यही कारण है कि आपको हमेशा अपने हैश स्टोरेज को नमक करना चाहिए।

यदि वे अपने डेटाबेस से क्या चाहते हैं, यह पढ़ने के लिए स्वतंत्र लगाम था, तो वे बहुत अधिक नुकसान कर सकते थे।

मैं यहाँ केवल इस बात पर ज़ोर देना चाहता हूँ कि यदि आप अपने ग्राहकों से विदा होने से पहले हैश का फैसला करते हैं, तो यह पर्याप्त नहीं है - बैकएंड हैशिंग, ईमो, बहुत अधिक महत्वपूर्ण है और यही कारण है कि: यदि कोई आपके ट्रैफ़िक को रोक रहा है क्लाइंट, फिर वे passwordफ़ील्ड की सामग्री देखेंगे । चाहे यह एक हैश, या सादा पाठ हो, इससे कोई फर्क नहीं पड़ता - वे इसे अधिकृत ग्राहक को लागू करने के लिए शब्दशः की प्रतिलिपि बना सकते हैं। (जब तक आप उन चरणों का पालन नहीं करते हैं जो @ user3299591 रूपरेखाएँ हैं, और मैं आपको सलाह देता हूं)। दूसरी ओर, डीबी कॉलम को हाशिल करना, एक आवश्यकता है और इसे लागू करना मुश्किल नहीं है।

Answer 10

क्या SSL / TLS नॉन की जगह नहीं ले रहा है? मुझे इसका जोड़ा मूल्य दिखाई नहीं देता क्योंकि SSL / TLS भी रिप्ले हमलों से बचाता है।

संदर्भ। https://en.wikipedia.org/wiki/Cryptographic_nonce

Comments

कृपया जाँच करें stackoverflow.com/questions/3391242/…

— अहमद होसानी

Answer 11

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

HTTPS का उपयोग करके, आप किसी हैकर को किसी एकल स्रोत से पासवर्ड प्राप्त करने से रोकते हैं, क्योंकि HTTPS दो चैनलों का उपयोग करता है, दोनों एन्क्रिप्टेड।

Comments

वास्तव में मैं इसे फिर से सर्वर में रखूँगा, और मैं वैसे भी HTTPS का उपयोग करूँगा, इसलिए कृपया इस परिदृश्य पर विचार करते हुए अपने उत्तर को संपादित करें।

— जादेर डायस २०

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

— पतरस ने

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

— जेमिलोइ

Answer 12

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

इसे दो प्रकार के हमलों के परिप्रेक्ष्य से देखा जा सकता है- एक नेटवर्क ट्रैफिक तक पहुंच के साथ, और दूसरा डेटाबेस तक पहुंच के साथ।

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

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

ध्यान में रखने की अवधारणा:

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