AJAX का उपयोग कर सादा पाठ पासवर्ड भेजना कितना सुरक्षित है?

Question

शायद शीर्षक बुरी तरह से phrased है लेकिन यह कहने का एक बेहतर तरीका नहीं सोच सका।

मैं फिलहाल एक लॉगिन सिस्टम पर काम कर रहा हूं (औपचारिक, बस प्रयोग नहीं कर रहा हूं) और कुछ सुविधाओं के लिए PHPLiveX (एक AJAX लाइब्रेरी) का उपयोग करने की योजना बना रहा था। असल में आप कुछ PHP फ़ंक्शन बनाते हैं जिन्हें जावास्क्रिप्ट के माध्यम से बुलाया जाता है। आप जावास्क्रिप्ट को पैरामीटर (getElementById) जोड़ सकते हैं जो PHP फ़ंक्शन में स्थानांतरित हो जाते हैं।

मैं वास्तव में जानना चाहता था कि पासवर्ड को पहले एन्क्रिप्ट किए बिना केवल जावास्क्रिप्ट से फ़ंक्शन को कॉल करना सुरक्षित है, फिर PHP फ़ंक्शन को एन्क्रिप्ट करने दें (इस मामले में SHA256)। AJAX के माध्यम से स्थानांतरित डेटा अवरुद्ध किया जा सकता है? यदि ऐसा है तो यह कितना संभव है?

Answer 1

कोई और अधिक या कम एक सामान्य HTTP POST एक ब्राउज़र द्वारा जारी किए गए अनुरोध से सुरक्षित (के रूप में में एक <form> से)

"ठीक" के लिए यह एक ही गैर AJAX के लिए "ठीक" है अनुरोध - एसएसएल का उपयोग करें।

Answer 2

AJAX कॉल केवल सादे HTTP अनुरोध हैं।

यह सामान्य HTTP अनुरोध की तरह व्यवहार करता है और इसके सभी लाभ और नुकसान के साथ आता है। यह कोई सुरक्षित नहीं है।

1. SSL का उपयोग करें:

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

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

Answer 3

चाहे आप AJAX के माध्यम से या सामान्य फ़ॉर्म के माध्यम से पासवर्ड भेज रहे हों, फिर भी यह एक HTTP POST (उम्मीदपूर्वक) अनुरोध के माध्यम से भेजा जाता है। तो आप सुरक्षा के अनुसार कुछ भी जोड़ या हटा नहीं रहे हैं।

किसी को अपना पासवर्ड अवरुद्ध करने से रोकने का एकमात्र तरीका एसएसएल (AJAX या नहीं के माध्यम से) का उपयोग कर है।

Answer 4

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

AJAX पर आगे पढ़ने और सुरक्षा मैं सलाह देते हैं के लिए निम्नलिखित रीडिंग

• Top 10 Ajax Security Holes and Driving Factors
• Ajax security holes and how to fill them

Answer 5

यह बस के रूप में एक लॉगिन फार्म का है कि एसएसएल सुरक्षित नहीं है होने के रूप में सुरक्षित है तार पर भेजा जाना चाहिए, लगभग सभी मंचों की तरह वहाँ!

Answer 6

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

यहाँ एक टेलनेट पासवर्ड कैप्चर करने का एक video उदाहरण है। टेलनेट सादे पाठ में भेजता है और यह अच्छी तरह से आपके सामने होने वाली प्रमुख समस्या को दर्शाता है यदि आप ऐसा करने के बारे में भी सोचते हैं। कोई भी दो बिट स्क्रिप्ट किड्डी एक सादे पाठ पासवर्ड को तेज़ी से छीन सकती है ताकि आप ऐसा कर सकें "हे मेरे भगवान, मेरा डेटाबेस कहां गया?"

Answer 7

सुनिश्चित करें कि आपके AJAX कॉल का लक्ष्य एक विश्वसनीय HTTPS: // पृष्ठ है और आपने इसे जितना सुरक्षित बनाया है, वैसे ही कोई अन्य जानकारी उसी जानकारी के भेजता है जो आपका शेष एप्लिकेशन कर रहा है। अधिकांश पुस्तकालय/ढांचे आपको अपने AJAX कॉल के लिए केवल HTTP: // तक ही सीमित नहीं करते हैं।

Answer 8

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

Answer 9

हाँ, यह पढ़ा जा सकता है। किसी अन्य प्रकार की सुरक्षा के बिना बस (एसएसएल देखें)

यह देखने के लिए कि आप अपने AJAX आदेशों के रूप में WireShark जैसे टूल चलाते हैं।

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

Answer 10

दूसरों का उल्लेख किया है, यह एक रूप से एक HTTP पोस्ट भेजने से अधिक नहीं खतरनाक है। वास्तव में, यह वही बात है।

लेकिन अगर HTTPS एक विकल्प आप हमेशा एन्क्रिप्ट न किए गए कनेक्शन पर एक चुनौती/प्रतिक्रिया योजना का उपयोग कर सकते हैं नहीं है। असल में यह इस तरह काम करता है:

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

यह विचार प्राप्त करने के बाद वास्तव में स्थापित करना बहुत आसान है। Wikipedia पर इसके बारे में कुछ अतिरिक्त जानकारी है।

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

Answer 11

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

Answer 12

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

Answer 13

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

निम्नलिखित साइट अजाक्स के संबंध और XSS या XSRF हमलों में वास्तव में कुछ अच्छे जानकारी है http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf

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