HTTP पर सुरक्षित रूप से पासवर्ड कैसे भेजें?

Question

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

तो सवाल यह है कि तीसरे पक्ष के खिलाफ उपयोगकर्ता और उसके पासवर्ड की रक्षा करने का सही तरीका क्या है जो संचार डेटा पर गलत हो सकता है?

मुझे पता है कि HTTPS समस्या का समाधान है, लेकिन क्या मानक HTTP प्रोटोकॉल (POST अनुरोध) का उपयोग करके कम से कम कुछ स्तर की सुरक्षा सुनिश्चित करने का कोई तरीका है? (शायद किसी तरह से जावास्क्रिप्ट का उपयोग करके)

EDIT I ने कुछ महत्वपूर्ण चीजें छोड़ दी हैं।

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

धन्यवाद।

Comments

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

— जेरेमी पॉवेल

आपके द्वारा बताई गई समस्या HTTPS का आविष्कार किया गया कारण है। यदि आप पासवर्ड को एन्क्रिप्ट करने के लिए क्लाइंट को एक गुप्त संदेश भेजते हैं, तो एक ईवेर्सडॉपर इसे सूँघने में सक्षम होगा और रिटर्न ट्रिप पर पासवर्ड को डिक्रिप्ट करेगा।

— 18

तो आपके सुझाव में S केवल पासवर्ड (या उपयोगकर्ता नाम + पासवर्ड किसी भी तरह से संयुक्त) हो सकता है, क्योंकि यह एकमात्र "गुप्त" है जो उपयोगकर्ता के पास है। क्या मैं सही हूँ? तो समाधान फॉलोवर्स के रूप में होगा: - सर्वर एक छिपे हुए फॉर्म फ़ील्ड R के साथ HTML पेज प्रदान करता है - उपयोगकर्ता पासवर्ड दर्ज करता है, और पासवर्ड भेजे जाने से पहले, जावास्क्रिप्ट एच (आर, एस) की गणना करता है और इसे सर्वर को भेजता है, शायद AJAX का उपयोग करके भी - सर्वर एच (आर, एस) की गणना करता है और प्राप्त के साथ इसकी तुलना करता है और अजाक्स अनुरोध की प्रतिक्रिया भेजता है कि क्या प्रमाणीकरण पारित हुआ - जावास्क्रिप्ट ब्राउज़र को वांछित वेबपेज पर पुनर्निर्देशित करता है

— कोर्नेलिजेक

@ जेरेमी पॉवेल - जब आप वर्णन करते हैं तो यह आम बात है, यह एक मध्यस्थ के लिए भी असुरक्षित है जो शीर्ष लेख से कुकी को सूँघ सकता है और कुकी का पुन: उपयोग करके उपयोगकर्ता को प्रतिरूपित कर सकता है। जब तक आप HTTPS

— jnoss

भविष्य में जो कोई भी इस प्रश्न के लिए आता है: लॉग इन करने के बाद, आपको सत्र कुकी को सुरक्षित करने की भी आवश्यकता है। (इसलिए, HTTPS का उपयोग करना वास्तव में इतना आसान है।)

— अर्जन

Answer 1

SSL के साथ HTTP का उपयोग करना आपके जीवन को बहुत आसान बना देगा और आप बहुत ही स्मार्ट लोगों (कम से कम मुझसे कम!) को आराम कर सकते हैं, इसने गोपनीय संचार की इस विधि की वर्षों तक छानबीन की है।

Comments

... और "लेकिन मुझे एसएसएल प्रमाणपत्र के लिए भुगतान करना होगा !!" एक वैध शिकायत नहीं है, क्योंकि आप उन्हें इन दिनों $ 30 के लिए प्राप्त कर सकते हैं। क्या आपका डेटा वास्तव में सुरक्षा के लिए 30 रुपये का मूल्य नहीं है?

— कैफे

क्या होगा यदि आपने जिस वेबहोस्ट को सब्सक्राइब किया है वह एसएसएल सर्टिफिकेट जोड़ने का समर्थन नहीं करता है?

— कालमेरी

@Calmarius - तब आप एक असली वेबहोस्ट पर चले जाते हैं

— 19

@BornToCode तकनीकी रूप से इसका मतलब है कि आपके पास एक समर्पित आईपी होना चाहिए और आपको HTTPS का उपयोग करने के लिए सर्वर हार्डवेयर (या कम से कम VPS) का मालिक होना चाहिए। साझा किए गए वेबहोस्ट तब तक HTTPS नहीं कर सकते, जब तक कि होस्ट सर्वर के सर्टिफिकेट के साथ पूरा सर्वर सुरक्षित न हो।

— कालमर्सिस

साझा किए गए वेबहोस्ट निश्चित रूप से https कर सकते हैं, en.wikipedia.org/wiki/Server_Name_Indication

— ब्रायन मिंटन

Answer 2

सुरक्षित प्रमाणीकरण एक व्यापक विषय है। संक्षेप में, जैसा कि @ जेरेमी-पॉवेल ने उल्लेख किया है, हमेशा HTTP के बजाय HTTPS पर क्रेडेंशियल्स भेजने का पक्ष लेते हैं। यह सुरक्षा संबंधी सिरदर्द से बहुत दूर ले जाएगा।

TSL / SSL प्रमाणपत्र इन दिनों बहुत सस्ते हैं। वास्तव में यदि आप बिल्कुल भी पैसा खर्च नहीं करना चाहते हैं तो एक मुफ्त Letencrypt.org है - स्वचालित प्रमाणपत्र प्राधिकरण।

आप एक कदम आगे जा सकते हैं और Caddyserver.com का उपयोग कर सकते हैं, जो पृष्ठभूमि में Letencrypt कहता है।

अब, एक बार जब हम HTTPS रास्ते से हट गए ...

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

• उपयोगकर्ता नाम और पासवर्ड को एक बृहदान्त्र द्वारा अलग किए गए स्ट्रिंग में जोड़ा जाता है, जैसे: उपयोगकर्ता नाम: पासवर्ड
• परिणामी स्ट्रिंग को R642045-MIME बेस बेस के वेरिएंट का उपयोग करके एनकोड किया गया है, केवल 76 चार / लाइन तक सीमित नहीं है।
• प्राधिकरण विधि और एक स्थान अर्थात "बेसिक" को फिर एन्कोडेड स्ट्रिंग से पहले रखा जाता है।

स्रोत: विकिपीडिया: प्राधिकरण हेडर

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

कुछ अच्छे कारण हैं जिन्हें आपको प्राधिकरण शीर्ष लेख का उपयोग करना चाहिए

1. यह एक मानक है
2. यह सरल है (आप उन्हें कैसे उपयोग करना सीखें)
3. यह आपको URL स्तर पर लॉगिन करने की अनुमति देगा, इस तरह: https://user:[e-mail]/login(क्रोम, उदाहरण के लिए स्वचालित रूप से इसे Authorizationहेडर में बदल देगा )

महत्वपूर्ण:
जैसा कि नीचे टिप्पणी में @zaph द्वारा बताया गया है, संवेदनशील जानकारी भेजना क्योंकि GET क्वेरी अच्छा विचार नहीं है क्योंकि यह सर्वर लॉग में सबसे अधिक संभावना है।

Comments

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

— ज़ाफ

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

— FullStackForger

जो आप नहीं देख सकते, उसे आप लॉग नहीं कर सकते। username:password@urlब्राउज़र से इसका अनुवाद होता है: url+ Authorizationहेडर का अनुरोध करें। GET प्रश्नों के लिए ... जैसा कि मैंने कहा, प्रमाणिकता शीर्षक का उपयोग करें। यह बेहतर है।

— फुलस्टैकफ़ॉगर

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

— को गोओ का भगवान

यह जोर दिया जाना चाहिए कि यह समाधान केवल तभी काम करता है जब आप पहले से ही टीएलएस / एसएसएल के साथ कनेक्शन को एन्क्रिप्ट कर रहे हैं। base64 एन्क्रिप्शन नहीं है।

— स्कॉट

Answer 3

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

1. क्लाइंट के लिए सर्वर एक यादृच्छिक संख्या, आर भेजता है।
2. क्लाइंट H (R, S) को सर्वर पर भेजता है (जहाँ H एक क्रिप्टोग्राफ़िक हैश फ़ंक्शन है, जैसे SHA-256)
3. सर्वर एच (आर, एस) की गणना करता है और ग्राहक की प्रतिक्रिया से इसकी तुलना करता है। यदि वे मेल खाते हैं, तो सर्वर क्लाइंट को पासवर्ड जानता है।

संपादित करें:

R की ताजगी और तथ्य यह है कि HTTP स्टेटलेस है, के साथ यहां एक मुद्दा है। यह सर्वर को एक सीक्रेट बनाने के द्वारा नियंत्रित किया जा सकता है, इसे क्यू कहते हैं, जिसे केवल सर्वर जानता है । फिर प्रोटोकॉल इस प्रकार है:

1. सर्वर यादृच्छिक संख्या आर उत्पन्न करता है। यह तब क्लाइंट एच (आर, क्यू) (जिसे ग्राहक द्वारा जाली नहीं किया जा सकता है) को भेजता है।
2. क्लाइंट R, H (R, Q), और H (R, S) की गणना करता है और सभी को सर्वर पर वापस भेज देता है (जहाँ H एक क्रिप्टोग्राफ़िक हैश फ़ंक्शन है, जैसे SHA-256)
3. सर्वर एच (आर, एस) की गणना करता है और ग्राहक की प्रतिक्रिया से इसकी तुलना करता है। फिर यह आर लेता है और गणना करता है (फिर से) एच (आर, क्यू)। यदि क्लाइंट का संस्करण H (R, Q) और H (R, S) सर्वर के पुन: संगणना से मेल खाता है, तो सर्वर क्लाइंट को प्रमाणित करता है।

ध्यान दें, चूंकि H (R, Q) क्लाइंट द्वारा जाली नहीं बनाया जा सकता है, H (R, Q) कुकी के रूप में कार्य करता है (और इसलिए इसे वास्तव में कुकी के रूप में लागू किया जा सकता है)।

एक और संपादन:

प्रोटोकॉल में पिछला संपादन गलत है क्योंकि जिस किसी ने भी H (R, Q) का अवलोकन किया है, वह सही हैश के साथ इसे फिर से देख पाता है। सर्वर को याद रखना होगा कि कौन से आर अब नए नहीं हैं। मैं यह जवाब दे रहा हूं, ताकि आप लोग इसे दूर संपादित कर सकें और कुछ अच्छा कर सकें।

Comments

+1 - आपको जावास्क्रिप्ट (या फ्लैश / सिल्वरलाइट / आदि) के साथ क्लाइंट की ओर से प्रतिक्रिया की गणना करने की आवश्यकता होगी।

— ऑर्ट

आदमी को बीच में या प्रतिरूपण के हमलों से नहीं रोकता है। जैसे वाईफाई के माध्यम से। ऐसा लगता है कि सुरक्षा का एक गलत अर्थ, IMO होगा।

— टॉम हॉल्टिन -

यह निष्क्रिय हमलों से बचाता है, लेकिन मध्य में एक आदमी अभी भी हमला कर सकता है।

— डगलस लीडर

इसके अलावा सर्वर को मूल पासवर्ड जानना आवश्यक है।

— डगलस लीडर

क्रिप्टोकरंसी पर लगाम मत लगाओ! (उत्पादन में)

— ब्रीफ़न

Answer 4

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

अन्यथा यदि आप HTTP पर कुछ करना चाहते हैं। मैं ऐसा कुछ करूंगा।

1. सर्वर लॉगिन पृष्ठ में अपनी सार्वजनिक कुंजी एम्बेड करता है।
2. क्लाइंट लॉगिन फ़ॉर्म को पॉप्युलेट करता है और सबमिट पर क्लिक करता है।
3. AJAX के अनुरोध को सर्वर से वर्तमान टाइमस्टैम्प प्राप्त होता है।
4. क्लाइंट साइड स्क्रिप्ट क्रेडेंशियल, टाइमस्टैम्प और एक नमक (एनालॉग डेटा उदा। माउस आंदोलनों, कुंजी प्रेस घटनाओं) को एकत्र करता है, इसे सार्वजनिक कुंजी का उपयोग करके एन्क्रिप्ट करता है।
5. परिणामी हैश प्रस्तुत करता है।
6. सर्वर हैश को डिक्रिप्ट करता है
7. जाँच करता है कि टाइमस्टैम्प हाल ही में पर्याप्त है (केवल एक छोटी 5-10 दूसरी विंडो की अनुमति देता है)। यदि टाइमस्टैम्प बहुत पुराना है, तो लॉगिन को अस्वीकार कर देता है।
8. 20 सेकंड के लिए हैश स्टोर। इस अंतराल के दौरान लॉगिन के लिए उसी हैश को अस्वीकार करता है।
9. उपयोगकर्ता को प्रमाणित करता है।

तो इस तरह से पासवर्ड सुरक्षित है और उसी प्रमाणीकरण हैश को दोबारा नहीं चलाया जा सकता है।

सत्र टोकन की सुरक्षा के बारे में। यह थोड़ा कठिन है। लेकिन चुराए गए सत्र टोकन को थोड़ा कठिन बनाना संभव है।

1. सर्वर एक अतिरिक्त सत्र कुकी सेट करता है जिसमें एक यादृच्छिक स्ट्रिंग होती है।
2. ब्राउज़र अगले अनुरोध पर इस कुकी को वापस भेजता है।
3. सर्वर कुकी में मूल्य की जांच करता है, अगर यह अलग है तो यह सत्र को नष्ट कर देता है, अन्यथा सब ठीक है।
4. सर्वर कुकी को फिर से अलग पाठ के साथ सेट करता है।

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

संपादित करें: कृपया ध्यान दें कि यह MITM हमलों को नहीं रोकता है अगर हमलावर अपना पेज अलग-अलग सार्वजनिक कुंजी के साथ सेट करता है और सर्वर से अनुरोध करता है। इस तरह की चालों का पता लगाने के लिए सार्वजनिक कुंजी को ब्राउज़र के स्थानीय भंडारण में या ऐप के भीतर पिन किया जाना चाहिए।

कार्यान्वयन के बारे में: आरएसए शायद सबसे अधिक ज्ञात एल्गोरिदम है, लेकिन यह लंबे कुंजी के लिए काफी धीमा है। मुझे नहीं पता कि PHP या जावास्क्रिप्ट का कार्यान्वयन कितनी तेजी से होगा। लेकिन शायद एक तेज एल्गोरिदम हैं।

Comments

क्या इस मामले में पासवर्ड वास्तव में संरक्षित है? किसी को क्या भेजा गया है सूँघना नहीं है और इसे सार्वजनिक कुंजी का उपयोग करके डिक्रिप्ट कर सकते हैं और बाद में टाइमस्टैम्प को अपडेट कर सकते हैं जब वे इसे बाद में उपयोग करते हैं? क्या मैं कुछ भूल रहा हूँ?

— michaellindahl

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

— दान पेंट्री

ब्राउज़र और सर्वर के बीच एक कंप्यूटर लॉगिन पृष्ठ पर सार्वजनिक कुंजी को बदल सकता है।

— अंती

अपने तरीकों को साझा करने के लिए धन्यवाद, मुझे बहुत दिलचस्प कुछ मिला। पंथ भेजने पर जोड़ा गया टाइमस्टैम्प एक अच्छी पकड़ है! अतिरिक्त सत्र कुकी का उपयोग करने के बारे में एक सवाल जिसका मूल्य एक यादृच्छिक स्ट्रिंग है: केवल अगले अनुरोध के लिए एक टोकन की तरह है?

— विक्टर

Answer 5

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

Answer 6

आप एक असुरक्षित चैनल पर सुरक्षित पासवर्ड का उपयोग करने के लिए SRP का उपयोग कर सकते हैं । फायदा यह है कि अगर कोई हमलावर ट्रैफ़िक को सूँघता है, या सर्वर से समझौता करता है, तो भी वे किसी भिन्न सर्वर पर पासवर्ड का उपयोग नहीं कर सकते हैं। https://github.com/alax/jsrp एक जावास्क्रिप्ट लाइब्रेरी है जो ब्राउज़र में HTTP या सर्वर साइड (नोड के माध्यम से) पर सुरक्षित पासवर्ड का समर्थन करता है।

Answer 7

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

यहाँ जावा स्रोत कोड है जो संचार करने के लिए असममित सिफर RSA (PGP द्वारा प्रयुक्त) का उपयोग करता है: http://www.hushmail.com/services/downloads/

Answer 8

आप अपने होस्ट के लिए ssl का उपयोग कर सकते हैं ssl के लिए मुफ्त प्रोजेक्ट है जैसे letencrypt https://letsencrypt.org/

Comments

प्रश्न में तीसरे वाक्य की जाँच करें। (इसके अलावा, हमेशा यह सुनिश्चित करने के लिए अन्य उत्तर पढ़ें कि आप कम-विस्तृत डुप्लिकेट नहीं जोड़ रहे हैं।)

— नाथन टग्गी

Answer 9

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

हमने यह प्रयोग किया है कि safevia.net को लागू करते समय - ग्राहक (प्रेषक / रिसीवर) पक्षों पर एनक्रिप्शन किया जाता है, इसलिए उपयोगकर्ता डेटा न तो नेटवर्क पर उपलब्ध होते हैं और न ही सर्वर लेयर पर।