लॉगिन करते समय प्लेनटेक्स्ट पासवर्ड भेजने के लिए विकल्प
नोट: मैंने पहले ही पढ़ा है कि क्या HTTPS पर सादा-पाठ पासवर्ड भेजना ठीक है? और https सुरक्षा - पासवर्ड हैशेड सर्वर-साइड या क्लाइंट-साइड होना चाहिए? , लेकिन यहाँ यह एक विशिष्ट प्रतिस्थापन विधि के बारे में है (नीचे देखें)।
क्लाउडफेयर ब्लॉग पर एक नई प्रमाणीकरण पद्धति के बारे में एक लेख पढ़ने के बाद , मैंने POST"डेवलपर टूल्स> नेटवर्क" के साथ प्रमाणीकरण करते समय भेजे गए अनुरोधों को देखा । कई लोकप्रिय वेबसाइट (Reddit, HN, इत्यादि) अभी भी पासवर्ड को सादे संदर्भ में (SSL-सुरक्षित) POSTअनुरोध (नीचे स्क्रीनशॉट देखें) में भेजती हैं ।
क्या यह लॉगिन विधि अभी भी उद्योग मानक है?
HTTPS पर सादा पासवर्ड भेजने की तुलना में निम्नलिखित विकल्प अधिक सुरक्षित है?
साइनअप: क्लाइंट एक यादृच्छिक उत्पन्न करता है
salt, और(username, salt, hash(plain_password + salt))एकPOSTअनुरोध के माध्यम से ट्यूपल भेजता है । फिर प्लेनटेक्स्ट पासवर्ड कभी भी सर्वर तक नहीं पहुंचता है।बाद के लॉगिन: सर्वर
saltको किसी भी ग्राहक को वापस भेजना होगा जो किसी दिए गए लॉगिन के साथ प्रयास करता हैusername, ताकि ग्राहक उसी नमक के साथ हैश कर सके। तो इसका मतलब यह है कि सर्वरsaltकिसी दिए गए उपयोगकर्ता नाम के साथ लॉग इन करने की कोशिश कर रहा है।लाभ: सर्वर एक नमकीन + हैशेड पासवर्ड (जो मानक है) संग्रहीत करता है, लेकिन सर्वर ने कभी भी, कभी भी सादा पासवर्ड को एक बार भी नहीं देखा है (इसलिए यदि सर्वर से समझौता किया जाता है, तो जोखिम सीमित है)
टिप्पणियाँ:
के बाद से
H = hash(plain_password + salt)अब एक नया की तरह एक छोटा सा व्यवहार करती हैplaintext(के 2 जवाब देखने ? शून्य ज्ञान पासवर्ड सबूत: क्यों ग्राहक के पक्ष एक ZKP नहीं पर पासवर्ड hashing है ), तो Sever स्टोर कर सकते हैं(username, salt, server_salt, hash(H + server_salt))डेटाबेस में, बजाय(username, salt, H)।रिप्ले हमलों के लिए जोखिमों को कम करने के लिए, सर्वर प्रत्येक लॉगिन
nonceके साथ एक अद्वितीय भी भेज सकता हैsalt, जो एक लॉगिन प्रयास के बाद समाप्त हो जाता हैयहां मुख्य लक्ष्य यह है कि सर्वर में कभी भी प्लेनटेक्स्ट पासवर्ड या इसका एक साधारण हैश तक पहुंच नहीं है (जो कि पूरी साइट के लिए एक ही इंद्रधनुष तालिका के साथ उलट हो सकता है)। मैं जोखिम के साथ ठीक हूं कि एक हमलावर को प्रति उपयोगकर्ता एक इंद्रधनुष तालिका की गणना करनी है ।
उदाहरण का हमला मैं कम करना चाहूंगा: यदि सर्वर के पास प्लेनटेक्स्ट पासवर्ड का उपयोग होता है और यह समझौता किया जाता है (उदाहरण स्पेक्टर / मेल्टडाउन वल्न।) तो उपयोगकर्ता का प्लेनटेक्स्ट पासवर्ड (संभवतः अन्य वेबसाइटों पर पुन: उपयोग किया जा सकता है) चोरी हो सकता है, इससे पहले कि यह नमकीन हो। डेटाबेस में सहेजा और सहेजा गया।
जवाब
मैं यह नहीं देखता कि आपका प्रस्ताव मौजूदा क्लाइंट साइड हैशिंग दृष्टिकोण से बेहतर कैसे है, लेकिन मुझे यह दूसरों की तुलना में लागू करने के लिए अधिक जटिल लगता है। दुर्भाग्य से आप एक विशिष्ट जोखिम का वर्णन नहीं करते हैं जिसे आप एक्सेस करने की कोशिश कर रहे हैं इसलिए मैं आमतौर पर देखे जाने वाले विशिष्ट खतरों को मानता हूं।
मैन इन द मिडिल हमलावर
इस मामले में यह माना जाता है कि बीच के कुछ लोगों के पास यातायात की पहुंच है, उदाहरण के लिए क्योंकि इसने कॉर्पोरेट फ़ायरवॉल में कुछ विश्वसनीय ट्रैफ़िक टीएलएस अवरोधन से समझौता किया या सुपरफ़िश के मामले में एक विश्वसनीय सीए पर पकड़ बना ली ।
इस परिदृश्य में हमलावर Hको उसी तरह पहुंच मिलती है जैसा उन्होंने पहले किया था plain_password। चूँकि Hहमलावर के प्रमाणीकरण के लिए जो कुछ आवश्यक होता है वह इस प्रकार सफल होता है और आपका दृष्टिकोण यहाँ किसी अतिरिक्त सुरक्षा को नहीं जोड़ता है ।
कमजोर पासवर्ड और पासवर्ड को छुपाना
क्लाइंट साइड हैशिंग के लिए एक सामान्य तर्क सर्वर पर एक कमजोर या पुन: उपयोग किए गए पासवर्ड को उजागर नहीं करना है, बल्कि एक जटिल व्युत्पन्न पासवर्ड के साथ प्रमाणित करना है। आपका दृष्टिकोण hashing के साथ इस करता है plain_passwordयादृच्छिक उत्पन्न कुछ उपयोगकर्ता के साथ saltऔर फिर भेज Hऔर saltपासवर्ड सेटअप पर सर्वर से।
हालांकि यह काम करता है हर प्रमाणीकरण को अब एक अतिरिक्त चरण की आवश्यकता होती है : पहले इसे उपयोगकर्ता से उपयोगकर्ता के लिए पहले से उपयोग किए गए नमक को फिर से प्राप्त करने की आवश्यकता होती है और फिर यह saltहैश का उपयोग कर सकता है plain_password। यह अतिरिक्त कदम प्रमाणीकरण को और अधिक जटिल बनाता है क्योंकि पहले इसे सर्वर के साथ उपयोगकर्ता की जांच करने की आवश्यकता होती है और बाद में यह पासवर्ड की जांच कर सकता है। इसके अतिरिक्त, इसका एक तुच्छ कार्यान्वयन एक सूचना रिसाव को खोलता है क्योंकि यह जांचना संभव बनाता है कि क्या उपयोगकर्ता पहले प्रमाणीकरण में मौजूद है (नमक वापस लौटा या नहीं) आगे प्रमाणीकरण के बिना।
यह जानकारी लीक सर्वर द्वारा बंद की जा सकती है, जिसमें कोई नमक नहीं है, भले ही उपयोगकर्ता मौजूद हो या न हो। बेशक, यह सिर्फ एक यादृच्छिक नमक नहीं हो सकता है अन्यथा एक हमलावर सिर्फ एक ही उपयोगकर्ता को दो बार जांच सकता है और यह निष्कर्ष निकाल सकता है कि यदि लौटा हुआ नमक अलग था, तो उपयोगकर्ता मौजूद नहीं है। तो नमक वास्तव में गैर-मौजूदा उपयोगकर्ता के लिए तय किया जाना चाहिए, अर्थात उपयोगकर्ता नाम से लिया गया।
और यह आपके दृष्टिकोण को आसान बनाने का एक रास्ता भी दिखाता है : उपयोगकर्ता द्वारा एक यादृच्छिक नमक उत्पन्न करने के बजाय, इसे सर्वर पर संग्रहीत करना और बाद में इसे फिर से प्राप्त करना, कोई व्यक्ति केवल ग्राहक के नाम पर उपयोगकर्ता के नाम से नमक प्राप्त कर सकता है । एक साधारण salt=hash(username+domain)नमक जो डोमेन प्रति अद्वितीय है पैदा करते हैं और इस प्रकार दोनों करने के लिए पर्याप्त होगा saltऔर Hअलग भले ही usernameऔर plain_passwordअलग-अलग डोमेन पर पुन: उपयोग मिलता है। और आपके दृष्टिकोण के विपरीत सर्वर के लिए कोई अतिरिक्त यात्रा करने की आवश्यकता नहीं है, पहले उपयोगकर्ता के लिए पहले से उपयोग किए गए नमक को पुनः प्राप्त करने के लिए।
संक्षेप में: यह सरलीकृत दृष्टिकोण hash(plain_password+username+domain)मूल पासवर्ड के बजाय मूल रूप से भेज रहा है । डोमेन को यह सुनिश्चित करने के लिए जोड़ा जाता है कि भले ही usernameऔर plain_passwordकई साइटों पर पुन: उपयोग किया जाए, लेकिन व्युत्पन्न पासवर्ड का पुन: उपयोग नहीं किया जाता है।
यह वास्तव में समस्या है कि PAKE और SRP जैसे प्रोटोकॉल को हल करना है। PAKE / SRP के साथ, क्लाइंट और सर्वर क्लाइंट को ज्ञात पासवर्ड (और सर्वर को ज्ञात पासवर्ड की व्युत्पत्ति) के आधार पर परस्पर एक दूसरे को प्रमाणित करते हैं।
क्लाइंट सर्वर को दर्शाता है कि वह पासवर्ड जानता है, क्लाइंट को पासवर्ड (या पासवर्ड-समतुल्य डेटा) सर्वर को भेजे बिना। प्रक्रिया के अंत में, क्लाइंट और सर्वर एक साझा रहस्य साझा करते हैं।
सर्वर पासवर्ड (या पासवर्ड-समतुल्य डेटा) को संग्रहीत नहीं करता है और शब्दकोश हमलों के लिए अतिसंवेदनशील नहीं है। तार पर भेजे गए प्लेनटेक्स्ट को देखने में सक्षम एक ईव्सड्रोपर या मैन-इन-पासवर्ड पासवर्ड प्राप्त करने के लिए पर्याप्त जानकारी प्राप्त करने में सक्षम नहीं है। यह प्रभावी रूप से नकली प्रमाणपत्रों का उपयोग करते हुए मानव-में-मध्य हमलों को रोकता है, और 'फ़िशिंग' साइटों को उपयोगकर्ताओं के पासवर्ड चोरी करने से रोकता है।
1password SRP को कैसे लागू किया गया, इसके अच्छे तरीके से देखें https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/
स्टीफन उलरिच के जवाब के अलावा :
यदि लॉगिन के दौरान उपयोगकर्ता केवल हैश भेजता है, तो हमलावर को पासवर्ड जानने की आवश्यकता नहीं है। यह पासवर्ड डेटाबेस को चुराने के लिए पर्याप्त है। फिर लॉगिन अनुरोध के दौरान हमलावर डेटाबेस से सिर्फ हैश भेजेगा। यदि क्लाइंट पासवर्ड का उपयोग करता है और उसे हैश नहीं करता है, या क्लाइंट (हमलावर) को बस हैश भेजा जाएगा तो सर्वर अलग नहीं होगा।
OPAQUE पतों के बारे में लेख में यह समस्या भी है: पासवर्ड डेटाबेस को चुराने से हमलावर को मदद नहीं मिलेगी। एक को सादे उपयोगकर्ता पासवर्ड को जानना होगा।
यदि हमलावर ने आपके सर्वर से समझौता किया है, तो वे न केवल आपके सर्वर पर चल रहे सॉफ़्टवेयर के नियंत्रण में हैं, बल्कि क्लाइंट पर चलने वाले सॉफ़्टवेयर के भी हैं।
इससे कोई फर्क नहीं पड़ता कि आपने कितनी खूबसूरती से इंजीनियर प्रमाणीकरण योजना तैयार की है, ब्राउज़र को भेजने से पहले हमलावर इसे बदल सकता है।
अब आपके पास एक अंडा-चिकन समस्या है: आप एक पासवर्ड को सुरक्षित नहीं कर सकते हैं यदि हमलावर इसे इकट्ठा करने के तरीके को नियंत्रित करता है और आपके सर्वर पर भेजता है।
यदि आप एक डेटा ब्रीच के बारे में चिंतित हैं, तो आपका तरीका सुरक्षा के रूप में काम करेगा, लेकिन ऐसा एक उचित पासवर्ड हैशिंग सर्वर साइड होगा।
यदि आप MITM हमलों के बारे में चिंतित हैं, तो टीएलएस उन्हें हल करता है।
यदि आप टीएलएस पर MITM हमलों के बारे में चिंतित हैं, तो, जैसा कि मैं कहना चाहता हूं, उनके खिलाफ एक अच्छा बचाव हमेशा क्राव मागा मैनुअल से शुरू होता है। एक हमलावर जिसके पास लगातार टीएलएस को तोड़ने के लिए पर्याप्त संसाधन हैं, उसे किसी भी गैर-ठीक से और विशेष रूप से प्रशिक्षित व्यक्ति (हाँ, मैं अत्याचार, ब्लैकमेलिंग, अपहरण और हत्या) के बारे में जो कुछ भी चाहता हूं उसे प्राप्त करने में कोई समस्या नहीं है।
यदि आप एक खतरे वाले अभिनेता के बारे में चिंतित हैं जो केवल सर्वर द्वारा प्राप्त डेटा को पढ़ सकते हैं, तो आपका दृष्टिकोण (स्टीफन द्वारा सही किया गया) उनके खिलाफ काम करेगा। हालांकि, यह एक अजीब और दुर्लभ परिस्थिति है, जो अक्सर एक गलत तरीके से गलत सर्वर से उत्पन्न होती है और खराब विकासशील प्रथाओं (यानी जीईटी अनुरोधों पर क्रेडेंशियल्स भेजना और सार्वजनिक रूप से एक्सेस लॉग को संग्रहीत करना) है। इन गलतियों को ठीक करना आसान है, इससे निपटने के लिए एक प्रोटोकॉल का आविष्कार करना।
ध्यान दें कि आपके द्वारा उल्लिखित दोनों भेद्यताएं (वास्तव में यह सिर्फ एक है, जैसा कि मेल्टडाउन तकनीकी रूप से स्पेक्टर का एक प्रकार है) आखिरकार स्थानीय विशेषाधिकार वृद्धि में परिणाम होगा, जिससे हमलावर को आपके वेब सर्वर का पूर्ण नियंत्रण मिल जाएगा। फिर से यह बताना कि परिदृश्य कितना दुर्लभ है जहां एक हमलावर ने केवल आपके वेब सर्वर द्वारा प्राप्त डेटा तक ही पहुंच बनाई है।
इसलिए, कई बड़ी साइटें इसका उपयोग नहीं करती हैं, यह इसलिए है क्योंकि इसमें कुछ भी नहीं बल्कि विशिष्ट परिस्थितियों में बहुत अधिक गलतफहमी होती है। यह भी ध्यान देने योग्य है कि अगर कोई हमलावर यह पढ़ सकता है कि आपके सर्वर पर कौन सा डेटा परिवर्तित हो रहा है, तो आप गेम के हारने के पक्ष में हैं। मेरा ध्यान रखें, स्तरित सुरक्षा करना अच्छा है, लेकिन आपका मुख्य लक्ष्य यह नहीं है कि यह पहले स्थान पर हो। और उस पर ध्यान केंद्रित करने से आप नई योजनाओं का आविष्कार करने से भी बच जाएंगे।
वैसे भी, जैसा कि स्टीफ़न ने दिखाया था, आपकी प्रस्तावित योजना फिर से इस तरह के अजीब हमले के मॉडल पर काम कर सकती है। मैं अभी भी सिर्फ एक शब्द में एक शब्द में अभी भी दूरस्थ संभावना पर शासन करने के hash(hash(domain + username) + password)बजाय उपयोग करूंगा । जैसा कि mti2935 ने दिखाया है, SRP एक अधिक दिलचस्प विकल्प है। सर्टिफिकेट-आधारित प्रमाणीकरण (यानी ब्राउज़र द्वारा संभाला गया) एक और विकल्प है (जो मुझे मैन्युअल रूप से करने से बेहतर लगता है, संभवतः दागी, जेएस स्क्रिप्ट, जैसा कि आप टिप्पणियों में प्रस्तावित किया गया है)।hash(domain + username + password)domain + username + password