क्या यह क्लाइंट के पास हैशिंग पासवर्ड के लायक है

Question

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

हालांकि, मेरे एक दोस्त ने मुझे बताया कि एक "स्पष्ट" पासवर्ड को नेटवर्क सॉफ़्टवेयर द्वारा सूँघा जा सकता है।

तो मेरा सवाल यह है कि क्या क्लाइंट की तरफ पासवर्ड हैश करना अच्छा है? क्या यह सर्वर की तरफ हैशिंग से बेहतर है?

Comments

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

— साइक्लोन

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

— sffc

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

— तीज 16

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

— MSalters

क्या यह सवाल security.stackexchange.com पर नहीं होना चाहिए?

— efr4k

Answer 1

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

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

सर्वर पर:

• यादृच्छिक के कुछ बिट उत्पन्न करते हैं
• क्लाइंट को ये बिट्स (स्पष्ट पाठ में) भेजें

ग्राहक पर:

• कुछ यादृच्छिक बिट्स उत्पन्न करें
• कॉन्टेक्ट पासवर्ड, सर्वर के रैंडम बिट्स और क्लाइंट रैंडम बिट्स
• उपरोक्त का हैश उत्पन्न करें
• रैंडम बिट्स (स्पष्ट पाठ में) और हैश सर्वर पर जमा करें

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

यह सब संपादित करें त्रुटि प्रवण और थकाऊ है और कुछ हद तक सही पाने के लिए कठिन है (पढ़ें: सुरक्षित)। यदि संभव हो तो, पहले से ही जानकार लोगों द्वारा लिखित प्रमाणीकरण प्रोटोकॉल कार्यान्वयन का उपयोग करने पर विचार करें (मेरे विपरीत! ऊपर केवल एक किताब की स्मृति से है जो मैंने कुछ समय पहले पढ़ी थी।) आप वास्तव में इसे आमतौर पर खुद नहीं लिखना चाहते हैं।

Comments

वह लॉगिन सिस्टम में हैशेड पासवर्ड के साथ कैसे प्रमाणित कर सकता है क्योंकि यह फिर से हैशेड होगा?

— जकारिया

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

— डर्क

@Dirk, चूंकि हमलावर दोनों तरीकों से सूँघ सकता है, इसलिए "यादृच्छिक बिट्स" को सूँघा जाएगा। फिर हमलावर मूल पासवर्ड को खोजने के लिए ऑफ़लाइन (रिक्वेस्ट: ब्रूट फोर्स) रिक्वेस्ट और रिस्पॉन्स पेयर का विश्लेषण कर सकता है।

— पचेरियर

हालाँकि, पासवर्ड या पासवर्ड के हैश जमा करने के उद्देश्य से, डिफि-हेलमैन जैसी एक असममित प्रक्रिया का उपयोग एक एन्क्रिप्शन कुंजी स्थापित करने के लिए किया जाता है जो दोनों पक्षों को एक स्नूपिंग पार्टी के बिना सूचना का आदान-प्रदान करने में सक्षम बनाता है जो इसे डिक्रिप्ट करने में सक्षम है। यह वही है जो एसएसएल करता है, और यही कारण है कि अधिकांश साइटों पर एचटीटीपीएस / एसएसएल पर अपना लॉगिन पेज है। SSL पहले से ही रिप्ले हमलों से बचाता है। मैं आपके अपने प्रोटोकॉल के निर्माण के बजाय SSL का लाभ उठाने की सलाह दूंगा। हालाँकि, मैं पासवर्ड क्लाइंट पक्ष को salting + hashing से सहमत हूं, लेकिन इन्हें एक स्थापित SSL कनेक्शन पर भेजें।

— एरोनल्स

बस स्पष्ट होने के लिए: यदि आप HTTPS का उपयोग नहीं कर रहे हैं, तो इससे कोई फर्क नहीं पड़ता कि आप ग्राहक पर क्या जावास्क्रिप्ट चलाते हैं; MITM क्लाइंट को हिट करने से पहले आपके पृष्ठ की सामग्री को संशोधित करने में सक्षम होगा। HTTPS एकमात्र समाधान है।

— एडियन

Answer 2

सबसे पहले, यह आपके आवेदन की सुरक्षा में सुधार नहीं करता है (यह मानते हुए कि यह एक वेबप है)।

एसएसएल का उपयोग करें (या वास्तव में टीएलएस, जिसे आमतौर पर एसएसएल कहा जाता है), इसका वास्तव में महंगा नहीं है (जिस समय का उपयोग आप इसके चारों ओर तरीके खोजने के लिए कर रहे हैं और इसे न्यूनतम मजदूरी के साथ गुणा करें, प्रमाण पत्र जीतकर लगभग हमेशा जीतता है)।

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

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

अस्वीकरण: उपयोगकर्ता इन चेतावनियों के माध्यम से दाईं ओर क्लिक करते हैं: "अविश्वासित कनेक्शन? क्या? मुझे बस बिल्ली के बच्चे की तस्वीरें चाहिए! अपवाद जोड़ें क्लिक करें पुष्टि करें क्लिक करें ! बिल्ली के बच्चे!"

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

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

(SHA256(SHA256(password)+salt))

(नमक को प्लेनटेक्स्ट के रूप में डेटाबेस में भी सेव करें))। और अपना पासवर्ड इस तरह भेजें:

RSA_With_Public_Key(SHA256(password))

और अपना पासवर्ड इस तरह जांचें:

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok

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

Comments

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

— Neyt

Answer 3

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

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

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

---

अगस्त 2014 को संपादित करें: Google वेबसाइटों को हर जगह HTTPS पर स्विच करने के लिए अधिक से अधिक जोर दे रहा है , क्योंकि संचार को सुरक्षित करना ही नेटवर्क स्निफिंग हमलों को रोकने का एकमात्र तरीका है। प्रेषित डेटा को बाधित करने के प्रयास केवल बाधा बनेंगे, रुकेंगे नहीं, एक समर्पित हमलावर, और डेवलपर्स को सुरक्षा की खतरनाक झूठी भावना दे सकते हैं।

Comments

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

— f1lt3r

Answer 4

वास्तव में मैं असहमत हूं कि इस मामले में ग्राहक पक्ष हैशिंग अधिक सुरक्षित है। मुझे लगता है कि यह कम सुरक्षित है।

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

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

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

वैसे, इस तरह के प्रश्न को शायद सुरक्षा स्टेक्सएक्सचेंज पर अधिक विशेषज्ञ प्रतिक्रियाएं मिलेंगी।

Comments

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

— जेम्स राइट

@JamesWright: बिंदु प्रत्येक उपयोग के लिए एक यादृच्छिक नमक भेज रहा है, जो लॉगिन संदेशों के अवैध पुन: उपयोग को रोकता है। (रिप्ले हमलों का एक रूप)। हर बार एक ही नमक भेजना वास्तव में व्यर्थ है।

— एमएसलटर्स

आपको जो करने की आवश्यकता है वह एक "गैर" ( en.wikipedia.org/wiki/Cryptographic_nonce ) का उपयोग करें । इस तरह, सर्वर नमक को भी नियंत्रित करता है और इसे सुरक्षित बनाता है। क्लाइंट साइड पर हैशिंग भी महत्वपूर्ण है ताकि इंजेक्ट किया गया जेएस कोड आसानी से इसे बाद में न पा सके। यहाँ और अधिक: stackoverflow.com/a/21716654/43615

— थॉमस टेम्पेलमैन

एक लॉगिन प्रमाणीकरण प्रक्रिया में नमक + नॉनस का उपयोग करने के लिए, यह उत्तर देखें: stackoverflow.com/a/24978909/43615

— थॉमस टेम्पेलमैन

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

— डैनियल मैटनर

Answer 5

ध्यान दें कि तीसरे पक्ष के दलों के खिलाफ पासवर्ड सुरक्षित रखने के लिए यह सब नहीं है।

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

इसलिए, हैशिंग / एन्क्रिप्टिंग क्लाइंट-साइड समझ में आता है।

Comments

माना! बहुत सारे लोग इस बिंदु को याद करते हैं। यदि मैं नमकीन हैशेड पासवर्ड के आपके पासवर्ड डेटाबेस को डाउनलोड करता हूं, और मैं हैश लुकअप डेटाबेस का उपयोग करके सिर्फ एक को क्रैक कर सकता हूं, तो संभावना है कि मैं उन सभी को क्रैक कर सकता हूं। एक बार जब मेरे पास 50k मूल पासवर्ड होते हैं, तो अब मेरे पास उन सेवाओं xपर उपयोगकर्ताओं की कुंजी है nजो केवल सर्वर पर एन्क्रिप्ट करते हैं। यदि क्लाइंट को छोड़ने से पहले प्रत्येक सेवा विशिष्ट रूप से पासवर्ड हैश करती है, तो क्रॉस-सर्विस पासवर्ड का बड़ा डेटाबेस बहुत छोटा हो जाता है। अपने AWS लॉगिन ट्रैफ़िक की जाँच करें, देखें कि वे क्या करते हैं। यह संभावना है मेरे प्रिय वॉटसन।

— f1lt3r

Answer 6

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

क्लाइंट पक्ष पर लिंक पासवर्ड एन्क्रिप्शन पर एक नज़र है

Answer 7

मैं हाल ही में इस पर बहुत काम कर रहा हूं, IRL क्लाइंट साइड हैश / सिमिट्रिक एन्क्रिप्शन के साथ दो मुद्दे हैं जो वास्तव में इस विचार को मारते हैं: 1. आपको सर्वर को वापस नमक मिलना है ... और एन्क्रिप्ट करना यह क्लाइंट पक्ष आपको एक पासवर्ड की आवश्यकता होगी ... जो उद्देश्य को हरा देता है। 2. आप अपने हैशिंग इम्प्लीमेंटेशन को उजागर करते हैं (न कि बहुत बड़ी डील के रूप में, ज्यादातर साइट्स 3 या 4 हैशिंग एलगोस में से एक का उपयोग करती हैं) जो हमले को आसान बनाता है (जैसा कि एन के बजाय केवल एक को आज़माने की ज़रूरत है)।

मैं अंततः OpenPGP.js या इसी तरह का उपयोग करके क्लाइंट पर असममित एन्क्रिप्शन में गया था ... यह क्लाइंट पर आयात की गई या क्लाइंट साइड जनरेट की गई कुंजी पर निर्भर करता है और सर्वर इसे सार्वजनिक कुंजी भेजता है। केवल क्लाइंट की सार्वजनिक कुंजी सर्वर पर वापस भेजी जा सकती है। यह एमआईएम के हमलों से बचाता है और डिवाइस के रूप में सुरक्षित है (मैं वर्तमान में स्थानीयस्टोर में डिफ़ॉल्ट रूप से क्लाइंट की निजी कुंजी संग्रहीत करता हूं, यह एक डेमो है)।

इसका मुख्य लाभ यह है कि मुझे कभी भी अपने सर्वर / डेटा स्टोर पर अनएन्क्रिप्टेड मेमोरी में / यहाँ तक कि उपयोगकर्ताओं का डेटा संग्रहीत नहीं करना पड़ता है (और मेरे सर्वर की निजी कुंजी शारीरिक रूप से अलग है)

इसका आधार लोगों को सुरक्षित रूप से संवाद करने का एक तरीका प्रदान करना था जहां HTTPS प्रतिबंधित था (उदाहरण के लिए, ईरान / N. कोरिया atc ...) और साथ ही सिर्फ एक मजेदार प्रयोग।

मैं यह सोचने के लिए पहले से FAR हूँ, http://www.mailvelope.com/ इसका उपयोग करता है

Answer 8

यदि कोई आपके कनेक्शन पर डेटा को अंदर और बाहर देख सकता है तो प्रमाणीकरण आपको नहीं बचाएगा। इसके बजाय मैं सुपर सीक्रेट सामान के लिए निम्न कार्य करूंगा।

सर्वर पर भेजे जाने से पहले क्लाइंट क्लाइंट की ओर से पासवर्ड भेजते हैं। (सर्वर हैश और ब्राउज़र से भेजे गए उस हैश के नमकीन मूल्य को संग्रहीत करता है)।

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

उपयोगकर्ता डेटा ब्राउज़र की तरफ भी एन्क्रिप्ट किया गया है।

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

इन दोनों विधियों के कुछ छोटे उदाहरण मेरे ब्लॉग http://glynrob.com/javascript/client-side-hashing-and-enc एन्क्रिप्शन/ पर हैं

Answer 9

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

तो यह सवाल वास्तव में है कि क्या हैशिंग सुरक्षा के लिए क्लाइंट की तरफ होनी चाहिए, लेकिन हम पासवर्ड को सुरक्षित रखने से पहले उसे अंततः हैशेड और सर्वर साइड की तुलना में कैसे सुरक्षित कर सकते हैं ताकि यह किसी तरह लॉग इन न हो।

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

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

एक कुकी के साथ गठबंधन करें जो सर्वर पर वापस जमा नहीं होता है और आप कुछ पर हो सकते हैं। पहले अनुरोध पर एक कुंजी के साथ ग्राहक को एक कुकी सबमिट करें, फिर सुनिश्चित करें कि कुकी लॉगिन सेवा में वापस नहीं आती है, इसलिए लॉग होने की बहुत कम संभावना है। सत्र स्टोर में कुंजी संग्रहीत करें, और उसके बाद लॉगिन समाप्त होने पर या सत्र समाप्त होने पर इसे ठीक से हटा दें ... इसके लिए आपको JWT लोगों के लिए राज्य की आवश्यकता होती है, लेकिन शायद इसके लिए केवल एक nosql सेवा का उपयोग करें।

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

Comments

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

— दान

Answer 10

इस पर विचार करो:-

क्लाइंट सर्वर से अनुरोध करता है कि "मेरे पास मान्य करने के लिए एक पासवर्ड है"।

सर्वर क्लाइंट को एक बार केवल रैंडम स्ट्रिंग भेजता है। R $

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

क्लाइंट सर्वर को स्ट्रिंग भेजता है और यदि पासवर्ड ठीक है, तो सर्वर उपयोगकर्ता को लॉग इन करता है।

क्या सर्वर को R $ का उपयोग करके एक और लॉगिन अनुरोध प्राप्त करना चाहिए, उपयोगकर्ता लॉग आउट हो गया है और खाता लंबित है।

जाहिर है कि अन्य सभी (सामान्य) सुरक्षा सावधानी बरती जाएगी।

Answer 11

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

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